Cleaner, but the main problem is that it does not work with legacy code. Will you rewrite the jaxb2 implementation to do that instead of using the stax factory ? ;-) We've got tons of legacy stuff that use stax, or jaxb2 and i don't see rewriting the whole lot as realistic. it would also mean having an OSGi specific thing everywhere we use a factory from a j2ee spec :-(
On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > > > On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote: > > > > 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. > > > > I think, just my personal opinion, that scouring bundles' META-INF/services > entries is kinda klunky. Could we not use a service/whiteboard approach > that is common in OSGi? When in Rome, do as the Romans do. > > Let's assume that we go with the virgin spec jar wrapped in a bundle > paradigm I spoke of in a previous post. Here the bundles that use the stax > api would register stax api service implementations. The stax api would > catch those service registrations and properly configure the factory. A > bit cleaner imo and you don't have to search every bundle. > > > Regards, > Alan > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
