On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski <[EMAIL PROTECTED]> 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?
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 classloaders 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 implementation. 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 > http://www.JacekLaskowski.pl > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
