Thursday Apr 09, 2009

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/config.properties.

  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 :

package examples.services.api;
/\*\*
 \* 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.

./pom.xml
./src/main/java/examples/services/api/SimpleService.java
./src/main/resources/META-INF/MANIFEST.MF


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-SymbolicName: examples.services.simple-bundle-api
Bundle-Name: Services definition bundle for OSGi integration in GlassFish
Export-Package: examples.services.api
Bundle-ManifestVersion: 2


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

 <?xml version="1.0"?>
<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>examples.services</groupId>
    <artifactId>simple-service-api</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>
    <name>Simple Service Provider API definition</name>
    <developers>
        <developer>
            <id>dochez</id>
            <name>Jerome Dochez</name>
            <email>jerome.dochez@sun.com</email>
            <url>blogs.sun.com/dochez</url>
        </developer>
    </developers>
    <build>
        <finalName>${project.artifactId}</finalName>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <configuration>
                    <archive>
                        <manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
                    </archive>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

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
Trying 127.0.0.1...
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 = examples.services.simple-bundle-api
Export-Package = examples.services.api
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...

Friday Apr 11, 2008

GlassFish V3 runs on OSGi

As some of you may remember when I introduced the HK2 project last year, I described it as a friendly environment to OSGi where we would eventually be capable of running GlassFish V3 on top of an OSGi runtime. Thanks to the good work of Sahoo, this vision has finally been completed and I am happy to report that since last week, we are now capable to run GlassFish V3 on top of Apache Felix, one of the OSGi runtime available to the open source community.


In fact, we have also tried KnopflerFish (I like the name of course) and it runs fine so we are pretty confident that any OSGi runtime will be supported with minimum effort.


Now the interesting question that everyone will be asking soon, are we switching to OSGi as our underlying module subsystem ? Today I can say yes, we will. Some people might say that we changed our mind about OSGi, we didn't. From the beginning I always said we wanted to be friendly to OSGi, we just realized that vision... It is pretty clear that there is a big industry support for OSGi and it is important that GlassFish can be part of that excitement. I cannot commit on which implementation we will eventually use because we are still experimenting with some of them and we need to following conditions to be met :


    \* open source

    \* friendly license to one of our dual open source licenses as well as to our Java EE licensees.

    \* good community (forums, mailing list) to get our questions answered

    \* possibility of a commiter to be able to push our bug fixes.


Whichever implementation we choose will get a huge boost from this endorsement because we will certainly have engineers capable of fixing bugs, adding features but also we have top performance engineers at Sun that will help with the overall performance of the OSGi runtime. 


Sahoo will probably blog in a day or two explaining in details the technicalities of the solution we adopted but let me introduce it here. We are still capable of running in both HK2 mode and in OSGi mode, I am not sure how long we will maintain the HK2 mode but so far the startup is a lot faster in HK2 (1 second) versus OSGi (2 seconds). Ok no big deal I suppose but we will work on that. It's hardly surprising that HK2 is faster, it is not meant to be a generic modular subsystem like OSGi, it is quite optimized for our V3 work !


None of GlassFish code depends on OSGi libraries (or very very little), we isolated those dependencies in HK2 which makes it very easy for us to switch OSGi runtimes or even module management runtime with no code changes. The HK2 project will continue as it is offering a lot more than just module management, in particular we have the following features that we continue to use heavily :


    \* module management isolation layer

    \* module management through Repositories (coming in OSGi R5)

    \* lightweight component model

    \* dependency injection 

    \* configuration handling


So if you want to play with the OSGi version of GlassFish V3, I would recommend downloading the latest binaries from there.

It's our latest build, don't expect miracle and please file bugs when you find one.

 

and to run GlassFish in OSGi mode, simply do from your installation directory

    	java -DGlassFish_Platform=Felix -jar modules/glassfish-10.0-SNAPSHOT.jar

to run in hk2 mode, just do

	java -jar modules/glassfish-10.0-SNAPSHOT.jar 
About

dochez

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today