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.

Tuesday, 7 June 2016

OSGi webconsole evolution

Status (Version 0.3.0)

Last week of May I started a new project, an OSGi webconsole bundle (check out this post for more details). It is still a proof of concept, but it is already getting useful (for me). The main idea is that I want to have something completely independent from the concrete OSGi framework or any other bundle or service already deployed in the system. So you add no more than one bundle into any framework to get an OSGi "introspector".


For documentation purposes, here's a current screenshot:

The Goal


Having a single bundle to provide all the introspection functionality is only the first step. What I really want to achieve are the following features:

 - Snapshots


As soon as the webconsole bundle is started, the first snapshot of the current framework state is taken, i.e. all bundle, service and log information will be persisted, referenced by a name like "initial". Later, for example after installing a new bundle, you can manually create a new snapshot of the framework, and compare it to the former one. Like this, it is much more easy to understand what happens in the framework once a specific event is triggered. 


 - Diagnostics

Comparing "working" snapshots to "broken" ones, it is easier to understand what is different and what needs to be fixed. The OSGi webconsole should be able to help the user figuring out what is different and provide hints of what to fix.


 - Visualization

OSGi is powerful, but not trivial (no surprise here...). Visualizing bundles and services together with their relations, potentially changing over time, provides insights and is fun. Creating this visualizations though is not trivial either ;)

Demo Link

This link should be working most of the time...

Stay tuned...

If you think this is going to be interesting for you, please let me know. This will add to my motivation ;)