Details
-
Type:
Improvement
-
Status: Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 2.16.0
-
Component/s: camel-core, osgi
-
Labels:None
-
Patch Info:Patch Available
-
Estimated Complexity:Unknown
-
Flags:Patch
Description
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.
Attachments
Issue Links
- relates to
-
CAMEL-9073 Installing camel-cxf on Karaf with Java 7 does not work
-
- Resolved
-