Hm, I'm not sure. For example you set the javax.xml.bind to version 2.1.3 because that is the one used since update 4 you're still able to deploy the 2.1.13 next to it and define your dependencies to version [2.1.13, 2.2). This way you are sure you use the one you need. If you leave the jre to 0.0.0.0 it's the one used even though you required it to be 2.1.13.
regards, Achim Am 12.07.2011 23:23, schrieb Daniel Kulp: > On Tuesday, July 12, 2011 10:59:09 PM Achim Nierbeck wrote: >> I think the jaxb stuff is a very specific problem we have >> and I ran into that one quite a lot :-) >> >> my best practice has been to version the crucial part of the >> jre.properties. >> For example I did a versioning for jaxb like the following in the >> jre.properties: >> >> 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 > > > > >> >> Regards, Achim >> >> Am 12.07.2011 21:41, schrieb David Jencks: >>> I probably didn't explain my idea very well.... >>> >>> I was thinking that the base jre.properties might have >>> >>> javax.xml.bind >>> >>> in the jdk6 entry in it to indicate that it's using the jaxb 2.1 api and >>> implementation shipped with java 6. If you needed say osgi-friendly >>> jaxb 2.2 api and the separate snoracle implementation you could have a >>> kar indicating the geronimo jaxb 2.2 spec and (smx?) bundlized snoracle >>> 2.2 jaxb impl together with a "patch" properties with >>> >>> !javax.xml.bind >>> >>> which would have the effect of removing the entry from the jdk6 entry. >>> >>> So the purpose here is to provide a way to modify the effective >>> jre.properties by installing a .kar file rather than editing it by >>> hand. >>> >>> thanks >>> david jencks >>> >>> On Jul 12, 2011, at 12:33 PM, mikevan wrote: >>>> David, >>>> >>>> From my experience, the only time I need to use a negation operator in >>>> jre.properties is if I want to explictly show users (folks reading the >>>> jre.properties file) that my implementation of Karaf does not use that >>>> package. If I don't want a package from the jre to be used in my >>>> instance of Karaf, I simply exclude that package from the list of >>>> packages exported into karaf. >>>> >>>> Feel free to correct me if I'm wrong. :-) >>>> >>>> David Jencks wrote: >>>>> So it really seems like we need a way to incrementally modify at >>>>> least >>>>> jre.properties and possibly the boot delegation property. >>>>> >>>>> It isn't possible to use a fragment bundle with the framework as >>>>> host to change the (effective) jre.properties, is it? >>>>> >>>>> If that won't work maybe we can merge property files something like >>>>> >>>>> jre-<BSN>.properties merges with jre.properties. >>>>> >>>>> An entry like >>>>> >>>>> jdk6=javax.foo,\ >>>>> !javax.bar,\ >>>>> !javax.baz >>>>> >>>>> has the result of adding the javax.foo to the jdk6 exports and >>>>> removing >>>>> javax.bar and javax.baz. >>>>> >>>>> I think I saw someone claim recently that for the bootdelegation >>>>> property the framework already understands entries like >>>>> !com.sun.xml.bind so maybe for that property we can just merge >>>>> everything together into one string. >>>>> >>>>> thanks >>>>> david jencks >>>>> >>>>> On Jul 12, 2011, at 9:09 AM, Guillaume Nodet wrote: >>>>>> I disagree with that. Jaxb, stax and other libraries provided by >>>>>> the JRE work in OSGi afaik with the JRE implementation. People >>>>>> have complained in >>>>>> the past that the default karaf behavior did not allow them to >>>>>> leverage those technologies provided by the JRE, that's why we >>>>>> changed the exported >>>>>> packages to reflect what the JRE provides. For all the OSGi >>>>>> users that don't use CXF and don't require a specific stax >>>>>> implementation or something >>>>>> like that, I'd like to keep the current behavior. >>>>>> >>>>>> Note that when you get to the borders of the OSGi specs, >>>>>> everything is >>>>>> not >>>>>> clearly defined. Another problem is caused by the fact that the >>>>>> packages >>>>>> provided by the JRE are not versioned. I think the current >>>>>> behavior is the >>>>>> best one for a generic container, but I agree we have to tweak it >>>>>> for CXF or >>>>>> ServiceMix, so be it, I think that's the responsibility of those >>>>>> projects to >>>>>> do it, though Karaf could provided a good way to allow those >>>>>> modifications. >>>>>> >>>>>> On Tue, Jul 12, 2011 at 13:42, Daniel Kulp >>>>>> <[email protected]> >>>>>> >>>>>> wrote: >>>>>>> On Tuesday, July 12, 2011 7:28:57 AM Andreas Pieber wrote: >>>>>>>> Hey David, >>>>>>>> >>>>>>>> The problem isn't during assambling but to install e.g. CXF >>>>>>>> afterwards. Please start an empty Karaf 3.x and try to install >>>>>>>> the CXF features file. To make it run you have to modify the >>>>>>>> jre.properties and the bootdelegation to get it up running. >>>>>>>> And there is no way to do this automatically from your >>>>>>>> .kar/features.xml right now :( >>>>>>> That should be changing in CXF 2.4.2. The last holdup was a >>>>>>> bug in >>>>>>> Neethi's >>>>>>> OSGi manifest, but a new version of Neethi is under vote now. >>>>>>> With >>>>>>> that, >>>>>>> you >>>>>>> should be able to take a clean Karaf and deploy CXF. >>>>>>> >>>>>>> THAT said, IMO, the karaf jre.properties file should exclude >>>>>>> the >>>>>>> packages >>>>>>> that are known not to work in karaf. jaxb-api, stax-api, >>>>>>> saaj-api, >>>>>>> etc.... >>>>>>> Karaf should then contain a set of "API" features to install the >>>>>>> proper OSGi >>>>>>> versions of said API's. >>>>>>> >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>>> Kind regards, >>>>>>>> Andreas >>>>>>>> >>>>>>>> On Tue, Jul 12, 2011 at 12:05 AM, David Jencks >>>>>>>> <[email protected]> >>>>>>> wrote: >>>>>>>>> On Jul 11, 2011, at 5:26 AM, Andreas Pieber wrote: >>>>>>>>> <big snip> >>>>>>>>> >>>>>>>>>> * Karaf profiles & Kar files (IMHO this is one of the most >>>>>>>>>> important features for 3.x and not present in the issues >>>>>>>>>> by now; there had been considerable work on this by >>>>>>>>>> David, but still, we're missing a possibility to start >>>>>>>>>> e.g. CXF without modifying some files in etc) >>>>>>>>> I'm really hoping that 3.0.0 will have the minimal and >>>>>>>>> standard >>>>>>>>> assemblies created using kars/features rather than the old >>>>>>>>> style >>>>>>>>> maven-assembly-plugin. I haven't been able to work on this >>>>>>>>> for a >>>>>>>>> while >>>>>>>>> but i thought I left it in a state as least as functional as >>>>>>>>> the >>>>>>>>> old-style servers. The only bit I recall as missing is the >>>>>>>>> legal >>>>>>>>> files. >>>>>>>>> >>>>>>>>> What are you looking for to start e.g. cxf? IIRC you can >>>>>>>>> assemble a server including a cxf feature as a boot >>>>>>>>> feature, or add it in later as >>>>>>>>> a regular feature.... >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> david jencks >>>>>>> -- >>>>>>> Daniel Kulp >>>>>>> [email protected] >>>>>>> http://dankulp.com/blog >>>>>>> Talend - http://www.talend.com >>>> ----- >>>> Mike Van >>>> -- >>>> View this message in context: >>>> http://karaf.922171.n3.nabble.com/PROPOSAL-Towards-Karaf-3-0-0-tp3158 >>>> 763p3163632.html Sent from the Karaf - Dev mailing list archive at >>>> Nabble.com. -- ----- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
