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 <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 >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> >
