On Jul 12, 2011, at 2:28 PM, Daniel Kulp wrote: > On Tuesday, July 12, 2011 12:41:18 PM David Jencks wrote: >> 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. > > The question I have is how possible is it to do that without restarting > Karaf, > or would restarting Karaf after installing the "jaxb kar" be required? Would > there be an impact on existing things running using jaxb?
I don't see how its plausible to make changes in what the framework exports without restarting karaf. Can you refresh the framework? Is this different from restarting? I actually hope or expect we'll make it so easy to assembly your own custom server with maven that the normal use case will be that rather than installing stuff into a running instance of someone else's idea of what karaf should be. david jencks > > Dan > > > > >> >> 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 <dk...@apache.org> >>>>> >>>>> 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 >>>>>>> <david_jen...@yahoo.com> >>>>>> >>>>>> 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 >>>>>> dk...@apache.org >>>>>> 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-tp315876 >>> 3p3163632.html Sent from the Karaf - Dev mailing list archive at >>> Nabble.com. > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog > Talend - http://www.talend.com