Re: Geronimo specs jars in OSGi
It's been a year IIUC servicemix has done something so the specs that have this discovery pattern solve the problem somehow. Now we have a jaxws 2.2 spec with the same problem. I think its silly to have the osgi-usable version of the spec far away from the spec source code. Can we revisit this discussion? I'd need to review what the servicemix bundles actually do but I'm pretty much in favor of having the geronimo spec jars work in osgi unchanged. If that's really unacceptable I'd suggest releasing two artifacts, one a working osgi bundle the other a non-osgi plain jar. thanks david jencks On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) 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. 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 ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
IMO, if we can release a single jar that has the OSGi mechanism in it that would also pass the TCK, then, to me, that is preferred.Thus, my suggestion would be to take something that we DO have the tck for (jaxws 2.1 or saaj or something), add the OSGi stuff to it, and run the tck's to see what happens. Dan On Tue June 16 2009 1:38:49 pm David Jencks wrote: It's been a year IIUC servicemix has done something so the specs that have this discovery pattern solve the problem somehow. Now we have a jaxws 2.2 spec with the same problem. I think its silly to have the osgi-usable version of the spec far away from the spec source code. Can we revisit this discussion? I'd need to review what the servicemix bundles actually do but I'm pretty much in favor of having the geronimo spec jars work in osgi unchanged. If that's really unacceptable I'd suggest releasing two artifacts, one a working osgi bundle the other a non-osgi plain jar. thanks david jencks On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) 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. 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 ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Geronimo specs jars in OSGi
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? 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 -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Geronimo specs jars in OSGi
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/
Re: Geronimo specs jars in OSGi
On Wed, Apr 16, 2008 at 5:49 PM, David Jencks [EMAIL PROTECTED] wrote: I'd like to see an example in action before I commit myself but so far I don't see any problems with this. I assume you have already or will soon verify this doesn't cause problems with the tck :-) Fair enough ;-) I may ping someone, as I've never worked on the TCK so far. I wonder if a package name with osgi in it somewhere would be more appropriate? Agreed. There are some specs (jacc for instance) that use a system property to figure out what to create. I've always thought this was a less than brilliant idea and wonder if we can do something similar for those. I also wonder if there is a way to generalize the osgi method so it might work in some non-osgi environments. I'm looking forward to seeing what you have in mind. I guess you are talking about the PolicyConfigurationFactory in jacc. I suppose we could extend the mechanism to include searching through the META-INF/services/xxx stuff instead of simply relying on a system property. However, the mechanism I'm thinking about is quite specific to OSGi (at least in its implementation). thanks david jencks On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) 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. 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 ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
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
Re: Geronimo specs jars in OSGi
On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) 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. 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 ? I would prefer to have a virgin spec jar wrapped inside an OSGi bundle. Here the virgin factories would be overshadowed by the OSGi specific factories. I feel strongly about this but am willing to discuss it. Regards, Alan
Re: Geronimo specs jars in OSGi
On Apr 16, 2008, at 8:49 AM, David Jencks wrote: I'd like to see an example in action before I commit myself but so far I don't see any problems with this. I assume you have already or will soon verify this doesn't cause problems with the tck :-) I wonder if a package name with osgi in it somewhere would be more appropriate? There are some specs (jacc for instance) that use a system property to figure out what to create. I've always thought this was a less than brilliant idea and wonder if we can do something similar for those. I also wonder if there is a way to generalize the osgi method so it might work in some non-osgi environments. I'm looking forward to seeing what you have in mind. thanks david jencks On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) 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. 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 ? -1 technical veto These are spec jars and extending the behavior of these jars on an ad hoc basis is bad and possibly violates the licenses of the JSRs they implement. Regards, Alan
Re: Geronimo specs jars in OSGi
Sorry, I meant to say: On Apr 17, 2008, at 7:11 AM, Alan D. Cabrera wrote: On Apr 16, 2008, at 8:49 AM, David Jencks wrote: I'd like to see an example in action before I commit myself but so far I don't see any problems with this. I assume you have already or will soon verify this doesn't cause problems with the tck :-) I wonder if a package name with osgi in it somewhere would be more appropriate? There are some specs (jacc for instance) that use a system property to figure out what to create. I've always thought this was a less than brilliant idea and wonder if we can do something similar for those. I also wonder if there is a way to generalize the osgi method so it might work in some non-osgi environments. -1 technical veto These are spec jars and extending the behavior of these jars on an ad hoc basis is bad and possibly violates the licenses of the JSRs they implement. Regards, Alan
Re: Geronimo specs jars in OSGi
Do you mean your -1 only apply to extending the behavior of the spec in the J2EE environment, and does not apply to extending the behavior in an OSGi environment ? I'm not sure to completely understand your reasoning. On Thu, Apr 17, 2008 at 4:15 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: Sorry, I meant to say: On Apr 17, 2008, at 7:11 AM, Alan D. Cabrera wrote: On Apr 16, 2008, at 8:49 AM, David Jencks wrote: I'd like to see an example in action before I commit myself but so far I don't see any problems with this. I assume you have already or will soon verify this doesn't cause problems with the tck :-) I wonder if a package name with osgi in it somewhere would be more appropriate? There are some specs (jacc for instance) that use a system property to figure out what to create. I've always thought this was a less than brilliant idea and wonder if we can do something similar for those. I also wonder if there is a way to generalize the osgi method so it might work in some non-osgi environments. -1 technical veto These are spec jars and extending the behavior of these jars on an ad hoc basis is bad and possibly violates the licenses of the JSRs they implement. Regards, Alan -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
I've thought about this. The main problem is that you end up having two different jars for the spec, one being a plain jar and another one being an OSGi bundle. Both would not be compatible if the bundle embeds the spec jar, because non osgi environment would not be able to load the jar inside the bundle. Imho, creating two different jars would confuse the users and be more error prone. On Thu, Apr 17, 2008 at 4:10 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) 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. 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 ? I would prefer to have a virgin spec jar wrapped inside an OSGi bundle. Here the virgin factories would be overshadowed by the OSGi specific factories. I feel strongly about this but am willing to discuss it. Regards, Alan -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
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
Re: Geronimo specs jars in OSGi
On Apr 17, 2008, at 7:19 AM, Guillaume Nodet wrote: I've thought about this. The main problem is that you end up having two different jars for the spec, one being a plain jar and another one being an OSGi bundle. Both would not be compatible if the bundle embeds the spec jar, because non osgi environment would not be able to load the jar inside the bundle. Imho, creating two different jars would confuse the users and be more error prone. Non OSGi environments use the vanilla jar as they currently do. OSGi environments load the spec bundle. Doesn't seem confusing to me. On Thu, Apr 17, 2008 at 4:10 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) 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. 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 ? I would prefer to have a virgin spec jar wrapped inside an OSGi bundle. Here the virgin factories would be overshadowed by the OSGi specific factories. I feel strongly about this but am willing to discuss it. Regards, Alan -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
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/
Re: Geronimo specs jars in OSGi
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/
Re: Geronimo specs jars in OSGi
Sorry. This is for David's idea: I also wonder if there is a way to generalize the osgi method so it might work in some non-osgi environments. Another reason to wrap the spec jar in a bundle is that we won't be seen as extending the spec, something that is explicitly prohibited in the licensing of the JSRs. Regards, Alan On Apr 17, 2008, at 7:17 AM, Guillaume Nodet wrote: Do you mean your -1 only apply to extending the behavior of the spec in the J2EE environment, and does not apply to extending the behavior in an OSGi environment ? I'm not sure to completely understand your reasoning. On Thu, Apr 17, 2008 at 4:15 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: Sorry, I meant to say: On Apr 17, 2008, at 7:11 AM, Alan D. Cabrera wrote: On Apr 16, 2008, at 8:49 AM, David Jencks wrote: I'd like to see an example in action before I commit myself but so far I don't see any problems with this. I assume you have already or will soon verify this doesn't cause problems with the tck :-) I wonder if a package name with osgi in it somewhere would be more appropriate? There are some specs (jacc for instance) that use a system property to figure out what to create. I've always thought this was a less than brilliant idea and wonder if we can do something similar for those. I also wonder if there is a way to generalize the osgi method so it might work in some non-osgi environments. -1 technical veto These are spec jars and extending the behavior of these jars on an ad hoc basis is bad and possibly violates the licenses of the JSRs they implement. Regards, Alan -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
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
Re: Geronimo specs jars in OSGi
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. 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. 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
Re: Geronimo specs jars in OSGi
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.
Re: Geronimo specs jars in OSGi
On Thursday 17 April 2008, Alan D. Cabrera wrote: On Apr 17, 2008, at 7:19 AM, Guillaume Nodet wrote: I've thought about this. The main problem is that you end up having two different jars for the spec, one being a plain jar and another one being an OSGi bundle. Both would not be compatible if the bundle embeds the spec jar, because non osgi environment would not be able to load the jar inside the bundle. Imho, creating two different jars would confuse the users and be more error prone. Non OSGi environments use the vanilla jar as they currently do. OSGi environments load the spec bundle. Doesn't seem confusing to me. Well, it IS confusing when you have projects that are required to work in both OSGi and non-OSGi environments. Suddenly, they have to ship two versions of the same jar so downloads are bigger. They have to document when they can use one versus the other. You have to deal with users that don't read the docs and try to do something with the wrong one, etc... Not fun. There are also issues with maven and dependencies (must depend on the non-osgi for compiling, but the non-osgi for testing/shipping?), but that's a completely different issue. Dan On Thu, Apr 17, 2008 at 4:10 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) 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. 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 ? I would prefer to have a virgin spec jar wrapped inside an OSGi bundle. Here the virgin factories would be overshadowed by the OSGi specific factories. I feel strongly about this but am willing to discuss it. Regards, Alan -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Geronimo specs jars in OSGi
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. 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. Actually it may be a good idea. I think it would allow running multiple versions concurrently. This would be true for jaxb 2.0 / 2.1 I think. The reason is that the way I've done that, if you deploy a jaxb 2.1 spec jar, it could try to create a jaxb 2.0 implementation. However, using the whiteboard pattern, the implementation bundle would register its own factory in OSGi, while the spec jar would listen for compatible services. The benefit is that OSGi can check the service implementation wrt to classloader constraints and would not allow the jaxb 2.1 spec bundle to see a service implementing jaxb 2.0. This would only work if we use the versions on the packages, but it may be worth the extra work. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Geronimo specs jars in OSGi
In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) 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. 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 ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
I'd like to see an example in action before I commit myself but so far I don't see any problems with this. I assume you have already or will soon verify this doesn't cause problems with the tck :-) I wonder if a package name with osgi in it somewhere would be more appropriate? There are some specs (jacc for instance) that use a system property to figure out what to create. I've always thought this was a less than brilliant idea and wonder if we can do something similar for those. I also wonder if there is a way to generalize the osgi method so it might work in some non-osgi environments. I'm looking forward to seeing what you have in mind. thanks david jencks On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) 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. 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 ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
