No, I did not update the Cxf version. I use Cxf 2.6.3 in both cases. I wonder why the cxf-api bundle imports the org.apache.cxf.jaxws.spi package. Maybe it's been done by "accident" but it still is what makes it work under Karaf 2.3.0...
I'm currently looking at the source code for the FactoryFinder class that does the actual loading of the factory class. It does seem like it uses the TCCL. Do you know if I'm supposed to set the TCCL manually? What is the actual usage pattern here? /Bengt 2013/4/2 Jean-Baptiste Onofré <j...@nanthrax.net> > Hi Bengt, > > it can but it doesn't come from Karaf. I guess that you updated the CXF > version as well ? > > Regards > JB > > > On 04/02/2013 02:01 PM, Bengt Rodehav wrote: > >> I compared Karaf 2.3.0 with 2.3.1 and noticed that (with my >> configuration) in Karaf 2.3.0, the org.apache.cxf.cxf-api bundle imports >> the org.apache.cxf.jaxws.spi package from the cxf-rt-frontend bundle. >> This does not happen in Karaf 2.3.1. Could this cause the problem? >> >> /Bengt >> >> >> >> >> 2013/4/2 Bengt Rodehav <be...@rodehav.com <mailto:be...@rodehav.com>> >> >> >> I read the blog but it didn't go into details regarding how the >> implementation classes are found - I guess I'll have to look in the >> code. >> >> One observation regarding my problem: What gives me an exception is >> when blueprint attempts to instantiate my class. In my class >> constructor I try to create the web service proxy. I did try to >> import the org.apache.cxf.jaxws.spi package to the bundle that >> contains the class that cannot be instantiated. I can see in runtime >> that the bundle does indeed import the org.apache.cxf.jaxws.spi >> package from the cxf-rt-frontend bundle. But I still get the >> exception indicating that it cannot find the >> org.apache.cxf.jaxws.spi.**ProviderImpl class. >> >> Thus, putting the ProviderImpl class in my bundle's classpath >> doesn't help. It seems like it has to be in the system bundle's >> classpath. I really don't know how that mechanism is supposed to >> work - but it did work in Karaf 2.3.0. Does the new blueprint >> version do some classloading magic? >> >> /Bengt >> >> >> 2013/4/2 Bengt Rodehav <be...@rodehav.com <mailto:be...@rodehav.com>> >> >> >> Thanks, will read the blog. >> >> >> 2013/4/2 Freeman Fang <freeman.f...@gmail.com >> <mailto:freeman.f...@gmail.com**>> >> >> >> Hi, >> Good question, yeah, the traditional JAVA SPI mechanism >> generally doesn't work in OSGi container. >> So Servicemix Specs project[1] use "OSGi locator" to resolve >> this problem, Guillaume has a blog about it years ago[2] >> >> [1]https://svn.apache.org/**repos/asf/servicemix/smx4/** >> specs/trunk/<https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/> >> [2]http://gnodet.blogspot.com/** >> 2008/05/jee-specs-in-osgi.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.f...@gmail.com >>> <mailto:freeman.f...@gmail.com**>> >>> >>> >>> Hi, >>> >>> No, that blog is a little bit out of data and not >>> applicable for Karaf 2.3.x anymore. >>> >>> With Karaf 2.3.x we endorse specs(like jaxws/jaxb) >>> jars, so we need export those 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 <be...@rodehav.com >>>> <mailto:be...@rodehav.com>> >>>> >>>> >>>> Hello Freeman, >>>> >>>> It would be a lot of work for me to narrow down >>>> my application to a simple test case. I'd really >>>> like to try other possibilities first, like: >>>> >>>> - Understanding how the factory pattern is >>>> supposed to work, espcially for Cxf >>>> - What has been changed in Karaf 2.3.1. that >>>> could affect this >>>> >>>> /Bengt >>>> >>>> >>>> 2013/4/2 Freeman Fang <freeman.f...@gmail.com >>>> <mailto:freeman.f...@gmail.com**>> >>>> >>>> >>>> Hi, >>>> >>>> No concrete idea now, could you please append >>>> a test case which we can build and reproduce it? >>>> Thanks >>>> －－－－－－－－－－－－－ >>>> Freeman(Yue) Fang >>>> >>>> Red Hat, Inc. >>>> FuseSource is now part of Red Hat >>>> Web: http://fusesource.com >>>> <http://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é > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
