Hi Martin,
A simple workaround is to add camel-cxf as boot feature.
What CXF version are you using ?
I will take a look.
Regards
JB
On 13/12/2018 14:30, Martin Lichtin wrote:
Has anyone tried running
feature:install -v camel-cxf
? It has a big unwanted effect of refreshing many core Karaf bundles,
due to the fact that Camel CXF classes still import
"org.apache.aries.blueprint.reflect" (see also KARAF-4932).
Refreshing bundles:
org.apache.aries.blueprint.cm/1.1.0 (Wired to
org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
org.apache.aries.blueprint.core/1.8.3 (Attached fragments changed:
[org.apache.aries.blueprint.core.compatibility/1.0.0])
org.apache.karaf.bundle.blueprintstate/4.1.7 (Wired to
org.apache.karaf.bundle.core/4.1.7 which is being refreshed)
org.apache.karaf.bundle.core/4.1.7 (Wired to
org.apache.karaf.shell.core/4.1.7 which is being refreshed)
org.apache.karaf.config.core/4.1.7 (Wired to
org.apache.karaf.shell.core/4.1.7 which is being refreshed)
org.apache.karaf.deployer.kar/4.1.7 (Wired to
org.apache.karaf.kar.core/4.1.7 which is being refreshed)
org.apache.karaf.diagnostic.core/4.1.7 (Wired to
org.apache.karaf.shell.core/4.1.7 which is being refreshed)
org.apache.karaf.event/4.1.7 (Wired to
org.apache.karaf.shell.core/4.1.7 which is being refreshed)
org.apache.karaf.features.command/4.1.7 (Wired to
org.apache.karaf.shell.core/4.1.7 which is being refreshed)
org.apache.karaf.instance.core/4.1.7 (Wired to
org.apache.karaf.features.command/4.1.7 which is being refreshed)
org.apache.karaf.jaas.blueprint.config/4.1.7 (Wired to
org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
org.apache.karaf.jaas.command/4.1.7 (Wired to
org.apache.karaf.shell.core/4.1.7 which is being refreshed)
org.apache.karaf.kar.core/4.1.7 (Wired to
org.apache.karaf.features.command/4.1.7 which is being refreshed)
org.apache.karaf.log.core/4.1.7 (Wired to
org.apache.karaf.shell.core/4.1.7 which is being refreshed)
org.apache.karaf.package.core/4.1.7 (Wired to
org.apache.karaf.shell.core/4.1.7 which is being refreshed)
org.apache.karaf.service.core/4.1.7 (Wired to
org.apache.karaf.shell.core/4.1.7 which is being refreshed)
org.apache.karaf.shell.commands/4.1.7 (Wired to
org.apache.karaf.shell.core/4.1.7 which is being refreshed)
org.apache.karaf.shell.console/4.1.7 (Wired to
org.apache.karaf.shell.core/4.1.7 which is being refreshed)
org.apache.karaf.shell.core/4.1.7 (Wired to
org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
org.apache.karaf.shell.ssh/4.1.7 (Wired to
org.apache.karaf.shell.core/4.1.7 which is being refreshed)
org.apache.karaf.system.core/4.1.7 (Wired to
org.apache.karaf.shell.core/4.1.7 which is being refreshed)
org.ops4j.pax.logging.pax-logging-log4j2/1.10.1 (Should be wired
to: javax.mail/1.4.5 (through
[org.ops4j.pax.logging.pax-logging-log4j2/1.10.1] osgi.wiring.package;
filter:="(osgi.wiring.package=javax.mail)"; resolution:=optional),
stax2-api/3.1.4 (through
[org.ops4j.pax.logging.pax-logging-log4j2/1.10.1] osgi.wiring.package;
filter:="(osgi.wiring.package=org.codehaus.stax2)"; resolution:=optional))
The compatibility bundle (it's only a fragment) is now loaded with
dependency="true" (Karaf 4.0 did not have this flag), perhaps this is
triggering the effect..
Obviously if anyone has a solution, let me know. I just see, it's also
been reported in KARAF-5469
- Martin
PS: JB, see above a case of pax-logging restarting, as it has so many
optional imports.
