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

Monday, 23 May 2016

Starting an OSGi webconsole project...

 Gibhub project 

You can find the project here.


Although I like the felix webconsole, more often than not I faced issues with integrating it with an existing codebase. OSGi is all about modularity, meaning (amongst others) that the OSGi framework makes sure that the runtime dependencies your code relies on are met. But, in the case of something like an OSGi webconsole, any dependency I have is too much. I want to install the webconsole in any kind of environment, and I want it to work immediately. I do not want something like "Unresolved requirement: Import-Package: org.apache.commons.fileupload; version="[1.2.0,2.0.0)"", which is what I get if I put the felix webconsole into eclipse Mars.

So, this bundle is an effort to provide a single bundle, ready to be dropped into any (recent) OSGi runtime, starting up an embedded server which gives me an insight into my OSGi application - even if the application doesn't start up.


Use bndtools to create a bundle which provides all its (minimal) dependencies itself:

Currently these are


Well, just started ;) - Updates will be provided on various channels, like

Feedback usually is quite motivating ;) - the more people are interested, the more fun this will be. Let me know!


  • Bundles Overview
  • Bundle Details
  • Services Overview

Screenshot (version 0.1.1.)