Osgish

By Roland Huß |
Tags:

This is the first announcement about my new toy osgish [os-gish], a shell for OSGi containers.

osgish is 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 easier when dealing with a lot of OSGi bundles:

  • GNU Readline support with

    • History saved across sessions
    • context sensitive command line completion
    • Emacs key bindings ;-)

  • Consistent syntax highlighting (switchable) with color theme support

  • Remote operation via HTTP(S) including an 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

But have a look on your own in this 4:30 minutes walkthrough:

(The fine remix “Revolve” by hisboyelroy released under the Creative Commons NonCommercial Sampling Plus 1.0 License is used for the background music)

How does it work

Osgish's architecture

An agent bundle exporting an administrative HTTP Rest interface via Jmx4Perl and Aries JMX. The only dependency for now is on an OSGi HttpService implementation as specified in the OSGi Compendium Specification 4.2 (e.g. Pax Web)

A local Perl based shell using several external Perl modules, all available on CPAN. Readline support will use Term::ReadLine::Gnu if available and falls back to the pure Perl version Term::ReadLine::Perl if not.

“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 (and in fact, it is admittedly 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 will likely 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 characteristics 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 whether 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 ;-)

Although this is the initial release and there are in fact some rough edges it is already very useful and I use it on a daily basis. You can download osgish from CPAN, installation instructions included. The source is also available from GitHub.