You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Bengt Rodehav <be...@rodehav.com> on 2013/04/02 09:30:38 UTC
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
org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)
at
org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)
... 24 more
Has anything changed in Karaf 2.3.1 that could cause this? My main reason
for upgrading to Karaf 2.3.1 is the fixes that has been done to Aries
blueprint - could it cause this?
/Bengt
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Bengt Rodehav <be...@rodehav.com>.
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é <jb...@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 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.**DelegatingConstructorAccessorI**mpl.newInstance(**
>> DelegatingConstructorAccessorI**mpl.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
>> org.apache.aries.blueprint.**container.BeanRecipe.**
>> newInstance(BeanRecipe.java:**962)
>> at
>> org.apache.aries.blueprint.**container.BeanRecipe.**
>> getInstance(BeanRecipe.java:**331)
>> ... 24 more
>>
>> Has anything changed in Karaf 2.3.1 that could cause this? My main
>> reason for upgrading to Karaf 2.3.1 is the fixes that has been done to
>> Aries blueprint - could it cause this?
>>
>> /Bengt
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Jean-Baptiste Onofré <jb...@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 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
> org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)
> at
> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)
> ... 24 more
>
> Has anything changed in Karaf 2.3.1 that could cause this? My main
> reason for upgrading to Karaf 2.3.1 is the fixes that has been done to
> Aries blueprint - could it cause this?
>
> /Bengt
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Freeman Fang <fr...@gmail.com>.
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é <jb...@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 <bengt@rodehav.com <ma...@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.fang@gmail.com
> <ma...@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 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
> org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)
> at
> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)
> ... 24 more
>
> Has anything changed in Karaf 2.3.1 that could cause this? My
> main reason for upgrading to Karaf 2.3.1 is the fixes that has
> been done to Aries blueprint - could it cause this?
>
> /Bengt
>
>
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Bengt Rodehav <be...@rodehav.com>.
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é <jb...@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 <bengt@rodehav.com <ma...@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.fang@gmail.com
>> <mailto:freeman.fang@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://freemanfang.blogspot.com>
>> http://blog.sina.com.cn/u/**1473905042<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
>>> 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.**DelegatingConstructorAccessorI**mpl.newInstance(**
>>> DelegatingConstructorAccessorI**mpl.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
>>> org.apache.aries.blueprint.**container.BeanRecipe.**
>>> newInstance(BeanRecipe.java:**962)
>>> at
>>> org.apache.aries.blueprint.**container.BeanRecipe.**
>>> getInstance(BeanRecipe.java:**331)
>>> ... 24 more
>>>
>>> Has anything changed in Karaf 2.3.1 that could cause this? My
>>> main reason for upgrading to Karaf 2.3.1 is the fixes that has
>>> been done to Aries blueprint - could it cause this?
>>>
>>> /Bengt
>>>
>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Jean-Baptiste Onofré <jb...@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 <bengt@rodehav.com <ma...@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.fang@gmail.com
> <ma...@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 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
>> org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)
>> at
>> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)
>> ... 24 more
>>
>> Has anything changed in Karaf 2.3.1 that could cause this? My
>> main reason for upgrading to Karaf 2.3.1 is the fixes that has
>> been done to Aries blueprint - could it cause this?
>>
>> /Bengt
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Bengt Rodehav <be...@rodehav.com>.
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é <jb...@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 <bengt@rodehav.com <ma...@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 <bengt@rodehav.com <mailto:bengt@rodehav.com
>>>> >>
>>>>
>>>>
>>>> Thanks, will read the blog.
>>>>
>>>>
>>>> 2013/4/2 Freeman Fang <freeman.fang@gmail.com
>>>> <mailto:freeman.fang@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.html<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://freemanfang.blogspot.com>
>>>> http://blog.sina.com.cn/u/**1473905042<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.fang@gmail.com
>>>>> <mailto:freeman.fang@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://fusesource.com/> |
>>>>>
>>>>> http://www.redhat.com/
>>>>> Twitter: freemanfang
>>>>> Blog: http://freemanfang.blogspot.**com<http://freemanfang.blogspot.com>
>>>>> <http://freemanfang.blogspot.**com/<http://freemanfang.blogspot.com/>
>>>>> >
>>>>>
>>>>> http://blog.sina.com.cn/u/**1473905042<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/<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 <bengt@rodehav.com
>>>>>> <ma...@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.fang@gmail.com
>>>>>> <mailto:freeman.fang@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://fusesource.com/> |
>>>>>> http://www.redhat.com/
>>>>>>
>>>>>> Twitter: freemanfang
>>>>>> Blog: http://freemanfang.blogspot.**com<http://freemanfang.blogspot.com>
>>>>>> <http://freemanfang.blogspot.**com/<http://freemanfang.blogspot.com/>
>>>>>> >
>>>>>>
>>>>>> http://blog.sina.com.cn/u/**1473905042<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
>>>>>>> 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.**DelegatingConstructorAccessorI
>>>>>>> **mpl.newInstance(**DelegatingConstructorAccessorI**
>>>>>>> mpl.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
>>>>>>> org.apache.aries.blueprint.**
>>>>>>> container.BeanRecipe.**newInstance(BeanRecipe.java:**962)
>>>>>>> at
>>>>>>> org.apache.aries.blueprint.**
>>>>>>> container.BeanRecipe.**getInstance(BeanRecipe.java:**331)
>>>>>>> ... 24 more
>>>>>>>
>>>>>>> Has anything changed in Karaf 2.3.1 that
>>>>>>> could cause this? My main reason for
>>>>>>> upgrading to Karaf 2.3.1 is the fixes that
>>>>>>> has been done to Aries blueprint - could it
>>>>>>> cause this?
>>>>>>>
>>>>>>> /Bengt
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Bengt Rodehav <be...@rodehav.com>.
Thanks a lot Freeman - my problem is solved!
I had my own version of jre.properties in my custom server (I had forgotten
about that). Thus, the javax.xml.ws packaages had version 0 (Karaf had
that some time back) which caused my problems. When I replaced the
jre.properties with the one bundled with Karaf 2.3.1 things started to work
again.
The reason I had my own jre.properties was that IBM Websphere MQ used
(maybe still uses) classes in the com.sun.jndi.* packages which I therefore
needed to make available.
Again, thanks a lot,
/Bengt
2013/4/3 Freeman Fang <fr...@gmail.com>
> Hi,
>
> My comment inline
>
> －－－－－－－－－－－－－
> 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-3, at 下午2:34, Bengt Rodehav wrote:
>
> Yes, you're right Freeman - I misinterpreted that.
>
> Interestingly enough, the command "exports | grep javax.xml.ws" shows the
> following:
>
> karaf@root> exports | grep javax.xml.ws
> 0 javax.xml.ws; version=0.0.0
> 0 javax.xml.ws.handler; version=0.0.0
> 0 javax.xml.ws.handler.soap; version=0.0.0
> 0 javax.xml.ws.http; version=0.0.0
> 0 javax.xml.ws.soap; version=0.0.0
> 0 javax.xml.ws.spi; version=0.0.0
> 0 javax.xml.ws.wsaddressing; version=0.0.0
>
> I think this indicates that the libraries are taken from the jvm and not
> the endorsed folder - am I right?
>
> Not necessarily
> The system bundle 0 package version specified in etc/jre.properties, check
> your customer server to see what's going on there
>
>
> If I download a fresh Karaf 2.3.1 (not my custom sever) and do the same I
> get:
>
> karaf@root> exports | grep javax.xml.ws
> 0 javax.xml.ws; version=2.2.0
> 0 javax.xml.ws.handler; version=2.2.0
> 0 javax.xml.ws.handler.soap; version=2.2.0
> 0 javax.xml.ws.http; version=2.2.0
> 0 javax.xml.ws.soap; version=2.2.0
> 0 javax.xml.ws.spi; version=2.2.0
> 0 javax.xml.ws.wsaddressing; version=2.2.0
> 0 javax.xml.ws.spi.http; version=2.2.0
>
> This looks correct to me.
>
> So, I must have done something wrong in my custom server since it is not
> picking up the jars in the endorsed folder. Do you have any idea what could
> cause this?
>
>
> /Bengt
>
>
>
>
>
>
>
>
>
> 2013/4/3 Freeman Fang <fr...@gmail.com>
>
>> Hi,
>>
>> Both Karaf 2.3.0 and 2.3.1 endorse jaxws/jaxb 2.2 API, the 2.1.0 suffix
>> is servicemix specs release version, but not the api version, for example,
>> we have
>> org.apache.servicemix.specs.saaj-api-1.3-2.1.0.jar
>> the saaj-api version is 1.3, 2.1.0 is servicemix specs release version.
>>
>> And as we endorsed jaxws/jaxb 2.2 API, so OBR resolver could kick in and
>> prevent jaxws/jaxb bundles to get installed from cxf-spec feature.
>>
>> could you post result of
>> packages:exports |grep javax.xml.ws
>>
>> ?
>>
>> －－－－－－－－－－－－－
>> 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 下午11:04, Bengt Rodehav wrote:
>>
>> 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é <jb...@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 <bengt@rodehav.com <ma...@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 <bengt@rodehav.com <mailto:
>>>>> bengt@rodehav.com>>
>>>>>
>>>>>
>>>>> Thanks, will read the blog.
>>>>>
>>>>>
>>>>> 2013/4/2 Freeman Fang <freeman.fang@gmail.com
>>>>> <mailto:freeman.fang@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.html<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://freemanfang.blogspot.com/>
>>>>> http://blog.sina.com.cn/u/**1473905042<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.fang@gmail.com
>>>>>> <mailto:freeman.fang@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://fusesource.com/> |
>>>>>>
>>>>>> http://www.redhat.com/
>>>>>> Twitter: freemanfang
>>>>>> Blog: http://freemanfang.blogspot.**com<http://freemanfang.blogspot.com/>
>>>>>> <http://freemanfang.blogspot.**com/<http://freemanfang.blogspot.com/>
>>>>>> >
>>>>>>
>>>>>> http://blog.sina.com.cn/u/**1473905042<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/<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 <bengt@rodehav.com
>>>>>>> <ma...@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.fang@gmail.com
>>>>>>> <mailto:freeman.fang@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://fusesource.com/> |
>>>>>>> http://www.redhat.com/
>>>>>>>
>>>>>>> Twitter: freemanfang
>>>>>>> Blog: http://freemanfang.blogspot.**com<http://freemanfang.blogspot.com/>
>>>>>>> <http://freemanfang.blogspot.**com/<http://freemanfang.blogspot.com/>
>>>>>>> >
>>>>>>>
>>>>>>> http://blog.sina.com.cn/u/**1473905042<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
>>>>>>>> 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.**
>>>>>>>> DelegatingConstructorAccessorI**mpl.newInstance(**
>>>>>>>> DelegatingConstructorAccessorI**mpl.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
>>>>>>>> org.apache.aries.blueprint.**
>>>>>>>> container.BeanRecipe.**newInstance(BeanRecipe.java:**962)
>>>>>>>> at
>>>>>>>> org.apache.aries.blueprint.**
>>>>>>>> container.BeanRecipe.**getInstance(BeanRecipe.java:**331)
>>>>>>>> ... 24 more
>>>>>>>>
>>>>>>>> Has anything changed in Karaf 2.3.1 that
>>>>>>>> could cause this? My main reason for
>>>>>>>> upgrading to Karaf 2.3.1 is the fixes that
>>>>>>>> has been done to Aries blueprint - could it
>>>>>>>> cause this?
>>>>>>>>
>>>>>>>> /Bengt
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>>
>>
>>
>
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
My comment inline
－－－－－－－－－－－－－
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-3, at 下午2:34, Bengt Rodehav wrote:
> Yes, you're right Freeman - I misinterpreted that.
>
> Interestingly enough, the command "exports | grep javax.xml.ws" shows the following:
>
> karaf@root> exports | grep javax.xml.ws
> 0 javax.xml.ws; version=0.0.0
> 0 javax.xml.ws.handler; version=0.0.0
> 0 javax.xml.ws.handler.soap; version=0.0.0
> 0 javax.xml.ws.http; version=0.0.0
> 0 javax.xml.ws.soap; version=0.0.0
> 0 javax.xml.ws.spi; version=0.0.0
> 0 javax.xml.ws.wsaddressing; version=0.0.0
>
> I think this indicates that the libraries are taken from the jvm and not the endorsed folder - am I right?
Not necessarily
The system bundle 0 package version specified in etc/jre.properties, check your customer server to see what's going on there
>
> If I download a fresh Karaf 2.3.1 (not my custom sever) and do the same I get:
>
> karaf@root> exports | grep javax.xml.ws
> 0 javax.xml.ws; version=2.2.0
> 0 javax.xml.ws.handler; version=2.2.0
> 0 javax.xml.ws.handler.soap; version=2.2.0
> 0 javax.xml.ws.http; version=2.2.0
> 0 javax.xml.ws.soap; version=2.2.0
> 0 javax.xml.ws.spi; version=2.2.0
> 0 javax.xml.ws.wsaddressing; version=2.2.0
> 0 javax.xml.ws.spi.http; version=2.2.0
>
> This looks correct to me.
>
> So, I must have done something wrong in my custom server since it is not picking up the jars in the endorsed folder. Do you have any idea what could cause this?
>
> /Bengt
>
>
>
>
>
>
>
>
>
> 2013/4/3 Freeman Fang <fr...@gmail.com>
> Hi,
>
> Both Karaf 2.3.0 and 2.3.1 endorse jaxws/jaxb 2.2 API, the 2.1.0 suffix is servicemix specs release version, but not the api version, for example, we have
> org.apache.servicemix.specs.saaj-api-1.3-2.1.0.jar
> the saaj-api version is 1.3, 2.1.0 is servicemix specs release version.
>
> And as we endorsed jaxws/jaxb 2.2 API, so OBR resolver could kick in and prevent jaxws/jaxb bundles to get installed from cxf-spec feature.
>
> could you post result of
> packages:exports |grep javax.xml.ws
>
> ?
>
> －－－－－－－－－－－－－
> 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 下午11:04, Bengt Rodehav wrote:
>
>> 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é <jb...@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 <bengt@rodehav.com <ma...@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 <bengt@rodehav.com <ma...@rodehav.com>>
>>
>>
>> Thanks, will read the blog.
>>
>>
>> 2013/4/2 Freeman Fang <freeman.fang@gmail.com
>> <ma...@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.fang@gmail.com
>> <ma...@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://fusesource.com/> |
>>
>> http://www.redhat.com/
>> Twitter: freemanfang
>> Blog: http://freemanfang.blogspot.com
>> <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 <bengt@rodehav.com
>> <ma...@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.fang@gmail.com
>> <ma...@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://fusesource.com/> | http://www.redhat.com/
>>
>> Twitter: freemanfang
>> Blog: http://freemanfang.blogspot.com
>> <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
>> 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
>> org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)
>> at
>> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)
>> ... 24 more
>>
>> Has anything changed in Karaf 2.3.1 that
>> could cause this? My main reason for
>> upgrading to Karaf 2.3.1 is the fixes that
>> has been done to Aries blueprint - could it
>> cause this?
>>
>> /Bengt
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Bengt Rodehav <be...@rodehav.com>.
Yes, you're right Freeman - I misinterpreted that.
Interestingly enough, the command "exports | grep javax.xml.ws" shows the
following:
karaf@root> exports | grep javax.xml.ws
0 javax.xml.ws; version=0.0.0
0 javax.xml.ws.handler; version=0.0.0
0 javax.xml.ws.handler.soap; version=0.0.0
0 javax.xml.ws.http; version=0.0.0
0 javax.xml.ws.soap; version=0.0.0
0 javax.xml.ws.spi; version=0.0.0
0 javax.xml.ws.wsaddressing; version=0.0.0
I think this indicates that the libraries are taken from the jvm and not
the endorsed folder - am I right?
If I download a fresh Karaf 2.3.1 (not my custom sever) and do the same I
get:
karaf@root> exports | grep javax.xml.ws
0 javax.xml.ws; version=2.2.0
0 javax.xml.ws.handler; version=2.2.0
0 javax.xml.ws.handler.soap; version=2.2.0
0 javax.xml.ws.http; version=2.2.0
0 javax.xml.ws.soap; version=2.2.0
0 javax.xml.ws.spi; version=2.2.0
0 javax.xml.ws.wsaddressing; version=2.2.0
0 javax.xml.ws.spi.http; version=2.2.0
This looks correct to me.
So, I must have done something wrong in my custom server since it is not
picking up the jars in the endorsed folder. Do you have any idea what could
cause this?
/Bengt
2013/4/3 Freeman Fang <fr...@gmail.com>
> Hi,
>
> Both Karaf 2.3.0 and 2.3.1 endorse jaxws/jaxb 2.2 API, the 2.1.0 suffix is
> servicemix specs release version, but not the api version, for example, we
> have
> org.apache.servicemix.specs.saaj-api-1.3-2.1.0.jar
> the saaj-api version is 1.3, 2.1.0 is servicemix specs release version.
>
> And as we endorsed jaxws/jaxb 2.2 API, so OBR resolver could kick in and
> prevent jaxws/jaxb bundles to get installed from cxf-spec feature.
>
> could you post result of
> packages:exports |grep javax.xml.ws
>
> ?
>
> －－－－－－－－－－－－－
> 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 下午11:04, Bengt Rodehav wrote:
>
> 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é <jb...@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 <bengt@rodehav.com <ma...@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 <bengt@rodehav.com <mailto:bengt@rodehav.com
>>>> >>
>>>>
>>>>
>>>> Thanks, will read the blog.
>>>>
>>>>
>>>> 2013/4/2 Freeman Fang <freeman.fang@gmail.com
>>>> <mailto:freeman.fang@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.html<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://freemanfang.blogspot.com/>
>>>> http://blog.sina.com.cn/u/**1473905042<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.fang@gmail.com
>>>>> <mailto:freeman.fang@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://fusesource.com/> |
>>>>>
>>>>> http://www.redhat.com/
>>>>> Twitter: freemanfang
>>>>> Blog: http://freemanfang.blogspot.**com<http://freemanfang.blogspot.com/>
>>>>> <http://freemanfang.blogspot.**com/<http://freemanfang.blogspot.com/>
>>>>> >
>>>>>
>>>>> http://blog.sina.com.cn/u/**1473905042<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/<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 <bengt@rodehav.com
>>>>>> <ma...@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.fang@gmail.com
>>>>>> <mailto:freeman.fang@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://fusesource.com/> |
>>>>>> http://www.redhat.com/
>>>>>>
>>>>>> Twitter: freemanfang
>>>>>> Blog: http://freemanfang.blogspot.**com<http://freemanfang.blogspot.com/>
>>>>>> <http://freemanfang.blogspot.**com/<http://freemanfang.blogspot.com/>
>>>>>> >
>>>>>>
>>>>>> http://blog.sina.com.cn/u/**1473905042<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
>>>>>>> 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.**DelegatingConstructorAccessorI
>>>>>>> **mpl.newInstance(**DelegatingConstructorAccessorI**
>>>>>>> mpl.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
>>>>>>> org.apache.aries.blueprint.**
>>>>>>> container.BeanRecipe.**newInstance(BeanRecipe.java:**962)
>>>>>>> at
>>>>>>> org.apache.aries.blueprint.**
>>>>>>> container.BeanRecipe.**getInstance(BeanRecipe.java:**331)
>>>>>>> ... 24 more
>>>>>>>
>>>>>>> Has anything changed in Karaf 2.3.1 that
>>>>>>> could cause this? My main reason for
>>>>>>> upgrading to Karaf 2.3.1 is the fixes that
>>>>>>> has been done to Aries blueprint - could it
>>>>>>> cause this?
>>>>>>>
>>>>>>> /Bengt
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
Both Karaf 2.3.0 and 2.3.1 endorse jaxws/jaxb 2.2 API, the 2.1.0 suffix is servicemix specs release version, but not the api version, for example, we have
org.apache.servicemix.specs.saaj-api-1.3-2.1.0.jar
the saaj-api version is 1.3, 2.1.0 is servicemix specs release version.
And as we endorsed jaxws/jaxb 2.2 API, so OBR resolver could kick in and prevent jaxws/jaxb bundles to get installed from cxf-spec feature.
could you post result of
packages:exports |grep javax.xml.ws
?
－－－－－－－－－－－－－
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 下午11:04, Bengt Rodehav wrote:
> 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é <jb...@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 <bengt@rodehav.com <ma...@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 <bengt@rodehav.com <ma...@rodehav.com>>
>
>
> Thanks, will read the blog.
>
>
> 2013/4/2 Freeman Fang <freeman.fang@gmail.com
> <ma...@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.fang@gmail.com
> <ma...@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://fusesource.com/> |
>
> http://www.redhat.com/
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
> <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 <bengt@rodehav.com
> <ma...@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.fang@gmail.com
> <ma...@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://fusesource.com/> | http://www.redhat.com/
>
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
> <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
> 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
> org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)
> at
> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)
> ... 24 more
>
> Has anything changed in Karaf 2.3.1 that
> could cause this? My main reason for
> upgrading to Karaf 2.3.1 is the fixes that
> has been done to Aries blueprint - could it
> cause this?
>
> /Bengt
>
>
>
>
>
>
>
>
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by 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é <jb...@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 <bengt@rodehav.com <ma...@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 <bengt@rodehav.com <mailto:bengt@rodehav.com
>>> >>
>>>
>>>
>>> Thanks, will read the blog.
>>>
>>>
>>> 2013/4/2 Freeman Fang <freeman.fang@gmail.com
>>> <mailto:freeman.fang@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.html<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://freemanfang.blogspot.com>
>>> http://blog.sina.com.cn/u/**1473905042<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.fang@gmail.com
>>>> <mailto:freeman.fang@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://fusesource.com/> |
>>>>
>>>> http://www.redhat.com/
>>>> Twitter: freemanfang
>>>> Blog: http://freemanfang.blogspot.**com<http://freemanfang.blogspot.com>
>>>> <http://freemanfang.blogspot.**com/<http://freemanfang.blogspot.com/>
>>>> >
>>>>
>>>> http://blog.sina.com.cn/u/**1473905042<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/<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 <bengt@rodehav.com
>>>>> <ma...@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.fang@gmail.com
>>>>> <mailto:freeman.fang@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://fusesource.com/> |
>>>>> http://www.redhat.com/
>>>>>
>>>>> Twitter: freemanfang
>>>>> Blog: http://freemanfang.blogspot.**com<http://freemanfang.blogspot.com>
>>>>> <http://freemanfang.blogspot.**com/<http://freemanfang.blogspot.com/>
>>>>> >
>>>>>
>>>>> http://blog.sina.com.cn/u/**1473905042<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
>>>>>> 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.**DelegatingConstructorAccessorI*
>>>>>> *mpl.newInstance(**DelegatingConstructorAccessorI**
>>>>>> mpl.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
>>>>>> org.apache.aries.blueprint.**
>>>>>> container.BeanRecipe.**newInstance(BeanRecipe.java:**962)
>>>>>> at
>>>>>> org.apache.aries.blueprint.**
>>>>>> container.BeanRecipe.**getInstance(BeanRecipe.java:**331)
>>>>>> ... 24 more
>>>>>>
>>>>>> Has anything changed in Karaf 2.3.1 that
>>>>>> could cause this? My main reason for
>>>>>> upgrading to Karaf 2.3.1 is the fixes that
>>>>>> has been done to Aries blueprint - could it
>>>>>> cause this?
>>>>>>
>>>>>> /Bengt
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by 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é <jb...@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 <bengt@rodehav.com <ma...@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 <bengt@rodehav.com <ma...@rodehav.com>>
>>
>>
>> Thanks, will read the blog.
>>
>>
>> 2013/4/2 Freeman Fang <freeman.fang@gmail.com
>> <mailto:freeman.fang@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.html<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://freemanfang.blogspot.com>
>> http://blog.sina.com.cn/u/**1473905042<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.fang@gmail.com
>>> <mailto:freeman.fang@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://fusesource.com/> |
>>>
>>> http://www.redhat.com/
>>> Twitter: freemanfang
>>> Blog: http://freemanfang.blogspot.**com<http://freemanfang.blogspot.com>
>>> <http://freemanfang.blogspot.**com/<http://freemanfang.blogspot.com/>
>>> >
>>>
>>> http://blog.sina.com.cn/u/**1473905042<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/<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 <bengt@rodehav.com
>>>> <ma...@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.fang@gmail.com
>>>> <mailto:freeman.fang@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://fusesource.com/> |
>>>> http://www.redhat.com/
>>>>
>>>> Twitter: freemanfang
>>>> Blog: http://freemanfang.blogspot.**com<http://freemanfang.blogspot.com>
>>>> <http://freemanfang.blogspot.**com/<http://freemanfang.blogspot.com/>
>>>> >
>>>>
>>>> http://blog.sina.com.cn/u/**1473905042<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
>>>>> 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.**DelegatingConstructorAccessorI**
>>>>> mpl.newInstance(**DelegatingConstructorAccessorI**
>>>>> mpl.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
>>>>> org.apache.aries.blueprint.**
>>>>> container.BeanRecipe.**newInstance(BeanRecipe.java:**962)
>>>>> at
>>>>> org.apache.aries.blueprint.**
>>>>> container.BeanRecipe.**getInstance(BeanRecipe.java:**331)
>>>>> ... 24 more
>>>>>
>>>>> Has anything changed in Karaf 2.3.1 that
>>>>> could cause this? My main reason for
>>>>> upgrading to Karaf 2.3.1 is the fixes that
>>>>> has been done to Aries blueprint - could it
>>>>> cause this?
>>>>>
>>>>> /Bengt
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Jean-Baptiste Onofré <jb...@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 <bengt@rodehav.com <ma...@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 <bengt@rodehav.com <ma...@rodehav.com>>
>
> Thanks, will read the blog.
>
>
> 2013/4/2 Freeman Fang <freeman.fang@gmail.com
> <ma...@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.fang@gmail.com
>> <ma...@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://fusesource.com/> |
>> http://www.redhat.com/
>> Twitter: freemanfang
>> Blog: http://freemanfang.blogspot.com
>> <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 <bengt@rodehav.com
>>> <ma...@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.fang@gmail.com
>>> <ma...@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://fusesource.com/> | http://www.redhat.com/
>>> Twitter: freemanfang
>>> Blog: http://freemanfang.blogspot.com
>>> <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
>>>> 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
>>>> org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)
>>>> at
>>>> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)
>>>> ... 24 more
>>>>
>>>> Has anything changed in Karaf 2.3.1 that
>>>> could cause this? My main reason for
>>>> upgrading to Karaf 2.3.1 is the fixes that
>>>> has been done to Aries blueprint - could it
>>>> cause this?
>>>>
>>>> /Bengt
>>>
>>>
>>>
>>
>>
>
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Bengt Rodehav <be...@rodehav.com>.
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>
> 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 <fr...@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 <fr...@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 <fr...@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 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
>>>>>> org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)
>>>>>> at
>>>>>> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)
>>>>>> ... 24 more
>>>>>>
>>>>>> Has anything changed in Karaf 2.3.1 that could cause this? My main
>>>>>> reason for upgrading to Karaf 2.3.1 is the fixes that has been done to
>>>>>> Aries blueprint - could it cause this?
>>>>>>
>>>>>> /Bengt
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I suspect more something around Aries Blueprint: in order to fix a
couple of issues on Blueprint, we upgraded to a new version of Aries
Blueprint.
I gonna take a look.
Regards
JB
On 04/02/2013 01:17 PM, Bengt Rodehav wrote:
> 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 <bengt@rodehav.com <ma...@rodehav.com>>
>
> Thanks, will read the blog.
>
>
> 2013/4/2 Freeman Fang <freeman.fang@gmail.com
> <ma...@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.fang@gmail.com
>> <ma...@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://fusesource.com/> |
>> http://www.redhat.com/
>> Twitter: freemanfang
>> Blog: http://freemanfang.blogspot.com
>> <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 <bengt@rodehav.com
>>> <ma...@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.fang@gmail.com
>>> <ma...@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://fusesource.com/> | http://www.redhat.com/
>>> Twitter: freemanfang
>>> Blog: http://freemanfang.blogspot.com
>>> <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
>>>> 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
>>>> org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)
>>>> at
>>>> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)
>>>> ... 24 more
>>>>
>>>> Has anything changed in Karaf 2.3.1 that could
>>>> cause this? My main reason for upgrading to
>>>> Karaf 2.3.1 is the fixes that has been done to
>>>> Aries blueprint - could it cause this?
>>>>
>>>> /Bengt
>>>
>>>
>>>
>>
>>
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Bengt Rodehav <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>
> Thanks, will read the blog.
>
>
> 2013/4/2 Freeman Fang <fr...@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 <fr...@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 <fr...@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 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
>>>>> org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)
>>>>> at
>>>>> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)
>>>>> ... 24 more
>>>>>
>>>>> Has anything changed in Karaf 2.3.1 that could cause this? My main
>>>>> reason for upgrading to Karaf 2.3.1 is the fixes that has been done to
>>>>> Aries blueprint - could it cause this?
>>>>>
>>>>> /Bengt
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Bengt Rodehav <be...@rodehav.com>.
Thanks, will read the blog.
2013/4/2 Freeman Fang <fr...@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 <fr...@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 <fr...@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 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
>>>> org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)
>>>> at
>>>> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)
>>>> ... 24 more
>>>>
>>>> Has anything changed in Karaf 2.3.1 that could cause this? My main
>>>> reason for upgrading to Karaf 2.3.1 is the fixes that has been done to
>>>> Aries blueprint - could it cause this?
>>>>
>>>> /Bengt
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Freeman Fang <fr...@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 <fr...@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 <fr...@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 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 org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)
>>> at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)
>>> ... 24 more
>>>
>>> Has anything changed in Karaf 2.3.1 that could cause this? My main reason for upgrading to Karaf 2.3.1 is the fixes that has been done to Aries blueprint - could it cause this?
>>>
>>> /Bengt
>>
>>
>>
>
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <fr...@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 <fr...@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 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
>>> org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)
>>> at
>>> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)
>>> ... 24 more
>>>
>>> Has anything changed in Karaf 2.3.1 that could cause this? My main
>>> reason for upgrading to Karaf 2.3.1 is the fixes that has been done to
>>> Aries blueprint - could it cause this?
>>>
>>> /Bengt
>>>
>>>
>>>
>>
>
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Freeman Fang <fr...@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 <fr...@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 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 org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)
>> at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)
>> ... 24 more
>>
>> Has anything changed in Karaf 2.3.1 that could cause this? My main reason for upgrading to Karaf 2.3.1 is the fixes that has been done to Aries blueprint - could it cause this?
>>
>> /Bengt
>
>
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <fr...@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 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
>> org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)
>> at
>> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)
>> ... 24 more
>>
>> Has anything changed in Karaf 2.3.1 that could cause this? My main reason
>> for upgrading to Karaf 2.3.1 is the fixes that has been done to Aries
>> blueprint - could it cause this?
>>
>> /Bengt
>>
>>
>>
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by 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 <fr...@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 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
> org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)
> at
> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)
> ... 24 more
>
> Has anything changed in Karaf 2.3.1 that could cause this? My main reason
> for upgrading to Karaf 2.3.1 is the fixes that has been done to Aries
> blueprint - could it cause this?
>
> /Bengt
>
>
>
Re: Problems with Karaf 2.3.1 and Cxf
Posted by Freeman Fang <fr...@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 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 org.apache.aries.blueprint.container.BeanRecipe.newInstance(BeanRecipe.java:962)
> at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:331)
> ... 24 more
>
> Has anything changed in Karaf 2.3.1 that could cause this? My main reason for upgrading to Karaf 2.3.1 is the fixes that has been done to Aries blueprint - could it cause this?
>
> /Bengt