I'm not sure to understand what the benefit of having to deploy some fragments and refreshing the framework instead of modifying the jre.properties is. Could you please enlighten me ? I really fail to see the difference.
On Tue, Dec 27, 2011 at 00:45, Christian Schneider <[email protected]> wrote: > You just have to install a fragment bundle that exports the needed packages. > From this moment on the packages will be available to the other bundles. So > a low start level would > be good but the user will get meaningfull error messages even when the > bundle is not installed. > > So if we document that the users should install one of the two features > there should not be much confusion. > > Christian > > > Am 27.12.2011 00:15, schrieb David Jencks: > >> 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 >>> > > > -- > > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
