WebLogic Event Server Applications Are Bundles Too

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Seth White's Blog | August 17, 2007   5:18 PM | Comments (1)

In my previous entry I discussed the Event Server's modular architecture and explained that each system module -- from the adapter framework to the JMX management layer -- is packaged as an OSGi bundle.  One of the neat things about the Event Server is that applications that developers write for the server are also packaged as an OSGi bundle.  This allows for a very uniform server architecture, especially in terms of classloading, but it raises an interesting question, namely, what's the best way for a developer to create the OSGi bundle that contains their application? The answer to this question depends a lot on the build tool being used.  Most Java developers use ant today, of course, although maven is an interesting alternative.  I've tried maven, but haven't been completely won over (yet -- but I would like to be).  I'll stick to talking about ant since that's still what is most common. 

Ant doesn't have built-in support for creating OSGi bundles the way it does for jar, war, and ear files. Maybe you're thinking, "Hey, OSGi bundles are just fancy jar files, so why not use the jar task?".  This is the approach taken by the sample applications that are part of the Event Server 2.0 release.  Take a look at the build.xml file for the helloworld sample application to see exactly how this works.   The main drawback of doing things this way is having to maintain the manifest file by hand.  (Note that I'm assuming we are not using some other tool, like an IDE, that helps with maintaining the manifest for now, just plain ant.)  For example, if you decide to implement your own adapter, you will likely start by adding some code to your project that looks like this:

import com.bea.wlevs.ede.api.Adapter;

public class MyAdapter implements Runnable, Adapter {
...
}

Import-Package:
    com.bea.wlevs.ede.api;version="2.0.0.0"

Managing these double imports, importing the class and importing the package, can become quite tedious. Fortunately, the OSGi community has been faced with the problem of easily creating bundles for awhile and there are some tools available that can make things easier when using ant.  One that I have been using is the bnd tool which was written by Peter Kriens. (Bnd was previously called Btool.) Here is the task from a sample application that I have been writing that uses bnd to create the application bundle:  

<target name="dist">
        <taskdef resource="aQute/bnd/ant/taskdef.properties"
                 classpath="lib/bnd-0.0.177.zip" />

        <bnd classpath="${output.dir}"
             eclipse="false"
             failok="false"
             exceptions="true"
             files="example.bnd"
             output="${dist.dir}/${bundle.file.name}" />
</target>

You can see from the taskdef element that I have downloaded the bnd zip file and placed it in the lib directory of my project.  The classpath attribute of the bnd task is set to the output directory where my compiled Java classes are located.  The compiled classes together with the example.bnd file constitute  the input to bnd which it uses to generate its output, in this case my application bundle.  Here is what my example.bnd file looks like:

Export-Package: com.bea.wlevs.example.event
Import-Package: javax.xml.bind;version="2.0",\
javax.xml.bind.annotation;version=2.0,\
javax.xml.bind.annotation.adapters;version=2.0,\
javax.xml.bind.attachment;version=2.0,\
javax.xml.bind.helpers;version=2.0,\
javax.xml.bind.util;version=2.0,\
com.bea.wlevs.configuration;version="2.0.0.0",\
com.bea.wlevs.configuration.application;version="2.0.0.0",\
com.sun.xml.bind.v2;version="2.0.2",\
*;resolution:=optional
Private-Package: com.bea.wlevs.example.*
Include-Resource: META-INF/spring=src/main/resources/META-INF/spring,\
META-INF/wlevs=src/main/resources/META-INF/wlevs
Bundle-SymbolicName: myexample

It's important to export the package containing the application's event classes so that server bundles -- like the EPL bundle -- can use them.  It's a best practice to always put the event classes in their own package, hence the single entry in the Export-Package section. 

I'm planning to have a  custom extension to the XML configuration for my application which is the reason for the JAXB imports.  The configuration extension feature of the Event Server uses JAXB.  This is an advanced feature which not every application needs to use.  In my case, I wouldn't have required any entries in the Import-Package section if I wasn't creating custom configuration.

The Private-Package section lists all of the classes for my sample since they need to be included in the application bundle.  The Include-Resource section pulls in my spring application context file and event server configuration files into the application bundle.

I have found bnd to be a useful tool.  If you try it with your own Event Server applications, let me know what you think. I should note that there is another tool called mangen for generating bundle manifests which I have not yet tried.  Developers using maven may also want to try the maven OSGi plug-in.  IDEs, like Eclipse, also have support for maintaining the OSGi manifest.  I will try to post about my experiences using Eclipse in the future.

Comments

• Hi Seth,

  I assume you are swhite in posting the comment in my blog entry about the new Eclipse-based tools?

  Good to meet you. Hope to meet you f2f soon.

  Although I found your posting above technically interesting, it seems to me that the Eclipse/WTP-based tools I've been working on take a lot of the pain out of managing the OSGi bundle meta info (manifest, runtime control info, build, etc). But I guess that view is not surprising to you :).

  Posted by: slewis on August 22, 2007 at 9:16 PM