Sahoo's Blog

Sahoo is an engineer at Sun Microsystems, working in Java EE application server development engineering group. He contributes to glassfish project. Besides that he is also involved in writing a portability checking tool for Java EE applications. Prior experiences include working in C++ language binding for an object database management system, developing enterprise applications using CORBA & messaging middleware. Although his full name is Sanjeeb Kumar Sahoo, he prefers to be called by his last name *Sahoo*.

Updated instructions to use OpenJPA in GlassFish

Layout of OpenJPA installation has changed since I last blogged about using OpenJPA in GlassFish. Let's say one installs OpenJPA in a directory called ${OPENJPA_HOME}. Earlier (I am talking about the days when OpenJPA was still in Apache incubator), all the jars would live under ${OPENJPA_HOME}/lib directory. Now, things have changed. The primary artifact, openjpa-${version}.jar, which contains classes built out of OpenJPA codebase lives under ${OPENJPA_HOME}; where as all the other library jars live under ${OPENJPA_HOME}/lib. So, all you need to do is to copy the appropriate jars like this:

 cp ${OPENJPA_HOME}/openjpa*.jar ${OPENJPA_HOME}/lib/*.jar ${GLASSFISH_HOME}/domains/domain1/lib 

For issues, please don't hesitate to contact us at users (at) glassfish.dev.java.net

Bug in Bundle.getResource() in Knopflerfish?

I was running a simple test on multiple OSGi platforms. I am seeing some difference in behavior when I run it on Knopflerfish #2.0.3. Upon investigation, I observed that Bundle.getResource() implementation on Knopflerfish does not use the parent class loader of the bundle even when I set org.osgi.framework.bootdelegation=*.

Here is a simple code that I used to test my theory:

public class Activator implements BundleActivator{


    public void start(BundleContext context) throws Exception {

        Class libClazz = context.getBundle().loadClass("sahoo.Library");

        System.out.println("libClazz = " + libClazz);

        URL libRes = context.getBundle().getResource("sahoo/Library.class");

        System.out.println("libRes = " + libRes);

    }

...

The above code prints non-null value for libClazz, but a null value for libResource. If Bundle.loadClass("sahoo.Library") could load the class, how could Bundle.getResource("sahoo/Library.class") return null? It works as expected in other OSGi implementations.

To ensure that sahoo.Library.class is available in the parent class loader, I wrote a Main class which creates a ClassLoader that has both the knopflerfish framework.jar and my library.jar in search path. I then use that classloader to launch knopflerfish.

Has anyone else faced similar issues? I think this is a serious bug in knopflerfish. I tried to get a confirmation by reporting it in their forum, but no luck. I also tried using the dev forum, but no difference. Is there a better way to ask them questions? I don't know. So I thought I would document what I observed.

GlassFish V3 on OSGi - Part I

I guess by now you have heard the big news coming out of GlassFish community. We have put back initial code that enables GlassFish to run on an *OSGi* R4 platform. Felix is currently our default OSGi runtime. I am assuming you have either read Jerome's blog or Eduardo's posting in The Aquarium. If you have not, I suggest you read them first. Jerome and Eduardo have explained some of the rational behind this change and what to expect in coming days. Now some details not covered there:

The following picture tries to give an idea as to how the runtime looks like when GlassFish is running on an OSGi platform:

All our GlassFish modules including the Java EE APIs are packaged as OSGi bundles. Some of you may wonder what's HK2's role here. HK2 has following layers, viz:
module layer - responsible for class loading and life cycle management
component layer - which is responsible for component registration, injection, outjection, etc.
config layer - responsible for configuring components by reading data from XML file. The XML file can be transactionally updated to reflect changes in component.
A simple class diagram that shows some of the HK2 abstractions (except those of config layer) is shown below:

We have implemented HK2' module layer APIs on OSGi by delegating to OSGi module layer. HK2's component layer and config layer relies on HK2's module APIs. Once those APIs are available, it is not that difficult to make those two layers available as OSGi bundles. Except for cases like URLStreamHandler registration, GlassFish modules do not use OSGi APIs directly; they use HK2 module APIs which are available on both the runtimes. That allows them to run unchanged on both the runtimes. Some other day, I shall talk about the service mapper.

Last, but not the least, I want to thank Felix community for the excellent support that they provide in their forum. It's not just the framework that I found easy to use. Their maven-bundle-plugin, which wraps Peter Krien's bnd tool, makes life of maven users so much easier.

Now, before you ask me, let me preempt you:

Why did we take this approach?
A lot of GlassFish code was already written, so we wanted an easier migration path without disrupting our schedule.

What are the benefits of this approach?
Well, it allows us to experiment on both the modes. Theoretically, given another compatible module system, we can switch to using that with relative ease.

What are the drawbacks of this approach?
By limiting ourselves to HK2 APIs, we are not able to take advantage of rich module management APIs that OSGi provides.

Will we continue to support both the modes?
Not very long. But, that does not mean that HK2 will vanish. As Jerome explains in his blog, HK2 will continue to provide component layer and config layer.

How does GlassFish use bundle repository?
That is something I have to investigate next.

What other OSGi implementation does it run on?
Theoretically speaking, since our code is written against R4 spec, it should run in any compliant implementation - it's a matter of configuration I would say. We have tried all major three and it works. More on this to follow in time to come. Felix is currently our default platform - it is distributed as part of our runtime.

What's next?
This is just the beginning. We have so many things lined up in this area. I have a long TODO list which I have to prioritize. We hope you shall provide constructive feedback to make it better. As Eduardo mentioned in his blog, please wait for the builds to stabilize.

June 2008

Search this blog:

Categories

Archives

May 2008
April 2008
January 2008
November 2007
November 2006
October 2006
July 2006
May 2006
March 2006
January 2006
December 2005

Recent Entries

Updated instructions to use OpenJPA in GlassFish

Bug in Bundle.getResource() in Knopflerfish?

GlassFish V3 on OSGi - Part I

This work is licensed under a Creative Commons License.