[jira] [Reopened] (CAMEL-8647) Make Camel OSGI Extender Subsystem-Aware

["Manuel Holzleitner (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-8647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Manuel Holzleitner reopened CAMEL-8647:
---------------------------------------

It seems that in change SHA: f058e02b00c27bec81ee813aee026e727cd1d33d the wildcard expression org.osgi.framework*;version="[1.5,2)", was removed and replaced by org.osgi.framework;version="[1.5,2)".

In camel-cxf the bundle plugin will create two import-package statements since it defines a org.osgi.framework;resolution:=optional in the camel.osgi.import property. Without the wildcard this leads to two import-package statements which prevents installing the camel-cxf bundle in an osgi container.

It seems that in SHA: ced83fe5b86a1861821ddefcc740c0ed3698a303we resolved the same issue in camel-spring by removing the import statement in the camel.osgi.import property. We could do the same for camel-cxf.

> 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)