I read the blog but it didn't go into details regarding how the implementation classes are found - I guess I'll have to look in the code.
One observation regarding my problem: What gives me an exception is when blueprint attempts to instantiate my class. In my class constructor I try to create the web service proxy. I did try to import the org.apache.cxf.jaxws.spi package to the bundle that contains the class that cannot be instantiated. I can see in runtime that the bundle does indeed import the org.apache.cxf.jaxws.spi package from the cxf-rt-frontend bundle. But I still get the exception indicating that it cannot find the org.apache.cxf.jaxws.spi.ProviderImpl class. Thus, putting the ProviderImpl class in my bundle's classpath doesn't help. It seems like it has to be in the system bundle's classpath. I really don't know how that mechanism is supposed to work - but it did work in Karaf 2.3.0. Does the new blueprint version do some classloading magic? /Bengt 2013/4/2 Bengt Rodehav <be...@rodehav.com> > Thanks, will read the blog. > > > 2013/4/2 Freeman Fang <freeman.f...@gmail.com> > >> Hi, >> Good question, yeah, the traditional JAVA SPI mechanism generally doesn't >> work in OSGi container. >> So Servicemix Specs project[1] use "OSGi locator" to resolve this >> problem, Guillaume has a blog about it years ago[2] >> >> [1]https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/ >> [2]http://gnodet.blogspot.com/2008/05/jee-specs-in-osgi.html >> >> －－－－－－－－－－－－－ >> Freeman(Yue) Fang >> >> Red Hat, Inc. >> FuseSource is now part of Red Hat >> Web: http://fusesource.com | http://www.redhat.com/ >> Twitter: freemanfang >> Blog: http://freemanfang.blogspot.com >> http://blog.sina.com.cn/u/1473905042 >> weibo: @Freeman小屋 >> >> On 2013-4-2, at 下午5:07, Bengt Rodehav wrote: >> >> I'll see if I can get a test case done for this although it might take a >> while. Meanwhile, can you explain what mechanism is used for resolving the >> implementation classes. I mean, how is the system bundle supposed to >> resolve a class that resides in another bundle? (In this case the >> cxf-rt-frontend). >> >> /Bengt >> >> >> 2013/4/2 Freeman Fang <freeman.f...@gmail.com> >> >>> Hi, >>> >>> No, that blog is a little bit out of data and not applicable for Karaf >>> 2.3.x anymore. >>> >>> With Karaf 2.3.x we endorse specs(like jaxws/jaxb) jars, so we need >>> export those packages from system bundle 0, so don't comment it out >>> >>> and those endorsed specs jars can load jaxws impl bundle(cxf jaxws >>> frontend bundle in this case) during runtime OOTB. >>> >>> No concrete idea why it doesn't work for you(also I don't think there's >>> any real difference between karaf 2.3 and karaf 2.3.1 in terms of jaxws >>> loading mechanism), that's why I ask a test case, it's definitely very >>> helpful to resolve the issue faster. >>> >>> >>> －－－－－－－－－－－－－ >>> Freeman(Yue) Fang >>> >>> Red Hat, Inc. >>> FuseSource is now part of Red Hat >>> Web: http://fusesource.com | http://www.redhat.com/ >>> Twitter: freemanfang >>> Blog: http://freemanfang.blogspot.com >>> http://blog.sina.com.cn/u/1473905042 >>> weibo: @Freeman小屋 >>> >>> On 2013-4-2, at 下午4:38, Bengt Rodehav wrote: >>> >>> I found this blog post by Dan Kulp: >>> http://www.dankulp.com/blog/2011/11/apache-cxf-in-osgi/ >>> >>> I modified the jre.properties accordingly but I still get the exact same >>> stack trace. >>> >>> /Bengt >>> >>> >>> 2013/4/2 Bengt Rodehav <be...@rodehav.com> >>> >>>> Hello Freeman, >>>> >>>> It would be a lot of work for me to narrow down my application to a >>>> simple test case. I'd really like to try other possibilities first, like: >>>> >>>> - Understanding how the factory pattern is supposed to work, espcially >>>> for Cxf >>>> - What has been changed in Karaf 2.3.1. that could affect this >>>> >>>> /Bengt >>>> >>>> >>>> 2013/4/2 Freeman Fang <freeman.f...@gmail.com> >>>> >>>>> Hi, >>>>> >>>>> No concrete idea now, could you please append a test case which we can >>>>> build and reproduce it? >>>>> Thanks >>>>> －－－－－－－－－－－－－ >>>>> Freeman(Yue) Fang >>>>> >>>>> Red Hat, Inc. >>>>> FuseSource is now part of Red Hat >>>>> Web: http://fusesource.com | http://www.redhat.com/ >>>>> Twitter: freemanfang >>>>> Blog: http://freemanfang.blogspot.com >>>>> http://blog.sina.com.cn/u/1473905042 >>>>> weibo: @Freeman小屋 >>>>> >>>>> On 2013-4-2, at 下午3:30, Bengt Rodehav wrote: >>>>> >>>>> I've been using Karaf 2.3.0 for a while. I now tried to upgrade to >>>>> Karaf 2.3.1 but ran into problems with CXF. >>>>> >>>>> I use cxf-codegen-plugin to generate code from a WSDL file so that I >>>>> can call the web service via a proxy. However, after upgrading to Karaf >>>>> 2.3.1 I get the following exception: >>>>> >>>>> 2013-04-02 09:19:03,317 | ERROR | rint Extender: 3 | >>>>> BlueprintContainerImpl | container.BlueprintContainerImpl 393 | >>>>> Unable to start blueprint container for bundle >>>>> se.digia.connect.services.iso20022.iws-client >>>>> org.osgi.service.blueprint.container.ComponentDefinitionException: >>>>> Error when instantiating bean iwsService of class class >>>>> se.digia.connect.iso20022.iwsclient.Client >>>>> at >>>>> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[7:org.apache.aries.blueprint.core:1.1.0] >>>>> at >>>>> 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 >>>>> >>>>> >>>>> >>>> >>> >>> >> >> >
