The May 2015 Beta introduces the Liberty OSGi Applications Console. When developing and deploying OSGi Applications it’s sometimes necessary to be able to look inside the application to diagnose problems. Maybe your application is not using the OSGi Service you expected it to, or maybe you suspect the package dependencies have resolved in an unexpected way. Without an OSGi Console, understanding what’s going on inside the application can be problematic.
Until now, Liberty has not provided a way to analyze your OSGi applications. WebSphere Application Server Full Profile provides a command line console as well as an OSGi Application console built into the administrative console. Since its inception, Liberty has had an
osgiConsole-1.0 feature, but this is for analyzing the runtime (for feature developers) and does not give access to OSGi applications.
The May 2015 Beta addresses this gap with the introduction of the new
To try the new
osgiAppConsole-1.0 feature, you’ll first need to install the latest (May) Liberty Beta with the OSGi Application programming model capabilities. There are two ways to do this:
- Use the new zip package for OSGi Applications. I’d recommend this one as it’s a package designed specifically for OSGi Application support.
- Or you can use the JAR installer which includes Web Profile 6 and OSGi Applications
Next you need to install the
osgiAppConsole-1.0 feature (in the future I’d expect this to be part of the zip install, but it isn’t there for this beta) using the following command:
bin\installUtility install osgiAppConsole-1.0
You should see output like this:
Step 1 of 5: Downloading httpWhiteboard-1.0... Step 2 of 5: Downloading osgiAppConsole-1.0... Step 3 of 5: Installing httpWhiteboard-1.0... Step 4 of 5: Installing osgiAppConsole-1.0... Step 5 of 5: Cleaning up temporary files... One or more features installed successfully: httpWhiteboard-1.0 osgiAppConsole-1.0. Start product validation... Validating feature: com.ibm.websphere.appserver.kernel-1.0... FAIL! [ERROR] Content: README.TXT is either changed or broken. Product validation was complete, and found 1 error(s).
If you see a validation error, don’t worry; this is a known side-effect of this particular beta build and will be resolved next time round. The feature is still installed and you’re now ready to start using it.
Configuring the Console feature
The feature is enabled with the following
featureManager entry in the
<featureManager> <feature>osgiAppConsole-1.0</feature> </featureManager>
The feature’s secured with an
admin role, using
basic auth and
https, so you’ll also need to add the following security configuration:
<httpEndpoint httpPort=”9080″ httpsPort=”9443″ id=”defaultHttpEndpoint”/> <keyStore id=”defaultKeyStore” password=”Liberty”/> <quickStartSecurity userName=”admin” userPassword=”password”/>
If you don’t have this security configuration, you’ll see errors when trying to access the console.
When you start the server, or add the feature to a running server, you’ll see a few messages that look something like this:
[AUDIT ] CWWKN2000A: HTTP Whiteboard context root added: /osgi/http [AUDIT ] CWWKN2000A: HTTP Whiteboard context root added: /osgi/http/shared [AUDIT ] CWWKN2050A: OSGi Application console added at: /osgi/http/shared/system/console [AUDIT ] CWWKT0016I: Web application available (default_host): http://localhost:9080/osgi/http/ [AUDIT ] CWWKN2000A: HTTP Whiteboard context root added: /osgi/http/MyWab.app [AUDIT ] CWWKN2050A: OSGi Application console added at: /osgi/http/MyWab.app/system/console
OSGi Application console added at messages are telling you where you have console capabilities. In this example, I had one OSGi application
MyWab.app deployed so I see a console entry for that, and a console entry for the shared bundle space (contains any bundles shared between applications on the same server). You can access these consoles by combining the Web application URL that ends in
/osgi/http/ and the relative URL for the consoles (merging the intersecting
/osgi/http/), for example:
http://localhost:9080/osgi/http/ + /osgi/http/MyWab.app/system/console http://localhost:9080/osgi/http/MyWab.app/system/console
When you access the URL, you’re redirected to the
https page and asked to sign in using the credentials configured into the
server.xml. Once signed in you’ll see a console page for your application. For example:
A few points to note:
- You’ll see we’re using the open source Felix Web Console. We felt there was no need to implement a whole other console capability when the Felix console does a perfectly good job. For more information on the Felix Web Console, see the Felix project documentation
- You’ll see a few extra bundles in the view for your application. These are a mixture of environment bundles (IDs 0 and 161 above) and Console bundles (IDs 163 and 164).
- You have the ability to perform lifecycle actions on the bundles. I’d seriously recommend against doing this as Liberty manages the Lifecycles of these bundles – no good can come of trying to do it yourself
Using the Console feature
The last bundle to mention in the example above is my application bundle (162). You can drill down on the details of each bundle by simply clicking on its name. For example, here are the details of my Web Application Bundle (MyWab):
In the above example you can see that there are a number of packages provided by other bundles in the system. Because we isolate applications from the rest of the runtime, you can see the bundle IDs but if you try to examine the bundles, the isolation will prevent this and give you a
404. Although not shown in my example, the Console also allows you to view service dependencies so that you can see which services your application is using and which services you provide.
I hope you find this new feature useful. As is always the case, feedback would be welcome and appreciated.
The May 2015 beta also introduced the Http Whiteboard feature which will be the subject of a upcoming post.