geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <>
Subject Re: Geronimo specs jars in OSGi
Date Thu, 17 Apr 2008 13:54:55 GMT
On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski <> wrote:
> On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <> wrote:
>  > However, lots of these spec jars define factories (stax, saaj for example)
>  > that use the META-INF/services/ discovery mechanism to find an
>  > implementation of the spec and load it.  This mechanism does not fit well in
>  > OSGi (really, it does not), mainly because usually, the classloader
>  > containing the spec jar will not contain the implementation.
>  >  I'd like to work on these spec jars so that they will contain an OSGi
>  > BundleActivator that would change the behavior of these factories when
>  > deployed in an OSGi environment (without changing the behavior in other
>  > case).  The idea is that the activator would scan OSGi bundles when they are
>  > started to find META-INF/services and populate a map that would be used by
>  > the factory when creating an object before using the standard mechanism.
>  Just to ensure I'm following, you are about to create a activator that
>  would be a bundle listener (o.o.f.BundleListener) and whenever a
>  bundle is registered the activator will scan it for provided services?
>  Can you explain how osgi works now without these
>  META-INF/services-based services? Doesn't it use them at all?

This is the tricky part.  The work we've done on the specs so far
means that each spec
is an OSGi bundle.   In OSGi, each bundle has each own classloader and
are not organized in a simple tree: if bundle A requires bundle B and
bundle B requires
bundle C, it does not mean that C will be accessible to A.  Following so far ?
So, let's say I create a bundle that references the Stax Api.
My bundle will have the geronimo stax api in its classpath.  The stax
implementation that
I deploy will also have the stax api in its classpath, but it won't be
available to either
the the stax api or my bundle.
The problem happens when the stax api needs to find and create the
Usually, the existing code won't be able to do that at all, because
the META-INF/services
and the implementation class are not available from the stax api classloader.
One way to work around that is (if the api uses the thread context
classloader) to make sure
my bundle includes the implementation in its classloader and make sure
the thread context
classloader is correctly set.  This usually involves copying the
META-INF/services/xx stuff
in our bundle and explicitely referencing the implementation to make
sure the classloader
includes it.

The problem is that it's a bit annoying to do that on all the bundles
and it does prevent
swicthing implementations.

So now, there is no need to reference the implementation from the
bundle.  The spec jar bundle
activator will use OSGi to find the META-INF/services/ entries each
time a bundle is installed
and if an implementation is used, will load the class through OSGi
API, using the implementation
bundle classloader instead of the spec jar classloader.

>  > The only real difference compared to what we currently have would be the
>  > addition of a package named org.apache.geronimo.specs.stax (for example)
>  > that would contain the needed classes (i suppose two classes), and the
>  > modification of the factories to delegate to one of these class before using
>  > the standard behavior (the class would do nothing if not deployed in an OSGi
>  > environment).
>  >  Has anyone any objection with such an enhancement in the specs jar ?
>  Unless I'm mistaken it shouldn't cause any troubles on non-osgi
>  environments and big +1 for the upcoming changes.

Exactly, the behavior should be exactly the same in non OSGi environment.

>  Jacek
>  --
>  Jacek Laskowski

Guillaume Nodet

View raw message