[
https://issues.apache.org/jira/browse/CAMEL-8647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14548101#comment-14548101
]
ASF GitHub Bot commented on CAMEL-8647:
---------------------------------------
GitHub user manuelh9r opened a pull request:
https://github.com/apache/camel/pull/520
CAMEL-8647: Fix duplicated import-package statement for org.osgi.fram…
It seems that in change f058e02b00 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 ced83fe5b86 we 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.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/manuelh9r/camel master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/camel/pull/520.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #520
----
commit 6ba4ac6ad5273668ca893f3be5464cf2ffdd455b
Author: Manuel Holzleitner <[email protected]>
Date: 2015-05-18T14:36:07Z
CAMEL-8647: Fix duplicated import-package statement for org.osgi.framework
in camel-cxf manifest
----
> 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)
