if you are talking about spifly I'd rather avoid that since it perverts the semantics of ServiceLoader.
In Geronimo we have something that while untested and needing to be added to the boot class path reimplements ServiceLoader to work with the ProviderRegistry and make ServiceLoader work with osgi. This does only work with apis that actually use ServiceLoader rather than the ones that just sort of act like they do.... thanks david jencks On Jul 12, 2011, at 3:38 PM, Daniel Kulp wrote: > > The issue is less the impl version than it is the api version. The API > version is just "2.1", not 2.1.13. What happens if the system is exported > as > 2.1 and we then add a "real" osgi engabled version that is also 2.1? The > API's are exactly the same, is just the "FactoryFinder" class that is really > different. We DEFINITELY need to make sure we get the "osgi" version of the > 2.1 so it would find the 2.1.13 impl bundle. > > Kind of wondering if davidb's stuff in Aries would come into play better > here....... > > > Dan > > > On Tuesday, July 12, 2011 11:55:30 PM Christian Schneider wrote: >> I don`t really understand why it should not work to export the system >> package as the version it really is. >> So if the jdk 1.6 exports 2.1.0 for example we should export it as that. >> >> Then a bundle could still require the version 2.1.13 and it should then >> take a separate version from outside the jdk. >> >> Christian >> >> Am 12.07.2011 23:23, schrieb Daniel Kulp: >>>> javax.xml.bind;version=2.1, \ >>>> >>>> This way I was able to make sure that jaxb isn't provided as 0.0.0.0 >>>> which is usually picked up during >>>> resolving. Like Neil Bartlett mentions in his blog >>>> http://njbartlett.name/2011/02/09/uses-constraints.html >>>> >>>> I would suggest since the jre.properties are already split up between >>>> 1.5 and 1.6 java version >>>> to add those versions to the crucial parts of the jre.properties. >>> >>> But that doesn't actually work. If you NEED to get a JAXB 2.1.13 >>> installed into the JRE due to the fact that the version in anything >>> other than the latest JRE is buggy (leaks memory and locks >>> classloaders, for example), just doing that won't work. You need to >>> actual API jar that has the osgi extensions in it. >>> >>> Dan > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog > Talend - http://www.talend.com
