Just checked the feature descriptor for Cxf 2.7.3. It still includes the 2.2 api's. I wonder if anyone has gotten this to work on Karaf 2.3.1 and, if so, how they did it.
/Bengt 2013/4/2 Bengt Rodehav <be...@rodehav.com> > Another observation. > > In Cxf 2.6.3 feature descriptor, the feature cxf-specs include, among > others, 2.2 versions of jaxb-api and jaxws-api. Since the corresponding > api's are only on 2.1 level in Karaf 2.3.0 lib\endorsed, the bundles are > used instead. But, Karaf 2.3.1 has updated the endorsed libraries to > version 2.2 which means that they are now used by Cxf instead of the > bundles listed in the cxf-spec feature. > > In other words, the Cxf feature descriptor must (or should) be changed in > order to work under Karaf 2.3.1. Perhaps this has been done in later > versions of Cxf - I haven't checked. > > Even if I fix this I'm still not done since I don't know how to get the > endorsed versions to work with Cxf. Hopefully someone knows how to get that > to work. > > /Bengt > > > 2013/4/2 Bengt Rodehav <be...@rodehav.com> > >> No, I did not update the Cxf version. I use Cxf 2.6.3 in both cases. >> >> I wonder why the cxf-api bundle imports the org.apache.cxf.jaxws.spi >> package. Maybe it's been done by "accident" but it still is what makes it >> work under Karaf 2.3.0... >> >> I'm currently looking at the source code for the FactoryFinder class that >> does the actual loading of the factory class. It does seem like it uses the >> TCCL. Do you know if I'm supposed to set the TCCL manually? What is the >> actual usage pattern here? >> >> /Bengt >> >> >> 2013/4/2 Jean-Baptiste Onofré <j...@nanthrax.net> >> >>> Hi Bengt, >>> >>> it can but it doesn't come from Karaf. I guess that you updated the CXF >>> version as well ? >>> >>> Regards >>> JB >>> >>> >>> On 04/02/2013 02:01 PM, Bengt Rodehav wrote: >>> >>>> I compared Karaf 2.3.0 with 2.3.1 and noticed that (with my >>>> configuration) in Karaf 2.3.0, the org.apache.cxf.cxf-api bundle imports >>>> the org.apache.cxf.jaxws.spi package from the cxf-rt-frontend bundle. >>>> This does not happen in Karaf 2.3.1. Could this cause the problem? >>>> >>>> /Bengt >>>> >>>> >>>> >>>> >>>> 2013/4/2 Bengt Rodehav <be...@rodehav.com <mailto:be...@rodehav.com>> >>>> >>>> >>>> I read the blog but it didn't go into details regarding how the >>>> implementation classes are found - I guess I'll have to look in the >>>> code. >>>> >>>> One observation regarding my problem: What gives me an exception is >>>> when blueprint attempts to instantiate my class. In my class >>>> constructor I try to create the web service proxy. I did try to >>>> import the org.apache.cxf.jaxws.spi package to the bundle that >>>> contains the class that cannot be instantiated. I can see in runtime >>>> that the bundle does indeed import the org.apache.cxf.jaxws.spi >>>> package from the cxf-rt-frontend bundle. But I still get the >>>> exception indicating that it cannot find the >>>> org.apache.cxf.jaxws.spi.**ProviderImpl class. >>>> >>>> Thus, putting the ProviderImpl class in my bundle's classpath >>>> doesn't help. It seems like it has to be in the system bundle's >>>> classpath. I really don't know how that mechanism is supposed to >>>> work - but it did work in Karaf 2.3.0. Does the new blueprint >>>> version do some classloading magic? >>>> >>>> /Bengt >>>> >>>> >>>> 2013/4/2 Bengt Rodehav <be...@rodehav.com <mailto:be...@rodehav.com >>>> >> >>>> >>>> >>>> Thanks, will read the blog. >>>> >>>> >>>> 2013/4/2 Freeman Fang <freeman.f...@gmail.com >>>> <mailto:freeman.f...@gmail.com**>> >>>> >>>> >>>> Hi, >>>> Good question, yeah, the traditional JAVA SPI mechanism >>>> generally doesn't work in OSGi container. >>>> So Servicemix Specs project[1] use "OSGi locator" to resolve >>>> this problem, Guillaume has a blog about it years ago[2] >>>> >>>> [1]https://svn.apache.org/**repos/asf/servicemix/smx4/** >>>> specs/trunk/<https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/> >>>> [2]http://gnodet.blogspot.com/** >>>> 2008/05/jee-specs-in-osgi.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 >>> >> >> >
