Osgish

Osgish is an OSGi shell based on a Perl shell on the client side which communicates via HTTP/JSON to a special agent bundled deployed on the target platform. Beside standard features provided by the various existing OSGi shells outside it provides some unique features to make life easiers when dealing with a lot of OSGi bundles:

* GNU Readline support with
- History saved accross sessions
- context sensitive command line completion
- Emacs key bindings

* Consistent syntax highlighting (switchable) with color theme support
* Remote operation via HTTP(S) including a upload facility for bundles to install/update
* Configurable via a configuration file like shortcuts for known server URLs.
* Wildcard support for query and lifecycle operations
* Support for bulk operations (e.g. starting multiple bundles at once)
* Command groups which can be traversed like directories
* Extensible by command plugins

HOW IT WORKS

Osgish consist of mainly two parts: A Perl command line script (along with some Perl modules) which connects to an OSGi container via a special OSGi agent bundle (osgish-agent.jar). This bundle contains the jmx4perl for exports JMX information through an OSGi HttpService as JSON data. The JMX MBeans used are those provided by the Aries (http://incubator.apache.org/aries/) which becomes an implementation of the (yet to be finished) specification of the OSGi Alliance Enterprise Expert Group (EEG), especially the "JMX Management Model Specification". 

Although this setup sounds a bit involved, installation is not much more than installing a CPAN package and a provided OSGi bundle (the same as for jmx4perl).

INSTALLATION

The Perl part installs as any other module via Module::Build, which you need to have installed. Using

  perl Build.PL
  ./Build
  ./Build test
  ./Build install

will install the modules. If you have Java and Maven (a Java build tool) installed, the agent bundle will be compiled and packaged as well when you use './Build dist'. However, this is not required as a prepackaged bundle is contained within the agent directory.

Osgish depends on the Perl Module 'Term::ReadLine' (indirectly via Term::ShellUI), which can be used with various backend Readline implementations. The most powerful (and hence recommended) implementation is GNU Readline/History Library which will be used if installed. It is really worth to go the extra way to install GNU readline, even on OS X or Windows (which is not trivial). E.g. for OS X you can use the package 'p5-term-readline-gnu' from Mac Ports to install readline along with the needed module. For Debian, the easiest way is to install the package 'libterm-readline-gnu-perl' via apt. However, the default implementation Term::ReadLine::Perl fits nicely, too.

For the module to work, you need to provision "osgi-agent-.jar" to each OSGi container you want to connect to. Refer to your OSGi framework how to install a bundle (e.g. by calling 'install' in a OSGi shell or providing the bundle name during startup). This bundle has a dependency on an OSGi HttpService, which needs to be available. Some OSGi container (like Glassfish v3) already comes with a HttpService as an installation option, for others you need to install one manually. A good choice is the Pax Web (http://wiki.ops4j.org/display/paxweb/Pax+Web) HttpService. Select the pax-web-jetty-bundle when downloading, it contains a all you need.

Considered you installed the HttpService at its default port 8080,  you can connect to it via

  osgish --server http://localhost:8080/j4p

(This assumes, that the HttpService has a root context '/' which is true for Pax Web. Glassfish v3's HttpService use a root context of '/osgi' which results in a connect URL of http://localhost:8080/osgi/j4p)

SUPPORTED OSGI PLAFORMS
 
The following OSGi platform has been confirmed to work so far with:

  * Felix 2.0.1
  * Equinox 3.5.1
  * Glassfish v3
  * Spring dm Server 2.0

Since OSGi bundles are highly portable, it is expected that every SGi server with an installed HttpService should work out of the box.  Please open a bug at http://rt.cpan.org/Public/Bug/Report.html?Queue=osgish if you encounter any problems.

“Why on earth are you using Perl for bridging to a pure Java based technology like OSGi ?”

Well, as the setup might seem quite complex (an in fact, it is confessly more work than installing a bunch of OSGi bundles) it has some unique advantages. Perl is known for its premium level text manipulation capabilities and its tight system integration. The richness of CPAN modules is still unmatched in the Java world so far. Goodies like Term::ProgressBar or Term::ShellUI are probably missing on the Java side for quite some time to come. Thanks to its pure HTTP communication it works nicely across firewall boundaries. And don’t forget Perl’s excellent performance characterisics for this sort of applications. Last but not least, it is a perfect use case for jmx4perl, which has a story on its own ;-). IMO it is the perfect mix, where each language plays out its strength.

Ok, enough praise, there are of course some drawbacks, too: Installing Perl modules can be a pain especially if one is uncomfortable with cpan or Perl at a whole. Especially installing Term::ReadLine::Gnu on Windows or OS X can give major headaches (although is possible, and there is a fallback, too). It is easy to shoot oneself in the foot when manipulating the lifecycle of the agent bundle or it’s dependencies with osgish. Network latency and traffic can become an issue since all communication is remotely per se.

At the end it is up to you to judge wheter osgish fits for you. I would be more than happy if you would give it a try. For me it helps me at my OSGi development and administration tasks every day.

Even if you are not planning to use osgish, I’m curious about your opinion on this setup. Comments are highly appreciated!

What is new in this release:

• Updated to Aries 0.3
• Splitted up OSGi bundles in a pure (core) bundle and an all-in-one bundle (bundle)

What is new in version 0.1.0:

• Upload bundles to server and manage it
• Tuned context sensitive completions, added options to 'ls' of services/bundles ('-s' show symbolic names, '-u < bid >' only services used by bundle < bid >, '-b < bid >' services owned by bundle < bid >
• Start to add online help

Requirements:

• Java 2 Standard Edition Runtime Environment
• Perl
• JMX::Jmx4Perl::Config
• Config::General
• OSGi::Osgish