geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Geronimo specs jars in OSGi
Date Thu, 17 Apr 2008 14:04:15 GMT
On Thursday 17 April 2008, Jacek Laskowski wrote:
> On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <> 
> > 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?

I'll provide an example that I'm running into....   In my OSGi app, if I 
do something like MessageFactory.newInstance() to create a new SAAJ 
MessageFactory, the current spec implementations check the 
contextClassLoader for the 
META-INF/services/javax.xml.soap.MessageFactory file.  Outside of OSGi, 
that would be properly picked up from the implementation jar.   Inside 
OSGi, the file isn't available, so it defaults to whatever version is 
hardcoded into the saaj-api jar, which may not even be available.  
Basically, in OSGi, you cannot have multiple jars/bundles export the 
META-INF/services directory.   That won't work.  Thus, the whole 
META-INF/services thing that all the specs rely on just doesn't work.  
(IMO: this is a big deficiency in the OSGi spec, but that's my opinion)

The goal is to allow the "default" that is hard coded into the saaj-api 
jar to be replaced/augmented at runtime based on information the bundle 
listener finds in the other bundles that are available.  Thus, when we 
call MessageFactory.newInstance(), it would probably still check 
META-INF/services/javax.xml.soap.MessageFactory (so someone COULD put 
that in their application bundle and possibly get it), but if not found, 
use a default value that can actually have a chance of succeeding.


> > 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.
> Jacek

J. Daniel Kulp
Principal Engineer, IONA

View raw message