Wednesday, 27 July 2016

Use Cases for skysail-webconsole Part 1

As written in some older posts (see here and here) skysail webconsole aims to visualise an OSGi runtime and provides you with all relevant information of the installed bundles, their services, packages and relations between them.

The information itself is derived from standard OSGi interface and _could_ be obtained using
the OSGi console using standard commands of the framework implementation (like 'ss' for show status in equinox or lb for 'list bundles' in apache felix). But skysail webconsole tries to make things more convenient both for OSGi beginners and experts.

This series will give you some ideas of how to use skysail webconsole, specifically if things don't seem to be working the way you expect them. Please be aware that the webconsole project is still work-in-progress and subject to change. If you have any feedback, ideas or questions, please let me know.

"could not resolve bundles"

The dreaded OSGi message for beginners (and experts?). What you get as a message on the console might look like this:

! could not resolve the bundles: [io.skysail.bundled.htmlunit-osgi-withdeps- to resolve io.skysail.bundled.htmlunit-osgi-withdeps [15](R 15.0): missing requirement [io.skysail.bundled.htmlunit-osgi-withdeps [15](R 15.0)] osgi.wiring.package; (osgi.wiring.package=javax.servlet) Unresolved requirements: [[io.skysail.bundled.htmlunit-osgi-withdeps [15](R 15.0)] osgi.wiring.package; (osgi.wiring.package=javax.servlet)]]

It is not like is doesn't say what's happened; the bundle 'htmlunit-osgi-withdeps' is not able to access the package 'javax.servlet' (as this package is not exported by any bundle), therefore the bundle cannot be resolved.

Now, assuming you fix this dependency, it is very likely that you will get a similar message when your start the framework again, this time referencing a different package which is also missing.

skysail webconsole 

With skysail webconsole, you can look inside the running framework and figure out all dependencies which are not fulfilled. Of course, the webconsole will not magically make your bundle resolve, but in the "imported packages view" you'll find all packages which cannot be resolved. This could be a real time saver and might save you from some frustration (namely, constantly and somehow randomly adding new bundles to make your initial bundle resolve, one at a time and over and over again.)

This is a version 0.1.10 screenshot of the "imported packages view":

Saturday, 23 July 2016

OSGi webconsole with d3.js visualizations


A couple of weeks ago I started a new project to help me understand what's going on under the hood of my OSGi applications. I was using the felix webconsole before, but it seemed wrong to me that I was forced to install additional bundles just to make the webconsole work, specifically as those additional bundles change the system as a whole by providing their own packages and services.

The idea

Provide a single bundle (including all necessary dependencies) which can be dropped into any OSGi application with minimal implications for the "system under observation".

Current Status

Find below some screenshots capturing the current status of development. The project is still in alpha, so please do not expect everything to work perfectly. I am happy about any feedback and ideas of how the skysail webconsole can become more useful to any OSGi developer.


The webconsole's starting page: you see a list of the installed bundles, their status, size and number of services they provide and consume:

The skysail webconsole bundle provides a "package dependencies" view so that you can see which bundles depend on which other bundles in terms of "package imports". The screenshot below is from a running eclipse installation. Of course, this approach still needs a lot of work as the only thing you might understand from that visualisation is that is is... complicated.

Stay tuned and follow me on my twitter account for updates if you like.