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 >>> >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com > ----- Mike Van -- View this message in context: http://karaf.922171.n3.nabble.com/PROPOSAL-Towards-Karaf-3-0-0-tp3158763p3163632.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
