Just to remind you that the purpose of this thread was to disucss --> [PROPOSAL] Towards Karaf 3.0.0
On Wed, Jul 13, 2011 at 1:26 AM, David Jencks <david_jen...@yahoo.com> wrote: > 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 > >
