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 <[email protected] <mailto:[email protected]>>
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 <[email protected] <mailto:[email protected]>>
Thanks, will read the blog.
2013/4/2 Freeman Fang <[email protected]
<mailto:[email protected]>>
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 <[email protected]
<mailto:[email protected]>>
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 <[email protected]
<mailto:[email protected]>>
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 <[email protected]
<mailto:[email protected]>>
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é
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
