I suspect more something around Aries Blueprint: in order to fix a
couple of issues on Blueprint, we upgraded to a new version of Aries
Blueprint.
I gonna take a look.
Regards
JB
On 04/02/2013 01:17 PM, Bengt Rodehav wrote:
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/
[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
<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://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
<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://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
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
