You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Kurt Westerfeld <kw...@novell.com> on 2010/10/23 01:43:20 UTC
Porting CXF SE/BC From SMX3 to SMX4 Libraries Question
Hello, I'm just beginning to look into porting some SMX 3 JBI components to SMX 4, after the great talk at DC yesterday by the FUSE team. I was encouraged to simply try out the SMX4 from FUSE, because it's got it's JBI layer going and all. So, gave it a try.
What I'm finding is that certain implicit library dependencies that were present in SMX3 are no longer there. The first I found was log4j, which while seemingly "supported", isn't provided (literally, the provided scope from maven is what we're using) any longer for servicemix-cxf-se SUs. That was an easy fix, but it led to the next occurrence of the same issue.
The servicemix-cxf-bc components we have all use spring configuration to configure the CXF bus. At first glance, it does not seem to be the case any longer that an xbean.xml deployment descriptor for these components has access to the spring schemas for base CXF configuration.
Simple example fragment we include for all our binding components:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cxf="http://cxf.apache.org/core"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
">
<cxf:bus>
<cxf:features>
<cxf:logging/>
(etc etc all of our interceptor configuration omitted)
where we use "busCfg=" on the binding component:
<cxfbc:consumer
wsdl="classpath:Some.wsdl"
locationURI="http://${HttpDefaultHost}:${HttpDefaultPort}/SomeEndPoint"
targetService="somens:SomeService"
targetInterface="somens:SomeService"
busCfg="/identity-server-bus-beans.xml" />
So this is no longer working. An example stacktrace is here:
18:59:58,461 | ERROR | rint Extender: 2 | ServiceAssemblyInstaller | er.impl.ServiceAssemblyInstaller 212 | 93 - org.apache.servicemix.jbi.deployer - 1.3.0.fuse-01-00 | Error deploying SU submit-process-binding
javax.jbi.management.DeploymentException: java.lang.RuntimeException: org.springframework.context.ApplicationContextException: Failed to load configuration /identity-server-bus-beans.xml
at org.apache.servicemix.cxfbc.CxfBcConsumer.validate(CxfBcConsumer.java:561)[140:servicemix-cxf-bc:2010.02.0.fuse-01-00]
at org.apache.servicemix.common.AbstractDeployer.validate(AbstractDeployer.java:58)[90:servicemix-common:2010.02.0.fuse-01-00]
at org.apache.servicemix.common.xbean.BaseXBeanDeployer.validate(BaseXBeanDeployer.java:55)[90:servicemix-common:2010.02.0.fuse-01-00]
at org.apache.servicemix.common.xbean.AbstractXBeanDeployer.deploy(AbstractXBeanDeployer.java:98)[90:servicemix-common:2010.02.0.fuse-01-00]
at org.apache.servicemix.common.BaseServiceUnitManager.doDeploy(BaseServiceUnitManager.java:88)[90:servicemix-common:2010.02.0.fuse-01-00]
at org.apache.servicemix.common.BaseServiceUnitManager.deploy(BaseServiceUnitManager.java:69)[90:servicemix-common:2010.02.0.fuse-01-00]
at org.apache.servicemix.jbi.deployer.artifacts.ServiceUnitImpl.deploy(ServiceUnitImpl.java:104)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
at org.apache.servicemix.jbi.deployer.impl.ServiceAssemblyInstaller.deploySUs(ServiceAssemblyInstaller.java:207)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
at org.apache.servicemix.jbi.deployer.impl.ServiceAssemblyInstaller.install(ServiceAssemblyInstaller.java:85)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
at org.apache.servicemix.jbi.deployer.impl.Deployer.checkPendingInstallers(Deployer.java:558)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
at org.apache.servicemix.jbi.deployer.impl.Deployer.lifeCycleChanged(Deployer.java:608)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
at org.apache.servicemix.jbi.deployer.artifacts.AbstractLifecycleJbiArtifact.fireEvent(AbstractLifecycleJbiArtifact.java:102)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
at org.apache.servicemix.jbi.deployer.artifacts.AbstractLifecycleJbiArtifact.fireEvent(AbstractLifecycleJbiArtifact.java:92)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
at org.apache.servicemix.jbi.deployer.artifacts.ComponentImpl$ComponentWrapper.init(ComponentImpl.java:250)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
at org.apache.servicemix.jbi.runtime.impl.ComponentRegistryImpl.doRegister(ComponentRegistryImpl.java:89)[91:org.apache.servicemix.jbi.runtime:1.3.0.fuse-01-00]
at org.apache.servicemix.jbi.runtime.impl.ComponentRegistryImpl.doRegister(ComponentRegistryImpl.java:38)[91:org.apache.servicemix.jbi.runtime:1.3.0.fuse-01-00]
at org.apache.servicemix.nmr.core.ServiceRegistryImpl.register(ServiceRegistryImpl.java:47)[81:org.apache.servicemix.nmr.core:1.3.0.fuse-01-00]
at org.apache.servicemix.nmr.osgi.OsgiServiceRegistryTracker.addingService(OsgiServiceRegistryTracker.java:78)[82:org.apache.servicemix.nmr.osgi:1.3.0.fuse-01-00]
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896)[osgi-3.6.0.v20100517.jar:]
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)[osgi-3.6.0.v20100517.jar:]
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233)[osgi-3.6.0.v20100517.jar:]
at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:840)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:104)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:933)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:149)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:756)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:711)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:206)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:507)[osgi-3.6.0.v20100517.jar:]
at org.apache.servicemix.jbi.deployer.impl.Deployer.registerService(Deployer.java:762)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
at org.apache.servicemix.jbi.deployer.impl.Deployer.registerComponent(Deployer.java:418)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
at org.apache.servicemix.jbi.deployer.impl.ComponentInstaller.initComponent(ComponentInstaller.java:424)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
at org.apache.servicemix.jbi.deployer.impl.ComponentInstaller.install(ComponentInstaller.java:150)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
at org.apache.servicemix.jbi.deployer.impl.Deployer.registerDeployedComponent(Deployer.java:657)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
at org.apache.servicemix.jbi.deployer.impl.Deployer$1.addingService(Deployer.java:222)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896)[osgi-3.6.0.v20100517.jar:]
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)[osgi-3.6.0.v20100517.jar:]
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233)[osgi-3.6.0.v20100517.jar:]
at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:840)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:104)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:933)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:149)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:756)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:711)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:206)[osgi-3.6.0.v20100517.jar:]
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:507)[osgi-3.6.0.v20100517.jar:]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:388)[7:org.apache.aries.blueprint:0.2.0.incubating]
at org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:166)[7:org.apache.aries.blueprint:0.2.0.incubating]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:646)[7:org.apache.aries.blueprint:0.2.0.incubating]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:314)[7:org.apache.aries.blueprint:0.2.0.incubating]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:213)[7:org.apache.aries.blueprint:0.2.0.incubating]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_18]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_18]
at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_18]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_18]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)[:1.6.0_18]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_18]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_18]
at java.lang.Thread.run(Thread.java:619)[:1.6.0_18]
Caused by: java.lang.RuntimeException: org.springframework.context.ApplicationContextException: Failed to load configuration /identity-server-bus-beans.xml
at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java:96)[138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java:88)[138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java:64)[138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
at org.apache.servicemix.cxfbc.CxfBcConsumer.getBus(CxfBcConsumer.java:677)[140:servicemix-cxf-bc:2010.02.0.fuse-01-00]
at org.apache.servicemix.cxfbc.CxfBcConsumer.retrieveWSDL(CxfBcConsumer.java:658)[140:servicemix-cxf-bc:2010.02.0.fuse-01-00]
at org.apache.servicemix.cxfbc.CxfBcConsumer.validate(CxfBcConsumer.java:430)[140:servicemix-cxf-bc:2010.02.0.fuse-01-00]
... 62 more
Caused by: org.springframework.context.ApplicationContextException: Failed to load configuration /identity-server-bus-beans.xml
at org.apache.cxf.bus.spring.BusApplicationContext.getConfigResources(BusApplicationContext.java:152)[138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:120)[62:org.springframework.context:3.0.3.RELEASE]
at org.apache.cxf.bus.spring.BusApplicationContext.loadBeanDefinitions(BusApplicationContext.java:262)[138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130)[62:org.springframework.context:3.0.3.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:467)[62:org.springframework.context:3.0.3.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:397)[62:org.springframework.context:3.0.3.RELEASE]
at org.apache.cxf.bus.spring.BusApplicationContext.<init>(BusApplicationContext.java:91)[138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
at org.apache.cxf.bus.spring.SpringBusFactory.createApplicationContext(SpringBusFactory.java:110)[138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java:93)[138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
... 67 more
This leads me to believe that perhaps the servicemix-cxf-bc component, as well as the servicemix-cxf-se component, are no longer providing the same libs as SMX3 while running in SMX4.
So, I wonder how I could solve this if I don't want to go down the route to rebuild all of our components as OSGi bundles? I would like to think that the same library underpinnings, apart from version #s, would be provided for these components.
Any thoughts?
Re: Porting CXF SE/BC From SMX3 to SMX4 Libraries Question
Posted by Kurt Westerfeld <kw...@novell.com>.
I basically ended up doing exactly this, except you don't need to add cxf-rt-core to the JBI package by changing the cxf:bus decleration to something similar to:
<bean id="cxf" class="org.apache.cxf.bus.CXFBusImpl">
<property name="inInterceptors">
<list>
</list>
</property>
<property name="outInterceptors">
<list>
</list>
</property>
<property name="outFaultInterceptors">
</property>
<property name="inFaultInterceptors">
</property>
</bean>
And this "works", but I can't understand how the classpath can contain the CXFBusImpl class and yet the same jar that contains this class, which also contains the cxf core.xsd, but cannot allow a cxf:bus decleration. It really seems like a defect that should be addressed.
>>> Freeman Fang <fr...@gmail.com> 10/23/2010 11:18 PM >>>
Hi,
This is actually the same spring handler namespace issue as I
mentioned in the end of my previous mail.
The workaround for JBI packaging I can come up is explictly add cxf-rt-
core dependency in your su pom.xml.
And in your xbean.xml, you also need add
<import resource="classpath:META-INF/cxf/cxf.xml" />
<import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
<import resource="classpath:META-INF/cxf/cxf-extension-http.xml" />
<import resource="classpath:META-INF/cxf/cxf-extension-http-
jetty.xml" />
to xbean.xml, as now you init cxf bus in the same context with your
cxf bc consumer endpoint.
Freeman
On 2010-10-24, at 上午1:18, Kurt Westerfeld wrote:
> Freeman, I decided to make a minor mod to the example you indicated,
> the cxf-wsdl-first example. I modified the xbean.xml in wsdl-first-
> cxfbc-su/src/main/resources/xbean.xml to add a cxf:bus adding the
> simple cxf:logging feature, got it to deploy fine on SMX3, but on
> SMX4 I receive the same error:
>
> <loc-message>Unrecognized xbean namespace mapping: http://cxf.apache.org/core
> </loc-message>
> <stack-trace><!
> [CDATA
> [org.springframework.beans.factory.BeanDefinitionStoreException:
> Unrecognized xbean namespace mapping: http://cxf.apache.org/core
> at
> org
> .apache
> .xbean
> .spring
> .context
> .v2c
> .XBeanNamespaceHandler
> .parseBeanFromExtensionElement(XBeanNamespaceHandler.java:282)
> at
> org
> .apache
> .xbean
> .spring
> .context.v2c.XBeanNamespaceHandler.parse(XBeanNamespaceHandler.java:
> 156)
> at
> org
> .apache
> .xbean
> .spring
> .context.v2.XBeanNamespaceHandler.parse(XBeanNamespaceHandler.java:49)
> at
> org
> .springframework
> .beans
> .factory
> .xml
> .BeanDefinitionParserDelegate
> .parseCustomElement(BeanDefinitionParserDelegate.java:1335)
> So, I guess I'm stuck on porting to OSGi unless I can figure out
> another workaround. We'd like to move to OSGi, mind you, but want
> to do so somewhat gradually if we can.
>
> Here's my diff, FWIW.....should I file a JIRA on this?
>
> diff -b -r wsdl-first-cxfbc-su/src/main/resources/xbean.xml e:\dev
> \apache-servicemix-4.3.0-fuse-02-00\examples\cxf-wsdl-first\wsdl-
> first-cxfbc-su/src/main/resources/xbean.xml
> 21,33c21
> < xmlns:person="http://servicemix.apache.org/samples/wsdl-
> first"
> < xmlns:cxf="http://cxf.apache.org/core"
> < xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> < xsi:schemaLocation="
> < http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
> < http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
> < ">
> <
> < <cxf:bus>
> < <cxf:features>
> < <cxf:logging/>
> < </cxf:features>
> < </cxf:bus>
> ---
>> xmlns:person="http://servicemix.apache.org/samples/wsdl-first">
>
> 37,41c25
> < targetInterface="person:Person">
> < <cxfbc:providedBus>
> < <ref bean="cxf" />
> < </cxfbc:providedBus>
> < </cxfbc:consumer>
> ---
>> targetInterface="person:Person"/>
>
>
>
>>>> "Kurt Westerfeld" <kw...@novell.com> 10/23/2010 10:35 AM >>>
>> First of all, I hope you didn't miss my previous answer about how to
>> use cxf bus in smx-cxf-bc with smx4
>> About using cxf bus in smx-cxf component, take a look at discussion
>> in
>> SMXCOMP-688[2]
>
>> [2]https://issues.apache.org/activemq/browse/SMXCOMP-688
>
> I actually read that several times before I originally posted, and
> can definitely see the overlap with my issue. I guess I thought the
> JBI packaging would be somewhat different, as that bug seems to be
> related to OSGi packaging.
>
> Uncle!
>
> You've given me enough to go chase....shame on me for not reading
> more carefully that thread. Thanks. :-)
>
--
Freeman Fang
------------------------
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Open Source SOA: http://fusesource.com
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org
Re: Porting CXF SE/BC From SMX3 to SMX4 Libraries Question
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
This is actually the same spring handler namespace issue as I
mentioned in the end of my previous mail.
The workaround for JBI packaging I can come up is explictly add cxf-rt-
core dependency in your su pom.xml.
And in your xbean.xml, you also need add
<import resource="classpath:META-INF/cxf/cxf.xml" />
<import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
<import resource="classpath:META-INF/cxf/cxf-extension-http.xml" />
<import resource="classpath:META-INF/cxf/cxf-extension-http-
jetty.xml" />
to xbean.xml, as now you init cxf bus in the same context with your
cxf bc consumer endpoint.
Freeman
On 2010-10-24, at 上午1:18, Kurt Westerfeld wrote:
> Freeman, I decided to make a minor mod to the example you indicated,
> the cxf-wsdl-first example. I modified the xbean.xml in wsdl-first-
> cxfbc-su/src/main/resources/xbean.xml to add a cxf:bus adding the
> simple cxf:logging feature, got it to deploy fine on SMX3, but on
> SMX4 I receive the same error:
>
> <loc-message>Unrecognized xbean namespace mapping: http://cxf.apache.org/core
> </loc-message>
> <stack-trace><!
> [CDATA
> [org.springframework.beans.factory.BeanDefinitionStoreException:
> Unrecognized xbean namespace mapping: http://cxf.apache.org/core
> at
> org
> .apache
> .xbean
> .spring
> .context
> .v2c
> .XBeanNamespaceHandler
> .parseBeanFromExtensionElement(XBeanNamespaceHandler.java:282)
> at
> org
> .apache
> .xbean
> .spring
> .context.v2c.XBeanNamespaceHandler.parse(XBeanNamespaceHandler.java:
> 156)
> at
> org
> .apache
> .xbean
> .spring
> .context.v2.XBeanNamespaceHandler.parse(XBeanNamespaceHandler.java:49)
> at
> org
> .springframework
> .beans
> .factory
> .xml
> .BeanDefinitionParserDelegate
> .parseCustomElement(BeanDefinitionParserDelegate.java:1335)
> So, I guess I'm stuck on porting to OSGi unless I can figure out
> another workaround. We'd like to move to OSGi, mind you, but want
> to do so somewhat gradually if we can.
>
> Here's my diff, FWIW.....should I file a JIRA on this?
>
> diff -b -r wsdl-first-cxfbc-su/src/main/resources/xbean.xml e:\dev
> \apache-servicemix-4.3.0-fuse-02-00\examples\cxf-wsdl-first\wsdl-
> first-cxfbc-su/src/main/resources/xbean.xml
> 21,33c21
> < xmlns:person="http://servicemix.apache.org/samples/wsdl-
> first"
> < xmlns:cxf="http://cxf.apache.org/core"
> < xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> < xsi:schemaLocation="
> < http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
> < http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
> < ">
> <
> < <cxf:bus>
> < <cxf:features>
> < <cxf:logging/>
> < </cxf:features>
> < </cxf:bus>
> ---
>> xmlns:person="http://servicemix.apache.org/samples/wsdl-first">
>
> 37,41c25
> < targetInterface="person:Person">
> < <cxfbc:providedBus>
> < <ref bean="cxf" />
> < </cxfbc:providedBus>
> < </cxfbc:consumer>
> ---
>> targetInterface="person:Person"/>
>
>
>
>>>> "Kurt Westerfeld" <kw...@novell.com> 10/23/2010 10:35 AM >>>
>> First of all, I hope you didn't miss my previous answer about how to
>> use cxf bus in smx-cxf-bc with smx4
>> About using cxf bus in smx-cxf component, take a look at discussion
>> in
>> SMXCOMP-688[2]
>
>> [2]https://issues.apache.org/activemq/browse/SMXCOMP-688
>
> I actually read that several times before I originally posted, and
> can definitely see the overlap with my issue. I guess I thought the
> JBI packaging would be somewhat different, as that bug seems to be
> related to OSGi packaging.
>
> Uncle!
>
> You've given me enough to go chase....shame on me for not reading
> more carefully that thread. Thanks. :-)
>
--
Freeman Fang
------------------------
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Open Source SOA: http://fusesource.com
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org
Re: Porting CXF SE/BC From SMX3 to SMX4 Libraries Question
Posted by Kurt Westerfeld <kw...@novell.com>.
Freeman, I decided to make a minor mod to the example you indicated, the cxf-wsdl-first example. I modified the xbean.xml in wsdl-first-cxfbc-su/src/main/resources/xbean.xml to add a cxf:bus adding the simple cxf:logging feature, got it to deploy fine on SMX3, but on SMX4 I receive the same error:
<loc-message>Unrecognized xbean namespace mapping: http://cxf.apache.org/core</loc-message>
<stack-trace><![CDATA[org.springframework.beans.factory.BeanDefinitionStoreException: Unrecognized xbean namespace mapping: http://cxf.apache.org/core
at org.apache.xbean.spring.context.v2c.XBeanNamespaceHandler.parseBeanFromExtensionElement(XBeanNamespaceHandler.java:282)
at org.apache.xbean.spring.context.v2c.XBeanNamespaceHandler.parse(XBeanNamespaceHandler.java:156)
at org.apache.xbean.spring.context.v2.XBeanNamespaceHandler.parse(XBeanNamespaceHandler.java:49)
at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1335)
So, I guess I'm stuck on porting to OSGi unless I can figure out another workaround. We'd like to move to OSGi, mind you, but want to do so somewhat gradually if we can.
Here's my diff, FWIW.....should I file a JIRA on this?
diff -b -r wsdl-first-cxfbc-su/src/main/resources/xbean.xml e:\dev\apache-servicemix-4.3.0-fuse-02-00\examples\cxf-wsdl-first\wsdl-first-cxfbc-su/src/main/resources/xbean.xml
21,33c21
< xmlns:person="http://servicemix.apache.org/samples/wsdl-first"
< xmlns:cxf="http://cxf.apache.org/core"
< xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
< xsi:schemaLocation="
< http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
< http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
< ">
<
< <cxf:bus>
< <cxf:features>
< <cxf:logging/>
< </cxf:features>
< </cxf:bus>
---
> xmlns:person="http://servicemix.apache.org/samples/wsdl-first">
37,41c25
< targetInterface="person:Person">
< <cxfbc:providedBus>
< <ref bean="cxf" />
< </cxfbc:providedBus>
< </cxfbc:consumer>
---
> targetInterface="person:Person"/>
>>> "Kurt Westerfeld" <kw...@novell.com> 10/23/2010 10:35 AM >>>
> First of all, I hope you didn't miss my previous answer about how to
> use cxf bus in smx-cxf-bc with smx4
> About using cxf bus in smx-cxf component, take a look at discussion in
> SMXCOMP-688[2]
> [2]https://issues.apache.org/activemq/browse/SMXCOMP-688
I actually read that several times before I originally posted, and can definitely see the overlap with my issue. I guess I thought the JBI packaging would be somewhat different, as that bug seems to be related to OSGi packaging.
Uncle!
You've given me enough to go chase....shame on me for not reading more carefully that thread. Thanks. :-)
Re: Porting CXF SE/BC From SMX3 to SMX4 Libraries Question
Posted by Kurt Westerfeld <kw...@novell.com>.
> First of all, I hope you didn't miss my previous answer about how to
> use cxf bus in smx-cxf-bc with smx4
> About using cxf bus in smx-cxf component, take a look at discussion in
> SMXCOMP-688[2]
> [2]https://issues.apache.org/activemq/browse/SMXCOMP-688
I actually read that several times before I originally posted, and can definitely see the overlap with my issue. I guess I thought the JBI packaging would be somewhat different, as that bug seems to be related to OSGi packaging.
Uncle!
You've given me enough to go chase....shame on me for not reading more carefully that thread. Thanks. :-)
Re: Porting CXF SE/BC From SMX3 to SMX4 Libraries Question
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
My comment inline
On 2010-10-23, at 下午1:23, Kurt Westerfeld wrote:
> Freeman, thanks a lot for responding to the issue....and apologies
> in advance for this lengthy email. I hope my issue is clear by the
> end of it. :-)
>
> You wrote:
>
>> If you're using JBI pakcaging, then there's no big difference
>> between
>> SMX3 and SMX4, you can take a look at cxf-wsdl-fisrt example we
>> shipped with smx4 kit, it's pretty much same as it's counterpart in
>> smx3. :-)
>
> That's an example I definitely know, and we used this and other
> servicemix-cxf* examples to generate the JBI artifacts that run on
> SMX3. The issue I'm having is, the core libraries provided with the
> servicemix-cxf-bc component do not have all of the cxf "core",
> including the [http://cxf.apache.org/core] mapping we use to
> configure the bus. The servicemix-cxf-bc component has a feature to
> configure the bus from an external spring mapping file, used with
> the busCfg= attribute:
>
> <cxfbc:consumer
> wsdl="classpath:Some.wsdl"
> locationURI="http://${HttpDefaultHost}:${HttpDefaultPort}/
> SomeEndPoint"
> targetService="somens:SomeService"
> targetInterface="somens:SomeService"
> busCfg="/identity-server-bus-beans.xml" />
> This busCfg= attribute is documented in the servicemix-cxf-bc.xsd as
> "the location of the CXF configuration file used to configure the
> CXF bus. This allows you to configure features like WS-RM and JMS
> runtime behavior." We use the cxf: prefix to create a bus,
> configure it how we want it, and it is then used as the cxf bus for
> the endpoint (in this case, a consumer of a servicemix-cxf-se
> component). I got the idea on how to do this by looking over
> servicemix 3 source code unit tests (see: http://svn.apache.org/repos/asf/servicemix/components/bindings/servicemix-cxf-bc/tags/servicemix-cxf-bc-2010.01/src/test/resources/org/apache/servicemix/cxfbc/provider/xbean_provider_with_bus_logger_feature.xml
> ). We adapted this use-case to allow our interceptor configuration
> for all of our endpoints to be centralized on one set of spring
> configuration files--which is quite nice.
First of all, I hope you didn't miss my previous answer about how to
use cxf bus in smx-cxf-bc with smx4
About using cxf bus in smx-cxf component, take a look at discussion in
SMXCOMP-688[2]
[2]https://issues.apache.org/activemq/browse/SMXCOMP-688
>
> In looking over the libraries provided in the servicemix-cxf-bc
> component on SMX3, the cxf-rt-core-2.2.6.jar library is provided to
> provide this cxf bus configuration capability. This jar is provided
> in the form of a OSGi feature bundle, but this bundle does not seem
> to be connected to the servicemix-cxf-bc component when using SMX4.
> Doing a little digging, it looks like the osgi bundle "Apache CXF
> Bundle Jar (2.2.10.fuse-00-00)", is not wired up to the servicemix-
> cxf-bc JBI component on SMX4. I don't know if this is intentional
> or oversight.
All cxf related jars(including cx-core you mentioned here) now are
merged into Apache CXF Bundle jar, and it should be wired up to the
servicemix-cxf-bc JBI component already, otherwise servicemix-cxf-bc
JBI component won't get started correctly. :-)
>
>
> Another piece of evidence here is that the servicemix-cxf-bc META-
> INF/DEPENDENCIES file indicates:
>
> - Apache CXF Runtime Core (http://cxf.apache.org)
> org.apache.cxf:cxf-rt-core:jar:2.2.10-fuse-00-00
> License: The Apache Software License, Version 2.0 (http://www.apache.org/licenses/LICENSE-2.0.txt
> )
>
> Which is the exact jar I would expect to provide the feature we're
> finding missing. So, is this a bug or is there a feature or bundle
> I must enable/install within servicemix to cause this connection to
> happen? I am admittedly a newbie for OSGi, but in this case we're
> not tackling OSGi yet, we're just trying to run our SMX3 SAs on SMX4.
>
As this jar already merged into Apache CXF Bundle jar, which by
default would be installed when you start smx4.
When you deploy JBI packaging artifacts into SMX4, there's a JBI
deployer come in and change your SA/SUs into bundles, actually in SMX4
which basically is OSGi container, every thing(JBI artifacts, spring
file, blueprint file, war) would be transform into OSGi bundles
underlying, but this process is automatically and so you're not aware
of it.
> On the topic of logging, it is implied by the URL (http://wiki.ops4j.org/display/paxlogging/Pax+Logging
> ) that Log4J API as well as back-end should be supported. I think
> it's probably a gray area that in our case, we're using JBI
> packaging, which doesn't make this same connection. Again, on SMX3
> the java code we deploy does not provide a copy of log4j (which
> would be duplicated all over the place as well as duplicate of the
> SMX3 core libraries), so while not a big deal, the expectation I
> have is that this same code would deploy and run on SMX4.
In SMX4, log4j api and impl class should be provided by pax-logging-
api-1.5.3.jar and pax-logging-service-1.5.3.jar(which is installed by
default when you start smx4), so you needn't install extra log4j jar.
You mean log4j in your SA doesn't work anymore when run with SMX4?
>
> I see these two issues as one-and-the-same, namely, that the core
> libraries that a SMX3 JBI component expects are not wired up on
> SMX4. I know that SMX4 has these libraries installed--they just
> aren't connected to the JBI deployment infrastructure.
And IMHO, the "Unable to locate Spring NamespaceHandler " is another
issue, Guillaume have written a very good blog to explain this [3],
you may need take a look at it.
[3]http://gnodet.blogspot.com/2010_03_01_archive.html
That said the "Unable to locate Spring NamespaceHandler" issue isn't
come from the library missing, it's actually from the defect that
spring-dm in OSGi container.
If you're using JBI packaging, the work around for this issue I can
come up with is that in your SU pom.xml, explicitly add cxf-core
dependency(or other cxf-* jar dependency if you need other Spring
NamespaceHandlers which in other cxf module).
Btw, besides JBI packaging, in SMX4 we also provide OSGi packaging for
JBI artifacts. The difference between OSGi packaging and JBI packaging
from my perspective isn't big, so you should easily transform your SA/
SUs into it if you want, and OSGi packaging IMHO is more natural when
deployed into OSGi container. Actually we have a cxf-wsdl-first-osgi-
package example shipped with smx4 kit, just in case you didn't look at
it.
So for the "Unable to locate Spring NamespaceHandler ", if you're
using OSGi packaging, then the solution is adding proper Import-
Packge, it's better following OSGi rule.
Hope this helps
Freeman
>
> Does that make sense?
--
Freeman Fang
------------------------
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Open Source SOA: http://fusesource.com
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org
Re: Porting CXF SE/BC From SMX3 to SMX4 Libraries Question
Posted by Kurt Westerfeld <kw...@novell.com>.
Freeman, thanks a lot for responding to the issue....and apologies in advance for this lengthy email. I hope my issue is clear by the end of it. :-)
You wrote:
> If you're using JBI pakcaging, then there's no big difference between
> SMX3 and SMX4, you can take a look at cxf-wsdl-fisrt example we
> shipped with smx4 kit, it's pretty much same as it's counterpart in
> smx3. :-)
That's an example I definitely know, and we used this and other servicemix-cxf* examples to generate the JBI artifacts that run on SMX3. The issue I'm having is, the core libraries provided with the servicemix-cxf-bc component do not have all of the cxf "core", including the [http://cxf.apache.org/core] mapping we use to configure the bus. The servicemix-cxf-bc component has a feature to configure the bus from an external spring mapping file, used with the busCfg= attribute:
<cxfbc:consumer
wsdl="classpath:Some.wsdl"
locationURI="http://${HttpDefaultHost}:${HttpDefaultPort}/SomeEndPoint"
targetService="somens:SomeService"
targetInterface="somens:SomeService"
busCfg="/identity-server-bus-beans.xml" />
This busCfg= attribute is documented in the servicemix-cxf-bc.xsd as "the location of the CXF configuration file used to configure the CXF bus. This allows you to configure features like WS-RM and JMS runtime behavior." We use the cxf: prefix to create a bus, configure it how we want it, and it is then used as the cxf bus for the endpoint (in this case, a consumer of a servicemix-cxf-se component). I got the idea on how to do this by looking over servicemix 3 source code unit tests (see: http://svn.apache.org/repos/asf/servicemix/components/bindings/servicemix-cxf-bc/tags/servicemix-cxf-bc-2010.01/src/test/resources/org/apache/servicemix/cxfbc/provider/xbean_provider_with_bus_logger_feature.xml
). We adapted this use-case to allow our interceptor configuration for all of our endpoints to be centralized on one set of spring configuration files--which is quite nice.
In looking over the libraries provided in the servicemix-cxf-bc component on SMX3, the cxf-rt-core-2.2.6.jar library is provided to provide this cxf bus configuration capability. This jar is provided in the form of a OSGi feature bundle, but this bundle does not seem to be connected to the servicemix-cxf-bc component when using SMX4. Doing a little digging, it looks like the osgi bundle "Apache CXF Bundle Jar (2.2.10.fuse-00-00)", is not wired up to the servicemix-cxf-bc JBI component on SMX4. I don't know if this is intentional or oversight.
Another piece of evidence here is that the servicemix-cxf-bc META-INF/DEPENDENCIES file indicates:
- Apache CXF Runtime Core (http://cxf.apache.org) org.apache.cxf:cxf-rt-core:jar:2.2.10-fuse-00-00
License: The Apache Software License, Version 2.0 (http://www.apache.org/licenses/LICENSE-2.0.txt)
Which is the exact jar I would expect to provide the feature we're finding missing. So, is this a bug or is there a feature or bundle I must enable/install within servicemix to cause this connection to happen? I am admittedly a newbie for OSGi, but in this case we're not tackling OSGi yet, we're just trying to run our SMX3 SAs on SMX4.
On the topic of logging, it is implied by the URL (http://wiki.ops4j.org/display/paxlogging/Pax+Logging) that Log4J API as well as back-end should be supported. I think it's probably a gray area that in our case, we're using JBI packaging, which doesn't make this same connection. Again, on SMX3 the java code we deploy does not provide a copy of log4j (which would be duplicated all over the place as well as duplicate of the SMX3 core libraries), so while not a big deal, the expectation I have is that this same code would deploy and run on SMX4.
I see these two issues as one-and-the-same, namely, that the core libraries that a SMX3 JBI component expects are not wired up on SMX4. I know that SMX4 has these libraries installed--they just aren't connected to the JBI deployment infrastructure.
Does that make sense?
Re: Porting CXF SE/BC From SMX3 to SMX4 Libraries Question
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
My comment inline.
On 2010-10-23, at 上午7:43, Kurt Westerfeld wrote:
> Hello, I'm just beginning to look into porting some SMX 3 JBI
> components to SMX 4, after the great talk at DC yesterday by the
> FUSE team. I was encouraged to simply try out the SMX4 from FUSE,
> because it's got it's JBI layer going and all. So, gave it a try.
>
> What I'm finding is that certain implicit library dependencies that
> were present in SMX3 are no longer there. The first I found was
> log4j, which while seemingly "supported", isn't provided (literally,
> the provided scope from maven is what we're using) any longer for
> servicemix-cxf-se SUs. That was an easy fix, but it led to the next
> occurrence of the same issue.
SMX4 now use pax-logging[1] to leverage all logging stuff.
[1]http://wiki.ops4j.org/display/paxlogging/Pax+Logging
>
> The servicemix-cxf-bc components we have all use spring
> configuration to configure the CXF bus. At first glance, it does
> not seem to be the case any longer that an xbean.xml deployment
> descriptor for these components has access to the spring schemas for
> base CXF configuration.
>
> Simple example fragment we include for all our binding components:
>
>
>
> <beans xmlns="http://www.springframework.org/schema/beans"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:cxf="http://cxf.apache.org/core"
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
> http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
> ">
> <cxf:bus>
> <cxf:features>
> <cxf:logging/>
>
> (etc etc all of our interceptor configuration omitted)
>
> where we use "busCfg=" on the binding component:
>
>
> <cxfbc:consumer
> wsdl="classpath:Some.wsdl"
> locationURI="http://${HttpDefaultHost}:${HttpDefaultPort}/
> SomeEndPoint"
> targetService="somens:SomeService"
> targetInterface="somens:SomeService"
> busCfg="/identity-server-bus-beans.xml" />
>
> So this is no longer working. An example stacktrace is here:
>
>
>
> 18:59:58,461 | ERROR | rint Extender: 2 |
> ServiceAssemblyInstaller | er.impl.ServiceAssemblyInstaller
> 212 | 93 - org.apache.servicemix.jbi.deployer - 1.3.0.fuse-01-00 |
> Error deploying SU submit-process-binding
> javax.jbi.management.DeploymentException:
> java.lang.RuntimeException:
> org.springframework.context.ApplicationContextException: Failed to
> load configuration /identity-server-bus-beans.xml
> at
> org
> .apache.servicemix.cxfbc.CxfBcConsumer.validate(CxfBcConsumer.java:
> 561)[140:servicemix-cxf-bc:2010.02.0.fuse-01-00]
> at
> org
> .apache
> .servicemix.common.AbstractDeployer.validate(AbstractDeployer.java:
> 58)[90:servicemix-common:2010.02.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .common.xbean.BaseXBeanDeployer.validate(BaseXBeanDeployer.java:55)
> [90:servicemix-common:2010.02.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .common
> .xbean.AbstractXBeanDeployer.deploy(AbstractXBeanDeployer.java:98)
> [90:servicemix-common:2010.02.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .common.BaseServiceUnitManager.doDeploy(BaseServiceUnitManager.java:
> 88)[90:servicemix-common:2010.02.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .common.BaseServiceUnitManager.deploy(BaseServiceUnitManager.java:69)
> [90:servicemix-common:2010.02.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .jbi.deployer.artifacts.ServiceUnitImpl.deploy(ServiceUnitImpl.java:
> 104)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .jbi
> .deployer
> .impl
> .ServiceAssemblyInstaller.deploySUs(ServiceAssemblyInstaller.java:
> 207)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .jbi
> .deployer
> .impl.ServiceAssemblyInstaller.install(ServiceAssemblyInstaller.java:
> 85)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .jbi.deployer.impl.Deployer.checkPendingInstallers(Deployer.java:558)
> [93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .jbi.deployer.impl.Deployer.lifeCycleChanged(Deployer.java:608)
> [93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .jbi
> .deployer
> .artifacts
> .AbstractLifecycleJbiArtifact
> .fireEvent(AbstractLifecycleJbiArtifact.java:102)
> [93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .jbi
> .deployer
> .artifacts
> .AbstractLifecycleJbiArtifact
> .fireEvent(AbstractLifecycleJbiArtifact.java:92)
> [93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
> at org.apache.servicemix.jbi.deployer.artifacts.ComponentImpl
> $ComponentWrapper.init(ComponentImpl.java:250)
> [93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .jbi
> .runtime
> .impl.ComponentRegistryImpl.doRegister(ComponentRegistryImpl.java:89)
> [91:org.apache.servicemix.jbi.runtime:1.3.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .jbi
> .runtime
> .impl.ComponentRegistryImpl.doRegister(ComponentRegistryImpl.java:38)
> [91:org.apache.servicemix.jbi.runtime:1.3.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .nmr.core.ServiceRegistryImpl.register(ServiceRegistryImpl.java:47)
> [81:org.apache.servicemix.nmr.core:1.3.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .nmr
> .osgi
> .OsgiServiceRegistryTracker
> .addingService(OsgiServiceRegistryTracker.java:78)
> [82:org.apache.servicemix.nmr.osgi:1.3.0.fuse-01-00]
> at org.osgi.util.tracker.ServiceTracker
> $Tracked.customizerAdding(ServiceTracker.java:896)
> [osgi-3.6.0.v20100517.jar:]
> at
> org
> .osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:
> 261)[osgi-3.6.0.v20100517.jar:]
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:
> 233)[osgi-3.6.0.v20100517.jar:]
> at org.osgi.util.tracker.ServiceTracker
> $Tracked.serviceChanged(ServiceTracker.java:840)
> [osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .internal
> .serviceregistry
> .FilteredServiceListener.serviceChanged(FilteredServiceListener.java:
> 104)[osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .framework
> .internal
> .core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:933)
> [osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227)
> [osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .framework
> .eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:
> 149)[osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .internal
> .serviceregistry
> .ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:
> 756)[osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .internal
> .serviceregistry
> .ServiceRegistry.publishServiceEvent(ServiceRegistry.java:711)
> [osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .internal
> .serviceregistry
> .ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130)
> [osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .internal
> .serviceregistry
> .ServiceRegistry.registerService(ServiceRegistry.java:206)
> [osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .framework
> .internal
> .core.BundleContextImpl.registerService(BundleContextImpl.java:507)
> [osgi-3.6.0.v20100517.jar:]
> at
> org
> .apache
> .servicemix.jbi.deployer.impl.Deployer.registerService(Deployer.java:
> 762)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .jbi.deployer.impl.Deployer.registerComponent(Deployer.java:418)
> [93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .jbi
> .deployer
> .impl.ComponentInstaller.initComponent(ComponentInstaller.java:424)
> [93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .jbi
> .deployer.impl.ComponentInstaller.install(ComponentInstaller.java:
> 150)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
> at
> org
> .apache
> .servicemix
> .jbi.deployer.impl.Deployer.registerDeployedComponent(Deployer.java:
> 657)[93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
> at org.apache.servicemix.jbi.deployer.impl.Deployer
> $1.addingService(Deployer.java:222)
> [93:org.apache.servicemix.jbi.deployer:1.3.0.fuse-01-00]
> at org.osgi.util.tracker.ServiceTracker
> $Tracked.customizerAdding(ServiceTracker.java:896)
> [osgi-3.6.0.v20100517.jar:]
> at
> org
> .osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:
> 261)[osgi-3.6.0.v20100517.jar:]
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:
> 233)[osgi-3.6.0.v20100517.jar:]
> at org.osgi.util.tracker.ServiceTracker
> $Tracked.serviceChanged(ServiceTracker.java:840)
> [osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .internal
> .serviceregistry
> .FilteredServiceListener.serviceChanged(FilteredServiceListener.java:
> 104)[osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .framework
> .internal
> .core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:933)
> [osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227)
> [osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .framework
> .eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:
> 149)[osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .internal
> .serviceregistry
> .ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:
> 756)[osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .internal
> .serviceregistry
> .ServiceRegistry.publishServiceEvent(ServiceRegistry.java:711)
> [osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .internal
> .serviceregistry
> .ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130)
> [osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .internal
> .serviceregistry
> .ServiceRegistry.registerService(ServiceRegistry.java:206)
> [osgi-3.6.0.v20100517.jar:]
> at
> org
> .eclipse
> .osgi
> .framework
> .internal
> .core.BundleContextImpl.registerService(BundleContextImpl.java:507)
> [osgi-3.6.0.v20100517.jar:]
> at
> org
> .apache
> .aries
> .blueprint
> .container
> .BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:
> 388)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org
> .apache
> .aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:
> 166)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org
> .apache
> .aries
> .blueprint
> .container
> .BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:
> 646)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org
> .apache
> .aries
> .blueprint
> .container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:
> 314)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org
> .apache
> .aries
> .blueprint
> .container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:
> 213)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at java.util.concurrent.Executors
> $RunnableAdapter.call(Executors.java:441)[:1.6.0_18]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> [:1.6.0_18]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_18]
> at java.util.concurrent.ScheduledThreadPoolExecutor
> $ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
> [:1.6.0_18]
> at java.util.concurrent.ScheduledThreadPoolExecutor
> $ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)[:
> 1.6.0_18]
> at java.util.concurrent.ThreadPoolExecutor
> $Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_18]
> at java.util.concurrent.ThreadPoolExecutor
> $Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_18]
> at java.lang.Thread.run(Thread.java:619)[:1.6.0_18]
> Caused by: java.lang.RuntimeException:
> org.springframework.context.ApplicationContextException: Failed to
> load configuration /identity-server-bus-beans.xml
> at
> org
> .apache
> .cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java:96)
> [138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
> at
> org
> .apache
> .cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java:88)
> [138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
> at
> org
> .apache
> .cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java:64)
> [138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
> at
> org.apache.servicemix.cxfbc.CxfBcConsumer.getBus(CxfBcConsumer.java:
> 677)[140:servicemix-cxf-bc:2010.02.0.fuse-01-00]
> at
> org
> .apache
> .servicemix.cxfbc.CxfBcConsumer.retrieveWSDL(CxfBcConsumer.java:658)
> [140:servicemix-cxf-bc:2010.02.0.fuse-01-00]
> at
> org
> .apache.servicemix.cxfbc.CxfBcConsumer.validate(CxfBcConsumer.java:
> 430)[140:servicemix-cxf-bc:2010.02.0.fuse-01-00]
> ... 62 more
> Caused by: org.springframework.context.ApplicationContextException:
> Failed to load configuration /identity-server-bus-beans.xml
> at
> org
> .apache
> .cxf
> .bus
> .spring
> .BusApplicationContext.getConfigResources(BusApplicationContext.java:
> 152)[138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
> at
> org
> .springframework
> .context
> .support
> .AbstractXmlApplicationContext
> .loadBeanDefinitions(AbstractXmlApplicationContext.java:120)
> [62:org.springframework.context:3.0.3.RELEASE]
> at
> org
> .apache
> .cxf
> .bus
> .spring
> .BusApplicationContext
> .loadBeanDefinitions(BusApplicationContext.java:262)
> [138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
> at
> org
> .springframework
> .context
> .support
> .AbstractRefreshableApplicationContext
> .refreshBeanFactory(AbstractRefreshableApplicationContext.java:130)
> [62:org.springframework.context:3.0.3.RELEASE]
> at
> org
> .springframework
> .context
> .support
> .AbstractApplicationContext
> .obtainFreshBeanFactory(AbstractApplicationContext.java:467)
> [62:org.springframework.context:3.0.3.RELEASE]
> at
> org
> .springframework
> .context
> .support
> .AbstractApplicationContext.refresh(AbstractApplicationContext.java:
> 397)[62:org.springframework.context:3.0.3.RELEASE]
> at
> org
> .apache
> .cxf
> .bus.spring.BusApplicationContext.<init>(BusApplicationContext.java:
> 91)[138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
> at
> org
> .apache
> .cxf
> .bus
> .spring
> .SpringBusFactory.createApplicationContext(SpringBusFactory.java:110)
> [138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
> at
> org
> .apache
> .cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java:93)
> [138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
> ... 67 more
>
> This leads me to believe that perhaps the servicemix-cxf-bc
> component, as well as the servicemix-cxf-se component, are no longer
> providing the same libs as SMX3 while running in SMX4.
About using cxf bus in smx-cxf component, take a look at discussion in
SMXCOMP-688[2]
[2]https://issues.apache.org/activemq/browse/SMXCOMP-688
>
> So, I wonder how I could solve this if I don't want to go down the
> route to rebuild all of our components as OSGi bundles? I would
> like to think that the same library underpinnings, apart from
> version #s, would be provided for these components.
>
If you're using JBI pakcaging, then there's no big difference between
SMX3 and SMX4, you can take a look at cxf-wsdl-fisrt example we
shipped with smx4 kit, it's pretty much same as it's counterpart in
smx3. :-)
Freeman
> Any thoughts?
--
Freeman Fang
------------------------
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Open Source SOA: http://fusesource.com
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org