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