On Thu, Apr 17, 2008 at 5:05 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > I must be missing something. That legacy code would not need to change. > The whiteboard pattern only obviates the need to scavenge every bundle the > META-INF/services entries. The rest works as you say.
You mean, having each implementation jar register a service in the osgi registry ? Yeah, doable. Just requires more work. > > But, as I think about it some more, I'm thinking that this is over > engineering it. Let's drop this aspect of the thread. > > I still feel strongly that the virgin spec jar should be wrapped in a > bundle. I can understand that there is legal problems changing the behavior of the spec, but I'm not sure how repackaging it would lead to a different conclusion: the behavior would still be changed. If we do use a separate bundle, I would lean towards removing the existing manifest headers so that there is no confusion, but I don't really see the benefit of doing this. The added code would not run in a non-osgi environment, so there is not much risk there. > > > Regards, > Alan > > > On Apr 17, 2008, at 7:54 AM, Guillaume Nodet wrote: > > > > i don't mean legacy jars but legacy *code*. > > If you have a jar which uses > > javax.xml.stream.XMLInputFactory.newInstance() > > somewhere deep in the code, I don't really understand how using a > whiteboard > > pattern will solve the problem. I'm not trying to make people rewrite > > everything, > > but rather make things easy for them to deploy their application and keep > the > > behavior they are used to see. > > it could be you want to deploy the jaxws-ri, jersey or any other xml > related > > technology that could use SAAJ, Stax, Jaxb2 ... > > > > > > On Thu, Apr 17, 2008 at 4:40 PM, Alan D. Cabrera <[EMAIL PROTECTED]> > wrote: > > > > > IIUC, they're not entirely legacy, i.e. you at least put in the OSGi > > > manifest entries. You do so using the maven/BND plugin I suspect. > > > > > > This strikes me as a common service discovery pattern. Off the top of > my > > > head I would think that a plugin that adds the necessary BundleActivator > for > > > legacy modules would be useful. > > > > > > Another thought that flashed in my head is that in a buttoned down > > > environment getting service notifications might be easier than getting > > > access to every Bundle's class loader. > > > > > > > > > Regards, > > > Alan > > > > > > > > > > > > On Apr 17, 2008, at 7:30 AM, Guillaume Nodet wrote: > > > > > > > > > > > > > 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/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Cheers, > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > > > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
