Long story short: telnet "host running glassfish v3" 6666 -> help Welcome to my blog. It's been a while since I last wrote something here. The last few months (or is it a year now) have been quite challenging for us at GlassFish project. Most of my time has been spent in making sure that GlassFish v3 runs on OSGi and runs well. We have made a lot of progress in this regard and made a release called GlassFish V3 Prelude back in November, which is our first supported release running on an OSGi platform. it uses Felix as the OSGi framework, but since it relies only on OSGi R4 APIs instead of using any proprietary Felix APIs, it is fairly easy to use any other compliant OSGi implementation as has been demonstrated by Ludo. When we started breaking our monolithic code base to a more modular one using OSGi, we started facing all the usual problems like ResolutionErrors, ClassNotFoundExceptions, NoClassDefFoundErrors, etc. We found Felix shell very useful in such scenarios. It helps us quickly query the OSGi runtime to narrow down the the problem. But, the problem is that the shell runs in the same JVM as the server and hence it can't be used when we start GlassFish in background, which is often the case. So, we have to start GlassFish by running: java -jar glassfish/modules/glassfish.jar. Even then, it's a bit annoying to find GlassFish server log mixed with the shell output. By the way, I am not blaming the shell at all. No such problems with Felix remote shell though. Like the Felix textual user interface shell, this uses the same Felix shell service to interact with the OSGi runtime, but the difference here is that this shell is accessible to telnet clients, hence it is called remote shell. It is a very light weight shell and we enable it by default in GlassFish. If you are running any recent builds of GlassFish v3, then you can connect to it by from from anywhere in the network by running: telnet host port. By default, it uses port 6666. Once you get the shell prompt, typehelp to discover all the available commands. In a nutshell, you can browse the bundles, view their headers, install new bundles, control their life cycles, etc. e.g., if you stop the GlassFish management agent bundle (bundle with name HK2 OSGi Adapter - this usually is towards the top of list when you runps command), GlassFish stops while the JVM is still around. Start it and you shall notice GlassFish starting in the same JVM. Thus, you have experienced a different avatar of Embeddable GlassFish. More on this topic some other time. I won't go onto describing all the features of the shell, as I suggest interested readers to visit its home page.How do I use it in GlassFish V3 Prelude? Although GlassFish v3 prelude comes with all the required OSGi bundles to run remote shell, it does enable the remote shell by default, because the shell was accessible to any host in the network and we didn't want that to be the case in a supported release. To enable the shell in Prelude release, open$GlassFish_Home/felix/conf/config.properties and add the shell bundles to the autostart bundles list. If you are not familiar with Felix config file, then just search for the word "shell" in that file, you shall find the instructions. Once you carry out the steps, restart GlassFish. No such steps is required if you are using any recent build of v3. The next version of the remote shell, i.e., version 1.0.4, has a configuration option to make the shell accessible only to localhost. See FELIX-826 for details. We shall integrate 1.0.4 in GlassFish as soon as it comes out and set the osgi.shell.telnet.ip property to localhost by default.