camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CAMEL-8647) Make Camel OSGI Extender Subsystem-Aware
Date Thu, 16 Apr 2015 14:43:58 GMT


ASF GitHub Bot commented on CAMEL-8647:

GitHub user manuelh9r opened a pull request:

    CAMEL-8647: Make Camel OSGI Extender Subsystem-Aware

    Pull Request for

You can merge this pull request into a Git repository by running:

    $ git pull master

Alternatively you can review and apply these changes as the patch at:

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #491
commit 139bd5de94b1a52e190d77b0801061a1d468d811
Author: Manuel Holzleitner <>
Date:   2015-04-16T14:39:42Z

    CAMEL-8647: Make Camel OSGI Extender Subsystem-Aware


> Make Camel OSGI Extender Subsystem-Aware
> ----------------------------------------
>                 Key: CAMEL-8647
>                 URL:
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-core
>            Reporter: Manuel Holzleitner
> 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]

This message was sent by Atlassian JIRA

View raw message