Problems with Karaf 2.3.1 and Cxf
I've been using Karaf 2.3.0 for a while. I now tried to upgrade to Karaf 2.3.1 but ran into problems with CXF. I use cxf-codegen-plugin to generate code from a WSDL file so that I can call the web service via a proxy. However, after upgrading to Karaf 2.3.1 I get the following exception: 2013-04-02 09:19:03,317 | ERROR | rint Extender: 3 | BlueprintContainerImpl | container.BlueprintContainerImpl 393 | Unable to start blueprint container for bundle se.digia.connect.services.iso20022.iws-client org.osgi.service.blueprint.container.ComponentDefinitionException: Error when instantiating bean iwsService of class class se.digia.connect.iso20022.iwsclient.Client at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_32] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_32] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_32] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_32] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_32] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_32] at java.lang.Thread.run(Thread.java:662)[:1.6.0_32] Caused by: javax.xml.ws.spi.FactoryFinder$ConfigurationError: Provider org.apache.cxf.jaxws.spi.ProviderImpl not found at javax.xml.ws.spi.FactoryFinder$2.run(FactoryFinder.java:130) at javax.xml.ws.spi.FactoryFinder.doPrivileged(FactoryFinder.java:229)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder.newInstance(FactoryFinder.java:124)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder.access$200(FactoryFinder.java:44)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder$3.run(FactoryFinder.java:220) at javax.xml.ws.spi.FactoryFinder.doPrivileged(FactoryFinder.java:229)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:160)[:1.6.0_32] at javax.xml.ws.spi.Provider.provider(Provider.java:43)[:1.6.0_32] at javax.xml.ws.Service.init(Service.java:35)[:1.6.0_32] at se.digia.connect.iso20022.iwsclient.iws.IntegrationWebService.init(IntegrationWebService.java:30) at se.digia.connect.iso20022.iwsclient.Client.createProxy(Client.java:198) at se.digia.connect.iso20022.iwsclient.Client.init(Client.java:35) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)[:1.6.0_32] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)[:1.6.0_32] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)[:1.6.0_32] at java.lang.reflect.Constructor.newInstance(Constructor.java:513)[:1.6.0_32] at org.apache.aries.blueprint.utils.ReflectionUtils.newInstance(ReflectionUtils.java:329) at
Re: Problems with Karaf 2.3.1 and Cxf
Hi Bengt, do you use the jre.properties.cxf ? No problem with 2.3.0 ? Regards JB On 04/02/2013 09:30 AM, Bengt Rodehav wrote: I've been using Karaf 2.3.0 for a while. I now tried to upgrade to Karaf 2.3.1 but ran into problems with CXF. I use cxf-codegen-plugin to generate code from a WSDL file so that I can call the web service via a proxy. However, after upgrading to Karaf 2.3.1 I get the following exception: 2013-04-02 09:19:03,317 | ERROR | rint Extender: 3 | BlueprintContainerImpl | container.BlueprintContainerImpl 393 | Unable to start blueprint container for bundle se.digia.connect.services.iso20022.iws-client org.osgi.service.blueprint.container.ComponentDefinitionException: Error when instantiating bean iwsService of class class se.digia.connect.iso20022.iwsclient.Client at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_32] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_32] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_32] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_32] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_32] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_32] at java.lang.Thread.run(Thread.java:662)[:1.6.0_32] Caused by: javax.xml.ws.spi.FactoryFinder$ConfigurationError: Provider org.apache.cxf.jaxws.spi.ProviderImpl not found at javax.xml.ws.spi.FactoryFinder$2.run(FactoryFinder.java:130) at javax.xml.ws.spi.FactoryFinder.doPrivileged(FactoryFinder.java:229)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder.newInstance(FactoryFinder.java:124)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder.access$200(FactoryFinder.java:44)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder$3.run(FactoryFinder.java:220) at javax.xml.ws.spi.FactoryFinder.doPrivileged(FactoryFinder.java:229)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:160)[:1.6.0_32] at javax.xml.ws.spi.Provider.provider(Provider.java:43)[:1.6.0_32] at javax.xml.ws.Service.init(Service.java:35)[:1.6.0_32] at se.digia.connect.iso20022.iwsclient.iws.IntegrationWebService.init(IntegrationWebService.java:30) at se.digia.connect.iso20022.iwsclient.Client.createProxy(Client.java:198) at se.digia.connect.iso20022.iwsclient.Client.init(Client.java:35) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)[:1.6.0_32] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)[:1.6.0_32] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)[:1.6.0_32] at java.lang.reflect.Constructor.newInstance(Constructor.java:513)[:1.6.0_32] at
Re: Problems with Karaf 2.3.1 and Cxf
Hi, No concrete idea now, could you please append a test case which we can build and reproduce it? Thanks － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午3:30, Bengt Rodehav wrote: I've been using Karaf 2.3.0 for a while. I now tried to upgrade to Karaf 2.3.1 but ran into problems with CXF. I use cxf-codegen-plugin to generate code from a WSDL file so that I can call the web service via a proxy. However, after upgrading to Karaf 2.3.1 I get the following exception: 2013-04-02 09:19:03,317 | ERROR | rint Extender: 3 | BlueprintContainerImpl | container.BlueprintContainerImpl 393 | Unable to start blueprint container for bundle se.digia.connect.services.iso20022.iws-client org.osgi.service.blueprint.container.ComponentDefinitionException: Error when instantiating bean iwsService of class class se.digia.connect.iso20022.iwsclient.Client at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_32] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_32] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_32] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_32] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_32] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_32] at java.lang.Thread.run(Thread.java:662)[:1.6.0_32] Caused by: javax.xml.ws.spi.FactoryFinder$ConfigurationError: Provider org.apache.cxf.jaxws.spi.ProviderImpl not found at javax.xml.ws.spi.FactoryFinder$2.run(FactoryFinder.java:130) at javax.xml.ws.spi.FactoryFinder.doPrivileged(FactoryFinder.java:229)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder.newInstance(FactoryFinder.java:124)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder.access$200(FactoryFinder.java:44)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder$3.run(FactoryFinder.java:220) at javax.xml.ws.spi.FactoryFinder.doPrivileged(FactoryFinder.java:229)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:160)[:1.6.0_32] at javax.xml.ws.spi.Provider.provider(Provider.java:43)[:1.6.0_32] at javax.xml.ws.Service.init(Service.java:35)[:1.6.0_32] at
Re: Problems with Karaf 2.3.1 and Cxf
Hello JB, No I don't use jre.properties.cxf - where can I find it? It doesn't seem to be part of the distribution. Everything works fine under Karaf 2.3.0 - without using jre.properties.cxf. I'm also using Camel 2.10.3. I did this on Karaf 2.3.0 too without any problems. It seems like the org.apache.cxf.jaxws.spi package is exported by the bundle org.apache.cxf.cxf-rt-frontend-jax2s in Cxf 2.6.3. However, no bundle is importing the package. I've experimented with setting the TCCL in my bundle but I then get other problems instead. Also, I didn't have to do this in Karaf 2.3.0. How is this supposed to work? Should I need to manipulate the TCCL or should I add any imports (dynamic?) to get this to work? I didn't use to do anything special at all. Looking at the stack trace it seems to be the system bundle (class javax.xml.ws.spi.FactoryFinder) that tries to instantiate the ProviderImpl. Thus, it doesn't matter if my bundle imports the org.apache.cxf.jaxws.spi or not. Not really sure how this is supposed to work... /Bengt 2013/4/2 Jean-Baptiste Onofré j...@nanthrax.net Hi Bengt, do you use the jre.properties.cxf ? No problem with 2.3.0 ? Regards JB On 04/02/2013 09:30 AM, Bengt Rodehav wrote: I've been using Karaf 2.3.0 for a while. I now tried to upgrade to Karaf 2.3.1 but ran into problems with CXF. I use cxf-codegen-plugin to generate code from a WSDL file so that I can call the web service via a proxy. However, after upgrading to Karaf 2.3.1 I get the following exception: 2013-04-02 09:19:03,317 | ERROR | rint Extender: 3 | BlueprintContainerImpl | container.**BlueprintContainerImpl 393 | Unable to start blueprint container for bundle se.digia.connect.services.**iso20022.iws-client org.osgi.service.blueprint.**container.**ComponentDefinitionException: Error when instantiating bean iwsService of class class se.digia.connect.iso20022.**iwsclient.Client at org.apache.aries.blueprint.**container.BeanRecipe.** getInstance(BeanRecipe.java:**333)[7:org.apache.aries.** blueprint.core:1.1.0] at org.apache.aries.blueprint.**container.BeanRecipe.** internalCreate2(BeanRecipe.**java:806)[7:org.apache.aries.** blueprint.core:1.1.0] at org.apache.aries.blueprint.**container.BeanRecipe.** internalCreate(BeanRecipe.**java:787)[7:org.apache.aries.** blueprint.core:1.1.0] at org.apache.aries.blueprint.di.**AbstractRecipe$1.call(** AbstractRecipe.java:79)[7:org.**apache.aries.blueprint.core:1.**1.0] at java.util.concurrent.**FutureTask$Sync.innerRun(** FutureTask.java:303)[:1.6.0_**32] at java.util.concurrent.**FutureTask.run(FutureTask.** java:138)[:1.6.0_32] at org.apache.aries.blueprint.di.**AbstractRecipe.create(** AbstractRecipe.java:88)[7:org.**apache.aries.blueprint.core:1.**1.0] at org.apache.aries.blueprint.**container.BlueprintRepository.** createInstances(**BlueprintRepository.java:245)[** 7:org.apache.aries.blueprint.**core:1.1.0] at org.apache.aries.blueprint.**container.BlueprintRepository.** createAll(BlueprintRepository.**java:183)[7:org.apache.aries.** blueprint.core:1.1.0] at org.apache.aries.blueprint.**container.**BlueprintContainerImpl.** instantiateEagerComponents(**BlueprintContainerImpl.java:** 668)[7:org.apache.aries.**blueprint.core:1.1.0] at org.apache.aries.blueprint.**container.**BlueprintContainerImpl.doRun(** BlueprintContainerImpl.java:**370)[7:org.apache.aries.** blueprint.core:1.1.0] at org.apache.aries.blueprint.**container.**BlueprintContainerImpl.run(** BlueprintContainerImpl.java:**261)[7:org.apache.aries.** blueprint.core:1.1.0] at java.util.concurrent.**Executors$RunnableAdapter.** call(Executors.java:441)[:1.6.**0_32] at java.util.concurrent.**FutureTask$Sync.innerRun(** FutureTask.java:303)[:1.6.0_**32] at java.util.concurrent.**FutureTask.run(FutureTask.** java:138)[:1.6.0_32] at org.apache.aries.blueprint.**container.**ExecutorServiceWrapper.run(** ExecutorServiceWrapper.java:**106)[7:org.apache.aries.** blueprint.core:1.1.0] at org.apache.aries.blueprint.**utils.threading.impl.** DiscardableRunnable.run(**DiscardableRunnable.java:48)[** 7:org.apache.aries.blueprint.**core:1.1.0] at java.util.concurrent.**Executors$RunnableAdapter.** call(Executors.java:441)[:1.6.**0_32] at java.util.concurrent.**FutureTask$Sync.innerRun(** FutureTask.java:303)[:1.6.0_**32] at java.util.concurrent.**FutureTask.run(FutureTask.** java:138)[:1.6.0_32] at java.util.concurrent.**ScheduledThreadPoolExecutor$** ScheduledFutureTask.access$**301(**ScheduledThreadPoolExecutor.** java:98)[:1.6.0_32] at java.util.concurrent.**ScheduledThreadPoolExecutor$** ScheduledFutureTask.run(**ScheduledThreadPoolExecutor.** java:206)[:1.6.0_32] at java.util.concurrent.**ThreadPoolExecutor$Worker.** runTask(ThreadPoolExecutor.**java:886)[:1.6.0_32] at java.util.concurrent.**ThreadPoolExecutor$Worker.run(** ThreadPoolExecutor.java:908)[:**1.6.0_32] at
Re: Problems with Karaf 2.3.1 and Cxf
Hello Freeman, It would be a lot of work for me to narrow down my application to a simple test case. I'd really like to try other possibilities first, like: - Understanding how the factory pattern is supposed to work, espcially for Cxf - What has been changed in Karaf 2.3.1. that could affect this /Bengt 2013/4/2 Freeman Fang freeman.f...@gmail.com Hi, No concrete idea now, could you please append a test case which we can build and reproduce it? Thanks － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午3:30, Bengt Rodehav wrote: I've been using Karaf 2.3.0 for a while. I now tried to upgrade to Karaf 2.3.1 but ran into problems with CXF. I use cxf-codegen-plugin to generate code from a WSDL file so that I can call the web service via a proxy. However, after upgrading to Karaf 2.3.1 I get the following exception: 2013-04-02 09:19:03,317 | ERROR | rint Extender: 3 | BlueprintContainerImpl | container.BlueprintContainerImpl 393 | Unable to start blueprint container for bundle se.digia.connect.services.iso20022.iws-client org.osgi.service.blueprint.container.ComponentDefinitionException: Error when instantiating bean iwsService of class class se.digia.connect.iso20022.iwsclient.Client at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_32] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_32] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_32] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_32] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_32] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_32] at java.lang.Thread.run(Thread.java:662)[:1.6.0_32] Caused by: javax.xml.ws.spi.FactoryFinder$ConfigurationError: Provider org.apache.cxf.jaxws.spi.ProviderImpl not found at javax.xml.ws.spi.FactoryFinder$2.run(FactoryFinder.java:130) at javax.xml.ws.spi.FactoryFinder.doPrivileged(FactoryFinder.java:229)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder.newInstance(FactoryFinder.java:124)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder.access$200(FactoryFinder.java:44)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder$3.run(FactoryFinder.java:220) at javax.xml.ws.spi.FactoryFinder.doPrivileged(FactoryFinder.java:229)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:160)[:1.6.0_32] at
Re: Problems with Karaf 2.3.1 and Cxf
I found this blog post by Dan Kulp: http://www.dankulp.com/blog/2011/11/apache-cxf-in-osgi/ I modified the jre.properties accordingly but I still get the exact same stack trace. /Bengt 2013/4/2 Bengt Rodehav be...@rodehav.com Hello Freeman, It would be a lot of work for me to narrow down my application to a simple test case. I'd really like to try other possibilities first, like: - Understanding how the factory pattern is supposed to work, espcially for Cxf - What has been changed in Karaf 2.3.1. that could affect this /Bengt 2013/4/2 Freeman Fang freeman.f...@gmail.com Hi, No concrete idea now, could you please append a test case which we can build and reproduce it? Thanks － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午3:30, Bengt Rodehav wrote: I've been using Karaf 2.3.0 for a while. I now tried to upgrade to Karaf 2.3.1 but ran into problems with CXF. I use cxf-codegen-plugin to generate code from a WSDL file so that I can call the web service via a proxy. However, after upgrading to Karaf 2.3.1 I get the following exception: 2013-04-02 09:19:03,317 | ERROR | rint Extender: 3 | BlueprintContainerImpl | container.BlueprintContainerImpl 393 | Unable to start blueprint container for bundle se.digia.connect.services.iso20022.iws-client org.osgi.service.blueprint.container.ComponentDefinitionException: Error when instantiating bean iwsService of class class se.digia.connect.iso20022.iwsclient.Client at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_32] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_32] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_32] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_32] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_32] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_32] at java.lang.Thread.run(Thread.java:662)[:1.6.0_32] Caused by: javax.xml.ws.spi.FactoryFinder$ConfigurationError: Provider org.apache.cxf.jaxws.spi.ProviderImpl not found at javax.xml.ws.spi.FactoryFinder$2.run(FactoryFinder.java:130) at javax.xml.ws.spi.FactoryFinder.doPrivileged(FactoryFinder.java:229)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder.newInstance(FactoryFinder.java:124)[:1.6.0_32] at javax.xml.ws.spi.FactoryFinder.access$200(FactoryFinder.java:44)[:1.6.0_32] at
Re: Problems with Karaf 2.3.1 and Cxf
It's the jre.properties that I'm taking about. It should be provided in etc/jre.properties.cxf. So the problem is not about a JRE package mismatch. I gonna take a deeper look (especially around the dependencies updates between 2.3.0 and 2.3.1). Regards JB On 04/02/2013 10:38 AM, Bengt Rodehav wrote: I found this blog post by Dan Kulp: http://www.dankulp.com/blog/2011/11/apache-cxf-in-osgi/ I modified the jre.properties accordingly but I still get the exact same stack trace. /Bengt 2013/4/2 Bengt Rodehav be...@rodehav.com mailto:be...@rodehav.com Hello Freeman, It would be a lot of work for me to narrow down my application to a simple test case. I'd really like to try other possibilities first, like: - Understanding how the factory pattern is supposed to work, espcially for Cxf - What has been changed in Karaf 2.3.1. that could affect this /Bengt 2013/4/2 Freeman Fang freeman.f...@gmail.com mailto:freeman.f...@gmail.com Hi, No concrete idea now, could you please append a test case which we can build and reproduce it? Thanks － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午3:30, Bengt Rodehav wrote: I've been using Karaf 2.3.0 for a while. I now tried to upgrade to Karaf 2.3.1 but ran into problems with CXF. I use cxf-codegen-plugin to generate code from a WSDL file so that I can call the web service via a proxy. However, after upgrading to Karaf 2.3.1 I get the following exception: 2013-04-02 09:19:03,317 | ERROR | rint Extender: 3 | BlueprintContainerImpl | container.BlueprintContainerImpl 393 | Unable to start blueprint container for bundle se.digia.connect.services.iso20022.iws-client org.osgi.service.blueprint.container.ComponentDefinitionException: Error when instantiating bean iwsService of class class se.digia.connect.iso20022.iwsclient.Client at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_32] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_32] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at
Re: Problems with Karaf 2.3.1 and Cxf
Thanks JB, I did notice that Karaf provides servicemix-specs API bundles in lib\endorsed. It includes jaxws. I thought that these jar's overrode the JVM. If so, then you shouldn't need to modifiy the jre.properties - or have I got it all wrong? /Bengt 2013/4/2 Jean-Baptiste Onofré j...@nanthrax.net It's the jre.properties that I'm taking about. It should be provided in etc/jre.properties.cxf. So the problem is not about a JRE package mismatch. I gonna take a deeper look (especially around the dependencies updates between 2.3.0 and 2.3.1). Regards JB On 04/02/2013 10:38 AM, Bengt Rodehav wrote: I found this blog post by Dan Kulp: http://www.dankulp.com/blog/**2011/11/apache-cxf-in-osgi/http://www.dankulp.com/blog/2011/11/apache-cxf-in-osgi/ I modified the jre.properties accordingly but I still get the exact same stack trace. /Bengt 2013/4/2 Bengt Rodehav be...@rodehav.com mailto:be...@rodehav.com Hello Freeman, It would be a lot of work for me to narrow down my application to a simple test case. I'd really like to try other possibilities first, like: - Understanding how the factory pattern is supposed to work, espcially for Cxf - What has been changed in Karaf 2.3.1. that could affect this /Bengt 2013/4/2 Freeman Fang freeman.f...@gmail.com mailto:freeman.f...@gmail.com** Hi, No concrete idea now, could you please append a test case which we can build and reproduce it? Thanks － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.**comhttp://freemanfang.blogspot.com http://blog.sina.com.cn/u/**1473905042http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午3:30, Bengt Rodehav wrote: I've been using Karaf 2.3.0 for a while. I now tried to upgrade to Karaf 2.3.1 but ran into problems with CXF. I use cxf-codegen-plugin to generate code from a WSDL file so that I can call the web service via a proxy. However, after upgrading to Karaf 2.3.1 I get the following exception: 2013-04-02 09:19:03,317 | ERROR | rint Extender: 3 | BlueprintContainerImpl | container.**BlueprintContainerImpl 393 | Unable to start blueprint container for bundle se.digia.connect.services.**iso20022.iws-client org.osgi.service.blueprint.**container.** ComponentDefinitionException: Error when instantiating bean iwsService of class class se.digia.connect.iso20022.**iwsclient.Client at org.apache.aries.blueprint.**container.BeanRecipe.** getInstance(BeanRecipe.java:**333)[7:org.apache.aries.** blueprint.core:1.1.0] at org.apache.aries.blueprint.**container.BeanRecipe.** internalCreate2(BeanRecipe.**java:806)[7:org.apache.aries.** blueprint.core:1.1.0] at org.apache.aries.blueprint.**container.BeanRecipe.** internalCreate(BeanRecipe.**java:787)[7:org.apache.aries.** blueprint.core:1.1.0] at org.apache.aries.blueprint.di.**AbstractRecipe$1.call(** AbstractRecipe.java:79)[7:org.**apache.aries.blueprint.core:1.**1.0] at java.util.concurrent.**FutureTask$Sync.innerRun(** FutureTask.java:303)[:1.6.0_**32] at java.util.concurrent.**FutureTask.run(FutureTask.** java:138)[:1.6.0_32] at org.apache.aries.blueprint.di.**AbstractRecipe.create(** AbstractRecipe.java:88)[7:org.**apache.aries.blueprint.core:1.**1.0] at org.apache.aries.blueprint.**container.BlueprintRepository.** createInstances(**BlueprintRepository.java:245)[** 7:org.apache.aries.blueprint.**core:1.1.0] at org.apache.aries.blueprint.**container.BlueprintRepository.** createAll(BlueprintRepository.**java:183)[7:org.apache.aries.** blueprint.core:1.1.0] at org.apache.aries.blueprint.**container.**BlueprintContainerImpl. **instantiateEagerComponents(**BlueprintContainerImpl.java:** 668)[7:org.apache.aries.**blueprint.core:1.1.0] at org.apache.aries.blueprint.**container.** BlueprintContainerImpl.doRun(**BlueprintContainerImpl.java:** 370)[7:org.apache.aries.**blueprint.core:1.1.0] at org.apache.aries.blueprint.**container.** BlueprintContainerImpl.run(**BlueprintContainerImpl.java:** 261)[7:org.apache.aries.**blueprint.core:1.1.0] at java.util.concurrent.**Executors$RunnableAdapter.** call(Executors.java:441)[:1.6.**0_32] at java.util.concurrent.**FutureTask$Sync.innerRun(** FutureTask.java:303)[:1.6.0_**32] at java.util.concurrent.**FutureTask.run(FutureTask.** java:138)[:1.6.0_32] at
Re: Problems with Karaf 2.3.1 and Cxf
Hi, No, that blog is a little bit out of data and not applicable for Karaf 2.3.x anymore. With Karaf 2.3.x we endorse specs(like jaxws/jaxb) jars, so we need export those packages from system bundle 0, so don't comment it out and those endorsed specs jars can load jaxws impl bundle(cxf jaxws frontend bundle in this case) during runtime OOTB. No concrete idea why it doesn't work for you(also I don't think there's any real difference between karaf 2.3 and karaf 2.3.1 in terms of jaxws loading mechanism), that's why I ask a test case, it's definitely very helpful to resolve the issue faster. － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午4:38, Bengt Rodehav wrote: I found this blog post by Dan Kulp: http://www.dankulp.com/blog/2011/11/apache-cxf-in-osgi/ I modified the jre.properties accordingly but I still get the exact same stack trace. /Bengt 2013/4/2 Bengt Rodehav be...@rodehav.com Hello Freeman, It would be a lot of work for me to narrow down my application to a simple test case. I'd really like to try other possibilities first, like: - Understanding how the factory pattern is supposed to work, espcially for Cxf - What has been changed in Karaf 2.3.1. that could affect this /Bengt 2013/4/2 Freeman Fang freeman.f...@gmail.com Hi, No concrete idea now, could you please append a test case which we can build and reproduce it? Thanks － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午3:30, Bengt Rodehav wrote: I've been using Karaf 2.3.0 for a while. I now tried to upgrade to Karaf 2.3.1 but ran into problems with CXF. I use cxf-codegen-plugin to generate code from a WSDL file so that I can call the web service via a proxy. However, after upgrading to Karaf 2.3.1 I get the following exception: 2013-04-02 09:19:03,317 | ERROR | rint Extender: 3 | BlueprintContainerImpl | container.BlueprintContainerImpl 393 | Unable to start blueprint container for bundle se.digia.connect.services.iso20022.iws-client org.osgi.service.blueprint.container.ComponentDefinitionException: Error when instantiating bean iwsService of class class se.digia.connect.iso20022.iwsclient.Client at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_32] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_32] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at
Re: Problems with Karaf 2.3.1 and Cxf
Hi, You are right, I just replied you about it. － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午4:54, Bengt Rodehav wrote: Thanks JB, I did notice that Karaf provides servicemix-specs API bundles in lib\endorsed. It includes jaxws. I thought that these jar's overrode the JVM. If so, then you shouldn't need to modifiy the jre.properties - or have I got it all wrong? /Bengt 2013/4/2 Jean-Baptiste Onofré j...@nanthrax.net It's the jre.properties that I'm taking about. It should be provided in etc/jre.properties.cxf. So the problem is not about a JRE package mismatch. I gonna take a deeper look (especially around the dependencies updates between 2.3.0 and 2.3.1). Regards JB On 04/02/2013 10:38 AM, Bengt Rodehav wrote: I found this blog post by Dan Kulp: http://www.dankulp.com/blog/2011/11/apache-cxf-in-osgi/ I modified the jre.properties accordingly but I still get the exact same stack trace. /Bengt 2013/4/2 Bengt Rodehav be...@rodehav.com mailto:be...@rodehav.com Hello Freeman, It would be a lot of work for me to narrow down my application to a simple test case. I'd really like to try other possibilities first, like: - Understanding how the factory pattern is supposed to work, espcially for Cxf - What has been changed in Karaf 2.3.1. that could affect this /Bengt 2013/4/2 Freeman Fang freeman.f...@gmail.com mailto:freeman.f...@gmail.com Hi, No concrete idea now, could you please append a test case which we can build and reproduce it? Thanks － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午3:30, Bengt Rodehav wrote: I've been using Karaf 2.3.0 for a while. I now tried to upgrade to Karaf 2.3.1 but ran into problems with CXF. I use cxf-codegen-plugin to generate code from a WSDL file so that I can call the web service via a proxy. However, after upgrading to Karaf 2.3.1 I get the following exception: 2013-04-02 09:19:03,317 | ERROR | rint Extender: 3 | BlueprintContainerImpl | container.BlueprintContainerImpl 393 | Unable to start blueprint container for bundle se.digia.connect.services.iso20022.iws-client org.osgi.service.blueprint.container.ComponentDefinitionException: Error when instantiating bean iwsService of class class se.digia.connect.iso20022.iwsclient.Client at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_32] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at
Re: Problems with Karaf 2.3.1 and Cxf
I'll see if I can get a test case done for this although it might take a while. Meanwhile, can you explain what mechanism is used for resolving the implementation classes. I mean, how is the system bundle supposed to resolve a class that resides in another bundle? (In this case the cxf-rt-frontend). /Bengt 2013/4/2 Freeman Fang freeman.f...@gmail.com Hi, No, that blog is a little bit out of data and not applicable for Karaf 2.3.x anymore. With Karaf 2.3.x we endorse specs(like jaxws/jaxb) jars, so we need export those packages from system bundle 0, so don't comment it out and those endorsed specs jars can load jaxws impl bundle(cxf jaxws frontend bundle in this case) during runtime OOTB. No concrete idea why it doesn't work for you(also I don't think there's any real difference between karaf 2.3 and karaf 2.3.1 in terms of jaxws loading mechanism), that's why I ask a test case, it's definitely very helpful to resolve the issue faster. － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午4:38, Bengt Rodehav wrote: I found this blog post by Dan Kulp: http://www.dankulp.com/blog/2011/11/apache-cxf-in-osgi/ I modified the jre.properties accordingly but I still get the exact same stack trace. /Bengt 2013/4/2 Bengt Rodehav be...@rodehav.com Hello Freeman, It would be a lot of work for me to narrow down my application to a simple test case. I'd really like to try other possibilities first, like: - Understanding how the factory pattern is supposed to work, espcially for Cxf - What has been changed in Karaf 2.3.1. that could affect this /Bengt 2013/4/2 Freeman Fang freeman.f...@gmail.com Hi, No concrete idea now, could you please append a test case which we can build and reproduce it? Thanks － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午3:30, Bengt Rodehav wrote: I've been using Karaf 2.3.0 for a while. I now tried to upgrade to Karaf 2.3.1 but ran into problems with CXF. I use cxf-codegen-plugin to generate code from a WSDL file so that I can call the web service via a proxy. However, after upgrading to Karaf 2.3.1 I get the following exception: 2013-04-02 09:19:03,317 | ERROR | rint Extender: 3 | BlueprintContainerImpl | container.BlueprintContainerImpl 393 | Unable to start blueprint container for bundle se.digia.connect.services.iso20022.iws-client org.osgi.service.blueprint.container.ComponentDefinitionException: Error when instantiating bean iwsService of class class se.digia.connect.iso20022.iwsclient.Client at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_32] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)[7:org.apache.aries.blueprint.core:1.1.0] at
Re: Problems with Karaf 2.3.1 and Cxf
Hi, Good question, yeah, the traditional JAVA SPI mechanism generally doesn't work in OSGi container. So Servicemix Specs project[1] use OSGi locator to resolve this problem, Guillaume has a blog about it years ago[2] [1]https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/ [2]http://gnodet.blogspot.com/2008/05/jee-specs-in-osgi.html － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午5:07, Bengt Rodehav wrote: I'll see if I can get a test case done for this although it might take a while. Meanwhile, can you explain what mechanism is used for resolving the implementation classes. I mean, how is the system bundle supposed to resolve a class that resides in another bundle? (In this case the cxf-rt-frontend). /Bengt 2013/4/2 Freeman Fang freeman.f...@gmail.com Hi, No, that blog is a little bit out of data and not applicable for Karaf 2.3.x anymore. With Karaf 2.3.x we endorse specs(like jaxws/jaxb) jars, so we need export those packages from system bundle 0, so don't comment it out and those endorsed specs jars can load jaxws impl bundle(cxf jaxws frontend bundle in this case) during runtime OOTB. No concrete idea why it doesn't work for you(also I don't think there's any real difference between karaf 2.3 and karaf 2.3.1 in terms of jaxws loading mechanism), that's why I ask a test case, it's definitely very helpful to resolve the issue faster. － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午4:38, Bengt Rodehav wrote: I found this blog post by Dan Kulp: http://www.dankulp.com/blog/2011/11/apache-cxf-in-osgi/ I modified the jre.properties accordingly but I still get the exact same stack trace. /Bengt 2013/4/2 Bengt Rodehav be...@rodehav.com Hello Freeman, It would be a lot of work for me to narrow down my application to a simple test case. I'd really like to try other possibilities first, like: - Understanding how the factory pattern is supposed to work, espcially for Cxf - What has been changed in Karaf 2.3.1. that could affect this /Bengt 2013/4/2 Freeman Fang freeman.f...@gmail.com Hi, No concrete idea now, could you please append a test case which we can build and reproduce it? Thanks － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午3:30, Bengt Rodehav wrote: I've been using Karaf 2.3.0 for a while. I now tried to upgrade to Karaf 2.3.1 but ran into problems with CXF. I use cxf-codegen-plugin to generate code from a WSDL file so that I can call the web service via a proxy. However, after upgrading to Karaf 2.3.1 I get the following exception: 2013-04-02 09:19:03,317 | ERROR | rint Extender: 3 | BlueprintContainerImpl | container.BlueprintContainerImpl 393 | Unable to start blueprint container for bundle se.digia.connect.services.iso20022.iws-client org.osgi.service.blueprint.container.ComponentDefinitionException: Error when instantiating bean iwsService of class class se.digia.connect.iso20022.iwsclient.Client at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668)[7:org.apache.aries.blueprint.core:1.1.0] at
Re: Problems with Karaf 2.3.1 and Cxf
Thanks, will read the blog. 2013/4/2 Freeman Fang freeman.f...@gmail.com Hi, Good question, yeah, the traditional JAVA SPI mechanism generally doesn't work in OSGi container. So Servicemix Specs project[1] use OSGi locator to resolve this problem, Guillaume has a blog about it years ago[2] [1]https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/ [2]http://gnodet.blogspot.com/2008/05/jee-specs-in-osgi.html － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午5:07, Bengt Rodehav wrote: I'll see if I can get a test case done for this although it might take a while. Meanwhile, can you explain what mechanism is used for resolving the implementation classes. I mean, how is the system bundle supposed to resolve a class that resides in another bundle? (In this case the cxf-rt-frontend). /Bengt 2013/4/2 Freeman Fang freeman.f...@gmail.com Hi, No, that blog is a little bit out of data and not applicable for Karaf 2.3.x anymore. With Karaf 2.3.x we endorse specs(like jaxws/jaxb) jars, so we need export those packages from system bundle 0, so don't comment it out and those endorsed specs jars can load jaxws impl bundle(cxf jaxws frontend bundle in this case) during runtime OOTB. No concrete idea why it doesn't work for you(also I don't think there's any real difference between karaf 2.3 and karaf 2.3.1 in terms of jaxws loading mechanism), that's why I ask a test case, it's definitely very helpful to resolve the issue faster. － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午4:38, Bengt Rodehav wrote: I found this blog post by Dan Kulp: http://www.dankulp.com/blog/2011/11/apache-cxf-in-osgi/ I modified the jre.properties accordingly but I still get the exact same stack trace. /Bengt 2013/4/2 Bengt Rodehav be...@rodehav.com Hello Freeman, It would be a lot of work for me to narrow down my application to a simple test case. I'd really like to try other possibilities first, like: - Understanding how the factory pattern is supposed to work, espcially for Cxf - What has been changed in Karaf 2.3.1. that could affect this /Bengt 2013/4/2 Freeman Fang freeman.f...@gmail.com Hi, No concrete idea now, could you please append a test case which we can build and reproduce it? Thanks － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午3:30, Bengt Rodehav wrote: I've been using Karaf 2.3.0 for a while. I now tried to upgrade to Karaf 2.3.1 but ran into problems with CXF. I use cxf-codegen-plugin to generate code from a WSDL file so that I can call the web service via a proxy. However, after upgrading to Karaf 2.3.1 I get the following exception: 2013-04-02 09:19:03,317 | ERROR | rint Extender: 3 | BlueprintContainerImpl | container.BlueprintContainerImpl 393 | Unable to start blueprint container for bundle se.digia.connect.services.iso20022.iws-client org.osgi.service.blueprint.container.ComponentDefinitionException: Error when instantiating bean iwsService of class class se.digia.connect.iso20022.iwsclient.Client at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[7:org.apache.aries.blueprint.core:1.1.0] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_32] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_32] at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[7:org.apache.aries.blueprint.core:1.1.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668)[7:org.apache.aries.blueprint.core:1.1.0] at
Re: Problems with Karaf 2.3.1 and Cxf
I read the blog but it didn't go into details regarding how the implementation classes are found - I guess I'll have to look in the code. One observation regarding my problem: What gives me an exception is when blueprint attempts to instantiate my class. In my class constructor I try to create the web service proxy. I did try to import the org.apache.cxf.jaxws.spi package to the bundle that contains the class that cannot be instantiated. I can see in runtime that the bundle does indeed import the org.apache.cxf.jaxws.spi package from the cxf-rt-frontend bundle. But I still get the exception indicating that it cannot find the org.apache.cxf.jaxws.spi.ProviderImpl class. Thus, putting the ProviderImpl class in my bundle's classpath doesn't help. It seems like it has to be in the system bundle's classpath. I really don't know how that mechanism is supposed to work - but it did work in Karaf 2.3.0. Does the new blueprint version do some classloading magic? /Bengt 2013/4/2 Bengt Rodehav be...@rodehav.com Thanks, will read the blog. 2013/4/2 Freeman Fang freeman.f...@gmail.com Hi, Good question, yeah, the traditional JAVA SPI mechanism generally doesn't work in OSGi container. So Servicemix Specs project[1] use OSGi locator to resolve this problem, Guillaume has a blog about it years ago[2] [1]https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/ [2]http://gnodet.blogspot.com/2008/05/jee-specs-in-osgi.html － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午5:07, Bengt Rodehav wrote: I'll see if I can get a test case done for this although it might take a while. Meanwhile, can you explain what mechanism is used for resolving the implementation classes. I mean, how is the system bundle supposed to resolve a class that resides in another bundle? (In this case the cxf-rt-frontend). /Bengt 2013/4/2 Freeman Fang freeman.f...@gmail.com Hi, No, that blog is a little bit out of data and not applicable for Karaf 2.3.x anymore. With Karaf 2.3.x we endorse specs(like jaxws/jaxb) jars, so we need export those packages from system bundle 0, so don't comment it out and those endorsed specs jars can load jaxws impl bundle(cxf jaxws frontend bundle in this case) during runtime OOTB. No concrete idea why it doesn't work for you(also I don't think there's any real difference between karaf 2.3 and karaf 2.3.1 in terms of jaxws loading mechanism), that's why I ask a test case, it's definitely very helpful to resolve the issue faster. － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午4:38, Bengt Rodehav wrote: I found this blog post by Dan Kulp: http://www.dankulp.com/blog/2011/11/apache-cxf-in-osgi/ I modified the jre.properties accordingly but I still get the exact same stack trace. /Bengt 2013/4/2 Bengt Rodehav be...@rodehav.com Hello Freeman, It would be a lot of work for me to narrow down my application to a simple test case. I'd really like to try other possibilities first, like: - Understanding how the factory pattern is supposed to work, espcially for Cxf - What has been changed in Karaf 2.3.1. that could affect this /Bengt 2013/4/2 Freeman Fang freeman.f...@gmail.com Hi, No concrete idea now, could you please append a test case which we can build and reproduce it? Thanks － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午3:30, Bengt Rodehav wrote: I've been using Karaf 2.3.0 for a while. I now tried to upgrade to Karaf 2.3.1 but ran into problems with CXF. I use cxf-codegen-plugin to generate code from a WSDL file so that I can call the web service via a proxy. However, after upgrading to Karaf 2.3.1 I get the following exception: 2013-04-02 09:19:03,317 | ERROR | rint Extender: 3 | BlueprintContainerImpl | container.BlueprintContainerImpl 393 | Unable to start blueprint container for bundle se.digia.connect.services.iso20022.iws-client org.osgi.service.blueprint.container.ComponentDefinitionException: Error when instantiating bean iwsService of class class se.digia.connect.iso20022.iwsclient.Client at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[7:org.apache.aries.blueprint.core:1.1.0] at
Re: Problems with Karaf 2.3.1 and Cxf
Another observation. In Cxf 2.6.3 feature descriptor, the feature cxf-specs include, among others, 2.2 versions of jaxb-api and jaxws-api. Since the corresponding api's are only on 2.1 level in Karaf 2.3.0 lib\endorsed, the bundles are used instead. But, Karaf 2.3.1 has updated the endorsed libraries to version 2.2 which means that they are now used by Cxf instead of the bundles listed in the cxf-spec feature. In other words, the Cxf feature descriptor must (or should) be changed in order to work under Karaf 2.3.1. Perhaps this has been done in later versions of Cxf - I haven't checked. Even if I fix this I'm still not done since I don't know how to get the endorsed versions to work with Cxf. Hopefully someone knows how to get that to work. /Bengt 2013/4/2 Bengt Rodehav be...@rodehav.com No, I did not update the Cxf version. I use Cxf 2.6.3 in both cases. I wonder why the cxf-api bundle imports the org.apache.cxf.jaxws.spi package. Maybe it's been done by accident but it still is what makes it work under Karaf 2.3.0... I'm currently looking at the source code for the FactoryFinder class that does the actual loading of the factory class. It does seem like it uses the TCCL. Do you know if I'm supposed to set the TCCL manually? What is the actual usage pattern here? /Bengt 2013/4/2 Jean-Baptiste Onofré j...@nanthrax.net Hi Bengt, it can but it doesn't come from Karaf. I guess that you updated the CXF version as well ? Regards JB On 04/02/2013 02:01 PM, Bengt Rodehav wrote: I compared Karaf 2.3.0 with 2.3.1 and noticed that (with my configuration) in Karaf 2.3.0, the org.apache.cxf.cxf-api bundle imports the org.apache.cxf.jaxws.spi package from the cxf-rt-frontend bundle. This does not happen in Karaf 2.3.1. Could this cause the problem? /Bengt 2013/4/2 Bengt Rodehav be...@rodehav.com mailto:be...@rodehav.com I read the blog but it didn't go into details regarding how the implementation classes are found - I guess I'll have to look in the code. One observation regarding my problem: What gives me an exception is when blueprint attempts to instantiate my class. In my class constructor I try to create the web service proxy. I did try to import the org.apache.cxf.jaxws.spi package to the bundle that contains the class that cannot be instantiated. I can see in runtime that the bundle does indeed import the org.apache.cxf.jaxws.spi package from the cxf-rt-frontend bundle. But I still get the exception indicating that it cannot find the org.apache.cxf.jaxws.spi.**ProviderImpl class. Thus, putting the ProviderImpl class in my bundle's classpath doesn't help. It seems like it has to be in the system bundle's classpath. I really don't know how that mechanism is supposed to work - but it did work in Karaf 2.3.0. Does the new blueprint version do some classloading magic? /Bengt 2013/4/2 Bengt Rodehav be...@rodehav.com mailto:be...@rodehav.com Thanks, will read the blog. 2013/4/2 Freeman Fang freeman.f...@gmail.com mailto:freeman.f...@gmail.com** Hi, Good question, yeah, the traditional JAVA SPI mechanism generally doesn't work in OSGi container. So Servicemix Specs project[1] use OSGi locator to resolve this problem, Guillaume has a blog about it years ago[2] [1]https://svn.apache.org/**repos/asf/servicemix/smx4/** specs/trunk/https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/ [2]http://gnodet.blogspot.com/** 2008/05/jee-specs-in-osgi.htmlhttp://gnodet.blogspot.com/2008/05/jee-specs-in-osgi.html － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.**comhttp://freemanfang.blogspot.com http://blog.sina.com.cn/u/**1473905042http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午5:07, Bengt Rodehav wrote: I'll see if I can get a test case done for this although it might take a while. Meanwhile, can you explain what mechanism is used for resolving the implementation classes. I mean, how is the system bundle supposed to resolve a class that resides in another bundle? (In this case the cxf-rt-frontend). /Bengt 2013/4/2 Freeman Fang freeman.f...@gmail.com mailto:freeman.f...@gmail.com** Hi, No, that blog is a little bit out of data and not applicable for Karaf 2.3.x anymore. With Karaf 2.3.x we endorse specs(like jaxws/jaxb) jars, so we need export those
Re: Problems with Karaf 2.3.1 and Cxf
Just checked the feature descriptor for Cxf 2.7.3. It still includes the 2.2 api's. I wonder if anyone has gotten this to work on Karaf 2.3.1 and, if so, how they did it. /Bengt 2013/4/2 Bengt Rodehav be...@rodehav.com Another observation. In Cxf 2.6.3 feature descriptor, the feature cxf-specs include, among others, 2.2 versions of jaxb-api and jaxws-api. Since the corresponding api's are only on 2.1 level in Karaf 2.3.0 lib\endorsed, the bundles are used instead. But, Karaf 2.3.1 has updated the endorsed libraries to version 2.2 which means that they are now used by Cxf instead of the bundles listed in the cxf-spec feature. In other words, the Cxf feature descriptor must (or should) be changed in order to work under Karaf 2.3.1. Perhaps this has been done in later versions of Cxf - I haven't checked. Even if I fix this I'm still not done since I don't know how to get the endorsed versions to work with Cxf. Hopefully someone knows how to get that to work. /Bengt 2013/4/2 Bengt Rodehav be...@rodehav.com No, I did not update the Cxf version. I use Cxf 2.6.3 in both cases. I wonder why the cxf-api bundle imports the org.apache.cxf.jaxws.spi package. Maybe it's been done by accident but it still is what makes it work under Karaf 2.3.0... I'm currently looking at the source code for the FactoryFinder class that does the actual loading of the factory class. It does seem like it uses the TCCL. Do you know if I'm supposed to set the TCCL manually? What is the actual usage pattern here? /Bengt 2013/4/2 Jean-Baptiste Onofré j...@nanthrax.net Hi Bengt, it can but it doesn't come from Karaf. I guess that you updated the CXF version as well ? Regards JB On 04/02/2013 02:01 PM, Bengt Rodehav wrote: I compared Karaf 2.3.0 with 2.3.1 and noticed that (with my configuration) in Karaf 2.3.0, the org.apache.cxf.cxf-api bundle imports the org.apache.cxf.jaxws.spi package from the cxf-rt-frontend bundle. This does not happen in Karaf 2.3.1. Could this cause the problem? /Bengt 2013/4/2 Bengt Rodehav be...@rodehav.com mailto:be...@rodehav.com I read the blog but it didn't go into details regarding how the implementation classes are found - I guess I'll have to look in the code. One observation regarding my problem: What gives me an exception is when blueprint attempts to instantiate my class. In my class constructor I try to create the web service proxy. I did try to import the org.apache.cxf.jaxws.spi package to the bundle that contains the class that cannot be instantiated. I can see in runtime that the bundle does indeed import the org.apache.cxf.jaxws.spi package from the cxf-rt-frontend bundle. But I still get the exception indicating that it cannot find the org.apache.cxf.jaxws.spi.**ProviderImpl class. Thus, putting the ProviderImpl class in my bundle's classpath doesn't help. It seems like it has to be in the system bundle's classpath. I really don't know how that mechanism is supposed to work - but it did work in Karaf 2.3.0. Does the new blueprint version do some classloading magic? /Bengt 2013/4/2 Bengt Rodehav be...@rodehav.com mailto:be...@rodehav.com Thanks, will read the blog. 2013/4/2 Freeman Fang freeman.f...@gmail.com mailto:freeman.f...@gmail.com** Hi, Good question, yeah, the traditional JAVA SPI mechanism generally doesn't work in OSGi container. So Servicemix Specs project[1] use OSGi locator to resolve this problem, Guillaume has a blog about it years ago[2] [1]https://svn.apache.org/**repos/asf/servicemix/smx4/** specs/trunk/https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/ [2]http://gnodet.blogspot.com/** 2008/05/jee-specs-in-osgi.htmlhttp://gnodet.blogspot.com/2008/05/jee-specs-in-osgi.html － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.**comhttp://freemanfang.blogspot.com http://blog.sina.com.cn/u/**1473905042http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午5:07, Bengt Rodehav wrote: I'll see if I can get a test case done for this although it might take a while. Meanwhile, can you explain what mechanism is used for resolving the implementation classes. I mean, how is the system bundle supposed to resolve a class that resides in another bundle? (In this case the cxf-rt-frontend). /Bengt 2013/4/2 Freeman Fang freeman.f...@gmail.com mailto:freeman.f...@gmail.com** Hi,
