I really think that we should focus on the proxy, not on Aegis versus JAXB. Who is constructing the proxy on the server side, and why does it reject this function?
On Thu, Sep 10, 2009 at 9:07 AM, <[email protected]> wrote: > I uploaded the code with the JAXB modifications to <http://ul.to/p6h744>. > > > Sergey Beryozkin wrote: > >> Ok... Can you try to use JAXB ? in 1.1-SNAPSHOT, you can provide a > >> property : > >> > >> 'org.apache.cxf.ws.databinding' with the value 'jaxb'. Add > >> '@XmlRootElement' > >> to MathHelperImpl, and you'll probably also need to import the > >> javax.xml.bind.annotation.* to client/server bundles. > >> If it will work then it will confirm it's an Aegis issue, if not then it > >> will point to some other DOSGi issue. > > > > Thanks for your help! > > > > I tried this. I added @XmlRootElement on MathHelperImpl (and later also > on > > PassObjectImpl) and imported packages javax.xml.bind.annotation and > > javax.xml.bind.annotation.adapters in both client and server bundles. > > > > Unfortunately the server now throws an exception (see attachement) when > > method passAnObject is called by the client. Thus it doesn't even get as > > far as before. > > > > Is it correct to set the databinding-property on the (PassObject) service > > when registering? If so, how does the client know about the server using > > JAXB? > > > > > > Greetings, > > Saul > > > > > > Attached is the stacktrace for the exception thrown by the server: > > > > org.apache.cxf.interceptor.Fault: Unmarshalling Error: unexpected element > > (uri:"http://interfaces.passobject/";, local:"arg0"). Expected elements > are > > (none) > > at > > > org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:625) > > > >
