Hi Dan, Krzysztof, I didn't look at the cxf code itself and as I didn't see any wiring problem when I tested cxf with karaf-3.0.3, I just looked at its manifest which is optionally importing org.apache.aries.blueprint.reflect and the availability of this package on karaf. I didn't know that this package was intentionally not-exposed. So, I agree with Dan. Thanks for the clarification. regards, aki
2015-02-12 18:37 GMT+01:00 Daniel Kulp <[email protected]>: > > Three thoughts: > > 1) This has been there for at least a few months and this was the first I’ve > seen it (and there still isn’t a JIRA filed…). It’s definitely not a > regression from the last release. > > 2) We have a viable workaround via the compat bundle > > 3) Even with the workaround, I strongly discourage people from configuring > the jetty servers in their blueprint files. Since the servers are “shared”, > you get into a “first bundle to create the port has the configuration that > wins” situation which can be unpredictable and error prone. If bundles with > different services start up in different order, you can get strange behavior. > Configuring the port via the files in /etc would be better (and also then > puts the job of configuring the ports into the hands of the administrator, > not the app developer, and puts it with the configs for the pax-web and > others). > > Anyway, it IS a bug we should fix, but not something I’d hold the release up > for at this point. > > Dan > > > >> On Feb 12, 2015, at 11:58 AM, Krzysztof Sobkowiak >> <[email protected]> wrote: >> >> Hi Aki >> >> Indeed, it works. But I had to install the compatibility bundle >> separately. Which Karaf/ServiceMix version did you use to test this? >> Which Karaf feature have you installed? Have you installed the bundle >> separately too? The bundle is not installed per default in Karaf now. >> >> Thanks for the hint :-) >> >> Regards >> Krzysztof >> >> >> On 12.02.2015 15:31, Aki Yoshida wrote: >>> But this org.apache.aries.blueprint.reflect is available from >>> org.apache.aries.blueprint.core.compatibility, so it isn't a problem >>> of CXF, no? >>> >>> karaf@root()> exports | grep org.apache.aries.blueprint.reflect >>> >>> org.apache.aries.blueprint.reflect >>> | 1.0.0 | 14 | >>> org.apache.aries.blueprint.core.compatibility >>> >>> karaf@root()> headers 14 >>> >>> Apache Aries Blueprint Core Compatiblity Fragment Bundle (14) >>> ------------------------------------------------------------- >>> ... >>> >>> Export-Package = >>> org.apache.aries.blueprint.container; >>> uses:="org.apache.aries.blueprint.di, >>> org.apache.aries.blueprint.reflect"; >>> deprecated=true; >>> version=1.0.0, >>> org.apache.aries.blueprint.di;uses:=org.apache.aries.blueprint.container;deprecated=true;version=1.0.0, >>> org.apache.aries.blueprint.reflect;deprecated=true;version=1.0.0 >>> >>> >>> karaf@root()> >>> >>> >>> 2015-02-12 7:01 GMT+01:00 Krzysztof Sobkowiak <[email protected]>: >>>> Hi >>>> >>>> One user has reported a problem with usage of httpj:engine-factoryin >>>> ServiceMix >>>> (http://servicemix.396122.n5.nabble.com/servicemix-5-4-0-cxf-jetty-blueprint-issue-tp5722268.html). >>>> Using this configuration element in blueprint causes following error >>>> >>>> >>>> java.lang.NoClassDefFoundError: >>>> org/apache/aries/blueprint/reflect/MapMetadataImpl >>>> at >>>> org.apache.cxf.transport.http_jetty.blueprint.JettyServerEngineFactoryParser.parseEngineConnector(JettyServerEngineFactoryParser.java:110) >>>> at >>>> org.apache.cxf.transport.http_jetty.blueprint.JettyServerEngineFactoryParser.parse(JettyServerEngineFactoryParser.java:83) >>>> at >>>> org.apache.cxf.transport.http_jetty.blueprint.HTTPJettyTransportNamespaceHandler.parse(HTTPJettyTransportNamespaceHandler.java:68) >>>> at >>>> org.apache.aries.blueprint.parser.Parser.parseCustomElement(Parser.java:1308)[18:org.apache.aries.blueprint.core:1.4.2] >>>> at >>>> org.apache.aries.blueprint.parser.Parser.loadComponents(Parser.java:366)[18:org.apache.aries.blueprint.core:1.4.2] >>>> at >>>> org.apache.aries.blueprint.parser.Parser.populate(Parser.java:306)[18:org.apache.aries.blueprint.core:1.4.2] >>>> at >>>> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:323)[18:org.apache.aries.blueprint.core:1.4.2] >>>> at >>>> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)[18:org.apache.aries.blueprint.core:1.4.2] >>>> at >>>> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:294)[18:org.apache.aries.blueprint.core:1.4.2] >>>> at >>>> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:263)[18:org.apache.aries.blueprint.core:1.4.2] >>>> at >>>> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:253)[18:org.apache.aries.blueprint.core:1.4.2] >>>> at >>>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[13:org.apache.aries.util:1.1.0] >>>> at >>>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[13:org.apache.aries.util:1.1.0] >>>> at >>>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[13:org.apache.aries.util:1.1.0] >>>> at >>>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[13:org.apache.aries.util:1.1.0] >>>> at >>>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[13:org.apache.aries.util:1.1.0] >>>> at >>>> org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1127)[org.apache.felix.framework-4.4.1.jar:] >>>> at >>>> org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:696)[org.apache.felix.framework-4.4.1.jar:] >>>> at >>>> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:484)[org.apache.felix.framework-4.4.1.jar:] >>>> at >>>> org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4429)[org.apache.felix.framework-4.4.1.jar:] >>>> at >>>> org.apache.felix.framework.Felix.startBundle(Felix.java:2100)[org.apache.felix.framework-4.4.1.jar:] >>>> at >>>> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1299)[org.apache.felix.framework-4.4.1.jar:] >>>> at >>>> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)[org.apache.felix.framework-4.4.1.jar:] >>>> at java.lang.Thread.run(Thread.java:745)[:1.7.0_76] >>>> Caused by: java.lang.ClassNotFoundException: >>>> org.apache.aries.blueprint.reflect.MapMetadataImpl not found by >>>> org.apache.cxf.cxf-rt-transports-http-jetty [165] >>>> at >>>> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1556)[org.apache.felix.framework-4.4.1.jar:] >>>> at >>>> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77)[org.apache.felix.framework-4.4.1.jar:] >>>> at >>>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1993)[org.apache.felix.framework-4.4.1.jar:] >>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)[:1.7.0_76] >>>> >>>> >>>> The problem was introduced by >>>> https://issues.apache.org/jira/browse/CXF-5863 (in 2.7.x, 3.0.x and >>>> master -- >>>> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=commit;h=3812fe2327b06d06ba60fe80fc466e4b39c915d6) >>>> by usage of classes from org.apache.aries.blueprint.reflectin >>>> JettyServerEngineFactoryParser. The package is imported by >>>> cxf-rt-transports-http-jettybut the classes are not exported (and were >>>> not exported when this bug was fixed) from blueprint-core. >>>> >>>> I think, this is a blocking issue for people using >>>> httpj:engine-factoryblueprint element in OSGi environment, but you can >>>> decide whether this should stop the release. It would be nice if you had >>>> a workaround for this problem. >>>> >>>> Regards >>>> Krzysztof >>>> >>>> >>>> On 12.02.2015 02:53, Daniel Kulp wrote: >>>>> This is a vote to release 3.0.4 and 2.7.15. It’s been about 2 months >>>>> since the last release and we’ve fixed more than 70 issues. >>>>> >>>>> Staging areas: >>>>> 2.7.15: >>>>> https://repository.apache.org/content/repositories/orgapachecxf-1036/ >>>>> 3.0.4: >>>>> https://repository.apache.org/content/repositories/orgapachecxf-1037/ >>>>> >>>>> >>>>> Tags: >>>>> 2.7.15: >>>>> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=ad0e985de4d14603398765e96723a4d2efe9da64 >>>>> 3.0.4: >>>>> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=3bbc187f31e42cd4cb2e82b6604a87029823331c >>>>> >>>>> >>>>> The vote will be open for at least 72 hours. >>>>> >>>> -- >>>> Krzysztof Sobkowiak >>>> >>>> JEE & OSS Architect >>>> Senior Solution Architect @ Capgemini SSC >>>> <http://www.pl.capgemini-sdm.com/en> >>>> Apache ServiceMix <http://servicemix.apache.org/> Committer & PMC >> >> -- >> Krzysztof Sobkowiak >> >> JEE & OSS Architect >> Senior Solution Architect @ Capgemini SSC >> <http://www.pl.capgemini-sdm.com/en> >> Apache ServiceMix <http://servicemix.apache.org/> Committer & PMC > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com >
