Thanks for the update Guillaume.
AFAIK:
- some issues are caused by SMX Specs and the version ranges used in. I
discussed with Gert about that today, to release a new version of SMX
Specs with a better version range definition. We are going to work on it
middle of this week.
- some Camel bundles reference directly to javax.xml.transform with a
"incorrect" version range (it's the case of camel-atom AFAIR), I will
take a look on these bundles.
- in CXF, I will take a deeper look, but CXF requires JAXB 2.2 explicitly.
For SMX Specs and Camel, I'm quite sure that we can fix it "easily".
For CXF, I don't know the impact and the origin of the JAXB 2.2 explicit
usage. I will discuss with Dan about that.
Regards
JB
On 12/27/2011 06:17 PM, Guillaume Nodet wrote:
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
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
