camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Schneider (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CAMEL-8647) Make Camel OSGI Extender Subsystem-Aware
Date Tue, 11 Aug 2015 09:11:46 GMT

    [ 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-zNO9rEUXNOQ4ZH4Qw4FGseoR4zxqcTuQ@mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message