Just a question, as you know CXF better than I:

- why CXF can't use the packages provided by the JRE (assuming we use JRE 1.6) ?

Regards
JB

On 12/27/2011 03:18 PM, Christian Schneider wrote:
Hi JB,

I think that should not be a big problem.

We currently only support three different runtimes 1.5, 1.6 and 1.7. So
it should not be a lot of work to provide features for them.
We could also support the jre version as a kind of switch for feature
files. So you can define bundles that will only be installed for certain
jre versions.
A bit like in maven. So then one feature would be fine for all 3 versions.

Christian


Am 27.12.2011 13:42, schrieb Jean-Baptiste Onofré:
As discussed on IRC, my concern with your solution is about multiple
JRE support: different versions, different providers (IBM, Sun/Oracle)
etc.

It's really painful to create fragments bundle per JRE, and know which
one to deploy.

Regards
JB

On 12/26/2011 09: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






--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply via email to