Hi all,
I have solved the problem. Like we discussed the problem was that the
following packages (javax.activation, javax.jws, javax.jws.soap,
javax.xml.bind.annotation) were exported by the system bundle and by the
sepc bundles.
I found the article
http://blog.springsource.com/2009/01/19/exposing-the-boot-classpath-in-osgi/
. The solution A' worked for me. I defined a fragment bundle for the
system bundle and was able to redefine the exports for the packages
above to the correct versions. After this change my example worked nicely.
Below you can find the Manifest of the fragment. I will write a blog
entry how to setup cxf for eclipse rcp to document what I did.
Could you give me some feedback if this solution is the way to go or if
you would suggest rather solving this in another way? One problem I
found is that I was only able to additionally define the exports so the
system bundle still also exports the version 0.0.0 for these packages.
Another thing is that it only worked because the versions in the jre
were the ones needed by cxf if other versions are needed at some point
in time I will need another solution. I guess the best way would be to
configure the system bundle to not export these packages at all but I
found no working way to do this.
I also just checked the servicemix config. There these packages are not
exported by the system bundle. So this is probably the reason why it
works in servicemix.
Greetings
Christian
----
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Activationfrag Fragment
Bundle-SymbolicName: activationfrag
Bundle-Version: 1.0.0
Fragment-Host: org.eclipse.osgi;bundle-version="3.6.0"
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Export-Package: javax.activation;version="1.1.0",
javax.jws;version="2.0.0",
javax.jws.soap;version="2.0.0",
javax.xml.bind.annotation;version="2.1.0"
Am 27.08.2010 00:55, schrieb Christian Schneider:
Hi Willem,
I am currently trying to recreate the problem at home where I am more
flexible in using stuf from the internet.
I have created a small bundle that should act as a client for the
customerservice from wsdl first example. When doing the service call I
get the following problem:
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'tester' defined in URL
[bundleentry://59.fwk23376028/META-INF/spring/bundle-context.xml]:
Invocation of init method failed; nested exception is
java.lang.LinkageError: loader constraint violation: when resolving
overridden method
"org.apache.cxf.jaxb.attachment.JAXBAttachmentMarshaller.addSwaRefAttachment(Ljavax/activation/DataHandler;)Ljava/lang/String;"
the class loader (instance of
org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the
current class,
org/apache/cxf/jaxb/attachment/JAXBAttachmentMarshaller, and its
superclass loader (instance of <bootloader>), have different Class
objects for the type javax/activation/DataHandler used in the signature
So I think the problem is that the system bundle offers
javax.activation in version 0.0.0 and
org.apache.geronimo.specs.geronimo-activation_1.1_spec offers it as
version "1.1.0".
I guess at work I am seeing something similar with the jaxb api. I
just checked the system bundle in servicemix but it also seems to
export the package.
Greetings
Christian
-----
The manifest looks like this:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Customerserviceclient
Bundle-SymbolicName: customerserviceclient
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: customerserviceclient.Activator
Bundle-ActivationPolicy: lazy
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Import-Package: org.osgi.framework;version="1.3.0"
Require-Bundle: org.apache.cxf.bundle-minimal;bundle-version="2.2.10",
org.springframework.beans;bundle-version="2.5.6",
com.springsource.org.junit;bundle-version="4.8.1"
Am 26.08.2010 14:41, schrieb Willem Jiang:
Schneider Christian wrote:
Hi Willem,
I have not yet used servicemix (at least the 4.x version). I will
try with servicemix but my target environment will be eclipse rcp.
My colleagues want to call services from a rich client. So I guess
even if it works with servicemix it is not a suitable environment.
What do you mean by bundle header? The manifest?
Yeah, it's the manifest file which has the import and export packages.
BTW, in ServiceMix you can get control of which JVM system package
will be export into osgi platform, I guess you can do the same thing
in the eclipse rcp to export the right version of JAXB.
Willem
Greetings
Christian
Christian Schneider
Informationsverarbeitung Business Solutions
Handel und Dispatching
Tel : +49-(0)721-63-15482
EnBW Systeme Infrastruktur Support GmbH
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim HRB 108550
Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
Geschäftsführer: Jochen Adenau, Hans-Günther Meier
-----Ursprüngliche Nachricht-----
Von: Willem Jiang [mailto:[email protected]] Gesendet:
Mittwoch, 25. August 2010 15:58
An: [email protected]
Betreff: Re: AW: Problem with service call in osgi: Unmarshalling
Error: unexpected element (uri:"", local:"customers"). Expected
elements are (none)
Hi Christian,
Did you try to deploy your bundle into ServicemMix?
Can I have a look at your application bundle header?
Willem
Schneider Christian wrote:
I have set the start levels so that the spec packages are loaded
first. The console messages below show that the javax.xml.bind.*
packages are resolved to the same package in jaxb impl and cxf. I
still get the same error though. Could it be that cxf can not load
or instantiate my stub classes. I must confess I do not really
understand how cxf can access / create these classes at all. Do I
have to enable something like buiddy classloading or should this
simply work?
I have done an interesting experiment. I added the
cxf-bundle-minimal jar to the project in a lib dir, adjusted the
require bundles and the call worked. So I suspect that the problem
could be that cxf can not access my stub classes. Could I be right?
Any ideas how to fix that with normal bundles?
Greetings
Christian
--
----
http://www.liquid-reality.de
