[
https://issues.apache.org/jira/browse/CAMEL-8647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14681485#comment-14681485
]
Christian Schneider commented on CAMEL-8647:
--------------------------------------------
I think the uses constraint violation could be an error in the karaf system
package exports. It does not seem to define a version for the export. CXF
requires a min version of 1.2.0 while spring does not require a special
version. So the spring import matches the felix system package export while the
cxf one can only match the export from the special annotation bundle.
If cxf is installed first then the javax.annotation package is available when
camel is installed. So it is used. If camel is installed first it wires to the
felix package which causes the usage constraint.
So there are several options to fix this:
1. Remove the system package export in karaf
2. Set the correct export version for the system package export in karaf
3. Add the javax.annotation-api bundle to the camel feature
The first two options can be done by end users.
The 3rd is probably the best for us as we can solve the issue in camel alone.
WDYT?
> Make Camel OSGI Extender Subsystem-Aware
> ----------------------------------------
>
> Key: CAMEL-8647
> URL: https://issues.apache.org/jira/browse/CAMEL-8647
> Project: Camel
> Issue Type: Improvement
> Components: camel-core, osgi
> Reporter: Manuel Holzleitner
> Assignee: Christian Schneider
> Fix For: 2.16.0
>
>
> I would like to propose a change to the camel-core extender for components,
> type converters, etc. to allow to use camel-core with subsystem-aware
> OSGI-containers to separate components and it’s dependencies into subsystems.
> This would allow to isolate applications and camel components (incl. it’s
> libraries) from each other. I.e. you could run HTTP-related components that
> rely on (otherwise conflicting) HTTP client libs in different versions next
> to each other.
> Currently, the BundleTracker in the camel-core extender is initialized on its
> own BundleContext and therefore does not receive any events from started
> camel component bundles that reside in subsystems. I discussed a solution to
> make the camel extender subsystem-aware in the Aries mailinglist [1], who
> already conducted this change in the blueprint implementation.
> This approach from the upcoming R6 DS 1.3 spec was proposed by David Jencks
> as a solution:
> - use the system bundle (bundle 0) to look for events of interest, so you
> see them for all bundles
> - have the extender register an extender capability
> - have bundles that need extension register a matching extender requirement
> - the extender should only extend bundles with no extender requirement or
> ones with extender requirements wired to their own extender capability.
> I implemented this approach accordingly for camel and tested it in
> combination with the Aries subsystem module. Any feedback to this would be
> very much appreciated.
> [1]
> http://mail-archives.apache.org/mod_mbox/aries-user/201503.mbox/%3CCADE24oihG71CdC=pz-zno9reuxnoq4zh4qw4fgseor4zxqc...@mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
