In principle this seems like a very promising idea. I have never used a fragment bundle hosted by the system bundle. Can you outline how this would work? Would a system bundle refresh be needed to pick up the fragment? What would trigger the refresh? When? Only on the first startup or every time karaf starts?
I still thought the karaf-activator idea was proposed because there is no way to make completely bundleized spec jars work due to either xerces or xalan in the jre, so I'm not convinced that we won't need to always export the spec packages. However this would at least give us a fairly manageable way to set the package versions on the specs. thanks! david jencks On Dec 26, 2011, at 12:09 PM, Christian Schneider wrote: > I am +1 for not exporting the packages by default in the system bundle. > > I also have an idea how we could create an environment for people who do not > want the improved bundles. > > I propose that we provide two (sets of) features: > > 1. jaxb, stax, ... from jre > These are just fragment bundles to the system bundle that export the > packages. So by installing these bundles > you get the current behaviour of karaf > > 2. improved jaxb, stax, .. like used for servicemix, cxf, camel > These will make cxf and camel behave like expected > > The reason why I prefer this aproach over the current setup of simply > exporting the packages from the system bundle is that it makes > installing cxf and camel much easier and at the same time also allows people > to use "pure OSGi" like Guillaume wrote. > > Christian > > Am 26.12.2011 16:04, schrieb Jean-Baptiste Onofré: >> 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 > > > -- > > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com >
