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.
