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
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)
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.
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.