Hi Guillaume,
I think that Christian consider that it's easier for an user.
However, I think that profiles is the good approach (you remember, we
discussed about diff/merge/patch lifecycle).
The profile can apply a patch on the jre.properties.
Let me progress on the profiles implementation.
Regards
JB
On 12/27/2011 05:53 PM, Guillaume Nodet wrote:
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
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
