On Thursday 17 April 2008, Jacek Laskowski wrote: > On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <[EMAIL PROTECTED]> 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?
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. Dan > > > 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 [EMAIL PROTECTED] http://www.dankulp.com/blog
