I think we should get back to the real problems here. IIUC, problems are caused by a few bundles having strong requirements on the versions of the packages exported by the JRE. That's mostly caused by the ServiceMix specs themselves which use version ranges. If the specs are the only problematic bundles, that won't be a problem anymore when we switch to the newer version I've been talking about several times already (see [1]). If other bundles rely on some versions, we may want to remove those ranges and re-release the bundles.
I don't think hiding the JRE packages is a good solution for the following reasons: * people expect things provided by the JRE to work * we can't really hide only a few packages On the first point, I think that's a key point in having Karaf being considered as a plain OSGi container and not only as a runtime dedicated to a few Apache projects. On the second point, you need to be very cautious because for example hiding the Stax API has some effects when you want to use javax.xml.transform as there are dependencies from this pacakge to the stax api, so you need to hide those too. You end up hiding all JAXP, which in itself causes other problems. I don't think we are in a position to choose the versions for the packages. It has to be done by either the OSGi Alliance or the JCP, but it has to be a standard everybody can follow, so I'd avoid exporting the system packages with a non empty version. Using fragments may work, but I don't understand which problem that will solve as it has the same effect and drawbacks than exporting the packages using properties, just with an additional step for the user. If there are other problems, let's raise and discuss those, but I don't think this thread is being very constructive. [1] http://mail-archives.apache.org/mod_mbox/servicemix-dev/201111.mbox/%3CCAEQV%2BEH5ca0R6sJvCXEeiLGdTZa6v1H%3DPwLFQ6BdLp27BdwgRw%40mail.gmail.com%3E On Mon, Dec 26, 2011 at 16:04, Jean-Baptiste Onofré <[email protected]> wrote: > Hi all, > > We have currently an issue in Camel and CXF with the default jre.properties > and some exported packages (like JAXB, etc). > > Currently, by default, the jre.properties exports all packages from the JRE. > > I would like to propose a new approach: > 1/ remove packages with problem by default from the jre.properties > 2/ add a set of Karaf features (in bootFeatures by default) to install > bundles providing the packages (JAXB, etc) > > It's a quick workaround for next Karaf 2.2.6 and Karaf 3.0. > > We can find a more elegant solution. I have some solutions in mind: > - new properties in the jre.properties to define an "override" flag > - add a KARAF-INF/* files to define some behaviors (like overriding system > packages) > > Feel free to propose your ideas for this problem. > > Please: > [ ] +1 to remove the packages from the jre.properties and provide a set of > Spec/API features in Karaf > [ ] 0 > [ ] -1 for that (please provide arguments) > Ideas (if you have ;)): > > Thanks > Regards > JB > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
