GlassFish V3 Extensions, part 2 : Managed OSGi bundles

     I am back this time to talk about a feature I just added to GlassFish v3. When extending GlassFish, you really have a few different ways to do so, you can write a plain old jar file and put it in the lib directory but preferably, you should write an OSGi bundle. The best for maximum portability is to write a jar which can be an OSGi bundle and also a plain old jar when possible. So once you have your brand new OSGi bundle, how can you install it in GlassFish v3 so it becomes part of the ecosystem ?

    There are basically two ways to do that today :

  • place the bundle in the glassfish/modules directory.

  • deploys the bundle just like you deploy any other application.

    Let's look at the disadvantages of each solution : 

  1. modules directory : Using the modules directory solution is easy and quick, and seems to be the natural way of adding functionality to GlassFish. However it has a few disadvantages :

    • no module management, you need to manage the files in modules yourself (adding, updating, removing).

    • no clustering support. we don't have clustering support in v3 yet but using the modules directory will not guarantee that all server instances will be updated when you add or remove bundles from the modules directory.

    • hard to figure out which bundles in modules directory are yours versus the ones we delivered. 

    • bundles are not started in OSGi automatically in V3, they are just installed, so if they have a bundle activator for instance, you need to start them manually. One easy way to do that is to change the autostart list in the felix configuration at glassfish/osgi/felix/config/

  2. Deployment : using deployment method you need to manage dependencies correctly when you deploy. So far you can only deploy one bundle at a time (ok, if you don't like that, file an RFE) so if your bundles import other bundles and so on, you better deploy them in the right order.

I think solution 2 has many advantages, it's a managed operation which is protected by the admin password if you set up on, it also does not require to have access to the application server file system and it's remotable. To illustrate solution 2, I am now going to build a new OSGi bundle and deploy using the normal "asadmin deploy" command. Let's start with building a new bundle using maven, something really simple, an API bundle containing one service definition that looks like this :

 \* Simple service defition
 \* @author Jerome Dochez
public interface SimpleService {
     \* Returns a implementation specific string
     \* @return a String
    public String getString();

So nothing that will get me a Nobel prize here ;-) Let's see the project files now.


Due to the simplicity of the project, I manually coded the manifest file rather than using BND, also it helps the no-magic theme here.

Bundle-Version: 1.0
Bundle-Name: Services definition bundle for OSGi integration in GlassFish
Bundle-ManifestVersion: 2

Finally, the complete pom.xml file looks like this...

 <?xml version="1.0"?>
    <name>Simple Service Provider API definition</name>
            <name>Jerome Dochez</name>

Build your code

mvn install 

Ok so time to deploy your new bundle in V3, this is really hard, just do 

 >asadmin deploy --type osgi target/simple-bundle-api.jar

--type osgi is necessary so the bundles is installed in the OSGi runtime rather than in Java EE containers. now let's check if the bundle is installed correctly, let's start the felix console :

>telnet localhost 6666
Tower:impl dochez$ telnet localhost 6666
Connected to localhost.
Escape character is '\^]'.

Felix Remote Shell Console:


type "ps" and you should get a list of all the installed bundles, one should be our newly deployed OSGi bundle (note that your bundle ID might be different) 

[ 188] [Active     ] [    1] Services definition bundle for OSGi integration in GlassFish (1.0)

lets make sure this is how bundle :

-> headers 188

Services definition bundle for OSGi integration in GlassFish (188)
Manifest-Version = 1.0
Archiver-Version = Plexus Archiver
Bundle-Name = Services definition bundle for OSGi integration in GlassFish
Built-By = dochez
Bundle-SymbolicName =
Export-Package =
Bundle-Version = 1.0
Build-Jdk = 1.6.0_07
Created-By = Apache Maven
Bundle-ManifestVersion = 2

when you are done with the bundle, just undeploy :

>asadmin undeploy simple-bundle-api

Voila !

Next article will be a lot more interesting, we will be using our newly deployed OSGi bundle with a mix of Spring, OSGi and Java EE 6 code...


Hey Jerome, this is really good simple stuff and yet I'm unable to run this on GlassFish V3 Prelude. Should there be a proviso here that it applies only to the current "Work In Progress" version of GlassFish?

Posted by James on April 21, 2009 at 07:43 AM PDT #

Actually, it is really good! I used the felix console commands to install the bundle and everything is sweet. Thanks.

Posted by James on April 21, 2009 at 09:24 AM PDT #

Hi James

You are right, I should have mentioned that you need to use the dev build or at least the last weekly pomotion of glassfish. This was not implemented at the time prelude was released.

Thanks for experimenting, feel free to send any feedback/RFE.


Posted by Jerome Dochez on April 23, 2009 at 03:32 AM PDT #

[Trackback] I have intergrated Felix FileInstall bundle in GlassFish and here I will show you how you can deploy/undeploy OSGi bundles by copying/removing your bundles to/from a designated directory.

Posted by Sahoo's Blog on May 03, 2009 at 04:51 PM PDT #

Post a Comment:
Comments are closed for this entry.



« January 2017