You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by o5...@sneakemail.com on 2009/09/09 14:30:27 UTC
[DOSGi] Server-side proxy doesn't work correctly
Hi,
I've got the following problem with DOSGi/CXF.
I've got a Service PassObject exposed by CXF/DOSGi running on the server. This service contains a method passAnObject which receives an object of type MathHelper. MathHelper is an interface known both to the server and client. AFAIU the server transparently creates a proxy for MathHelper when the client passes a MathHelper object.
Calls by the Server to methods of the MathHelper proxy only work on methods without arguments. A Call to a method with arguments raises an exception. The output of the server console is appended to this post.
Is it unsupported to pass objects to a remote service provider? Or is this some kind of bug?
Sample Code is on <https://issues.apache.org/jira/browse/CXF-2420>.
Thanks for your help,
Saul Goode
Output of server console (isGreaterZero is a method of MathHelper with an argument of type int):
02.09.2009 17:29:10 org.apache.cxf.phase.PhaseInterceptorChain doIntercept
INFO: Application has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: isGreaterZero is not delegated.
at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:148) ...
Re: [DOSGi] Server-side proxy doesn't work correctly
Posted by sa...@lavabit.com.
Benson Margulies wrote:
> 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?
The only thing I know is that it is automatically created. When I pass the
MathHelper object to the remote service, some component inside the DOSGi
bundle creates a proxy on the server.
Saul
Re: [DOSGi] Server-side proxy doesn't work correctly
Posted by Benson Margulies <bi...@gmail.com>.
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, <sa...@lavabit.com> 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)
>
>
>
>
Re: [DOSGi] Server-side proxy doesn't work correctly
Posted by sa...@lavabit.com.
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)
Re: [DOSGi] Server-side proxy doesn't work correctly
Posted by sa...@lavabit.com.
I wrote:
> I added @XmlSeeAlso(MathHelper.class) to MathHelperImpl and vice versa
> with no success.
>
> And i tried to set the osgi.remote.interfaces-property to
> "passobject.interfaces.PassObject" instead of "*" on the remote service
> and in the OSGI-INF/remote-service/*.xml-file. Unfortunately this didn't
> change nything, too. (Did you mean this by "You may need to limit the
> support for PathObject interface only"?)
>
> But I tried something different. Instead of using the interface type
> MathHelper to declare the method argument, I directly used MathHelperImpl.
> The remote service interface now looks like this:
>
> public interface PassObject {
> public void passAnObject(MathHelperImpl helper);
> // instead of: public void passAnObject(MathHelper helper);
> }
>
> Moreover I moved the package containing MathHelperImpl into the interface
> bundle (PassObjectInterface) which is installed on the server and the
> client.
I did this (moving the package), too, when trying the above
@XmlSeeAlso(MathHelper.class) stuff.
> Now it works with both JAXB and Aegis. Well, Aegis complains about a
> missing setter (as you already suggested), which I had to add to get it
> working.
>
> Thus the problem are arguments in a remote service, which are of an
> interface type. Somehow DOSGi can't resolve their type or sth like that.
The full code is on <http://ul.to/irbmwm>.
Saul
Re: [DOSGi] Server-side proxy doesn't work correctly
Posted by sa...@lavabit.com.
I added @XmlSeeAlso(MathHelper.class) to MathHelperImpl and vice versa
with no success.
And i tried to set the osgi.remote.interfaces-property to
"passobject.interfaces.PassObject" instead of "*" on the remote service
and in the OSGI-INF/remote-service/*.xml-file. Unfortunately this didn't
change nything, too. (Did you mean this by "You may need to limit the
support for PathObject interface only"?)
But I tried something different. Instead of using the interface type
MathHelper to declare the method argument, I directly used MathHelperImpl.
The remote service interface now looks like this:
public interface PassObject {
public void passAnObject(MathHelperImpl helper);
// instead of: public void passAnObject(MathHelper helper);
}
Moreover I moved the package containing MathHelperImpl into the interface
bundle (PassObjectInterface) which is installed on the server and the
client.
Now it works with both JAXB and Aegis. Well, Aegis complains about a
missing setter (as you already suggested), which I had to add to get it
working.
Thus the problem are arguments in a remote service, which are of an
interface type. Somehow DOSGi can't resolve their type or sth like that.
Greetings,
Saul
Sergey Beryozkin wrote:
> It appears there's some progress anyway. It's a JAXB-specific issue now.
> You
> can probably add @XmlSeeAlso(MathHelper.class) to MathHelperImpl.class or
> tell JAXB to ignore MathHelper alltogether (not sure how...). Now, another
> thing to check is : do you allow for all services be handled by DOSGi on
> the
> server side ? If yes then may be DOSGi does indeed tries to create a proxy
> on MathHelper...You may need to limit the support for PathObject interface
> only...
>
> Sergey
>
>
> Saul Goode wrote:
>> I'm not using the discovery service. I suppose, I have to set the
>> property
>> in the OSGI-INF/remote-service/*.xml file, too. After doing that, I get
>> an
>> exception on the client side:
>>
>> 10.09.2009 18:05:56
>> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
>> buildServiceFromClass
>> INFO: Creating Service {http://interfaces.passobject/}PassObject from
>> class passobject.interfaces.PassObject
>> PassObject service found
>> 10.09.2009 18:05:56 org.apache.cxf.phase.PhaseInterceptorChain
>> doIntercept
>> WARNUNG: Interceptor has thrown exception, unwinding now
>> org.apache.cxf.interceptor.Fault: Marshalling Error:
>> passobject.interfaces.MathHelper is not known to this context
>> at
>> org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:159)
>> [...]
>>
>>
>> Sergey Beryozkin wrote:
>>> This property must've been published by the discovery service, the
>>> logging
>>> on
>>> the server side should tell which properties have been published; if
>>> you're
>>> not using the discovery service then the client-side properties should
>>> also
>>> include a databinding property...
>>>
>>> cheers, Sergey
>>>
>>>
>>> Saul Goode wrote:
>>>>
>>>> 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)
>>>>
>>>> 10.09.2009 14:30:46 org.apache.cxf.phase.PhaseInterceptorChain
>>>> doIntercept
>>>> WARNUNG: Interceptor has thrown exception, unwinding now
>>>> 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)
>>>> at
>>>> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:530)
>>>> at
>>>> org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:114)
>>>> at
>>>> org.apache.cxf.interceptor.DocLiteralInInterceptor.getPara(DocLiteralInInterceptor.java:240)
>>>> at
>>>> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:117)
>>>> at
>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
>>>> at
>>>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:104)
>>>> at
>>>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:302)
>>>> at
>>>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:266)
>>>> at
>>>> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70)
>>>> at
>>>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729)
>>>> at
>>>> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
>>>> at
>>>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>>>> at org.mortbay.jetty.Server.handle(Server.java:324)
>>>> at
>>>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
>>>> at
>>>> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:843)
>>>> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:647)
>>>> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
>>>> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
>>>> at
>>>> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
>>>> at
>>>> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)
>>>> Caused by: javax.xml.bind.UnmarshalException
>>>> - with linked exception:
>>>> [javax.xml.bind.UnmarshalException: unexpected element
>>>> (uri:"http://interfaces.passobject/", local:"arg0"). Expected elements
>>>> are
>>>> (none)]
>>>> at
>>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:421)
>>>> at
>>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:360)
>>>> at
>>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:330)
>>>> at
>>>> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:610)
>>>> ... 20 more
>>>> Caused by: javax.xml.bind.UnmarshalException: unexpected element
>>>> (uri:"http://interfaces.passobject/", local:"arg0"). Expected elements
>>>> are
>>>> (none)
>>>> at
>>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:603)
>>>> at
>>>> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:244)
>>>> at
>>>> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:239)
>>>> at
>>>> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:116)
>>>> at
>>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext$DefaultRootLoader.childElement(UnmarshallingContext.java:1009)
>>>> at
>>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:446)
>>>> at
>>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:427)
>>>> at
>>>> com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleStartElement(StAXStreamConnector.java:275)
>>>> at
>>>> com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:209)
>>>> at
>>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:358)
>>>> ... 22 more
>>>> Caused by: javax.xml.bind.UnmarshalException: unexpected element
>>>> (uri:"http://interfaces.passobject/", local:"arg0"). Expected elements
>>>> are
>>>> (none)
>>>> ... 32 more
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/-DOSGi--Server-side-proxy-doesn%27t-work-correctly-tp25365318p25383348.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>
>>>
>>> ____________________________________________________________________________________
>>> Introducing Branchr
>>> Super Simple Advertising
>>> http://click.lavabit.com/?pub=78&ad=0023&url=aHR0cDovL2JyYW5jaHIuY29tLw==
>>> ____________________________________________________________________________________
>>>
>>
>>
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/-DOSGi--Server-side-proxy-doesn%27t-work-correctly-tp25365318p25387009.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
> ____________________________________________________________________________________
> Introducing Branchr
> Super Simple Advertising
> http://click.lavabit.com/?pub=78&ad=0023&url=aHR0cDovL2JyYW5jaHIuY29tLw==
> ____________________________________________________________________________________
>
Re: [DOSGi] Server-side proxy doesn't work correctly
Posted by Sergey Beryozkin <se...@iona.com>.
It appears there's some progress anyway. It's a JAXB-specific issue now. You
can probably add @XmlSeeAlso(MathHelper.class) to MathHelperImpl.class or
tell JAXB to ignore MathHelper alltogether (not sure how...). Now, another
thing to check is : do you allow for all services be handled by DOSGi on the
server side ? If yes then may be DOSGi does indeed tries to create a proxy
on MathHelper...You may need to limit the support for PathObject interface
only...
Sergey
Saul Goode wrote:
>
> I'm not using the discovery service. I suppose, I have to set the property
> in the OSGI-INF/remote-service/*.xml file, too. After doing that, I get an
> exception on the client side:
>
> 10.09.2009 18:05:56
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
> buildServiceFromClass
> INFO: Creating Service {http://interfaces.passobject/}PassObject from
> class passobject.interfaces.PassObject
> PassObject service found
> 10.09.2009 18:05:56 org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> WARNUNG: Interceptor has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Marshalling Error:
> passobject.interfaces.MathHelper is not known to this context
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:159)
> at org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:169)
> at
> org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(AbstractOutDatabindingInterceptor.java:105)
> at
> org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(BareOutInterceptor.java:68)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:472)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:302)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:254)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> at org.apache.cxf.frontend.ClientProxy.invoke(ClientProxy.java:68)
> at $Proxy34.passAnObject(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.cxf.dosgi.dsw.handlers.ServiceInvocationHandler.invoke(ServiceInvocationHandler.java:59)
> at $Proxy34.passAnObject(Unknown Source)
> at passobject.client.Activator$1.addingService(Activator.java:21)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:840)
> at
> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:124)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:930)
> at
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:220)
> at
> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:149)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:757)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:712)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:129)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:206)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:506)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:524)
> at
> org.apache.cxf.dosgi.dsw.hooks.AbstractClientHook.proxifyMatchingInterface(AbstractClientHook.java:118)
> at
> org.apache.cxf.dosgi.dsw.hooks.AbstractClientHook.processNotification(AbstractClientHook.java:91)
> at
> org.apache.cxf.dosgi.dsw.hooks.AbstractClientHook$DiscoveryCallback.serviceChanged(AbstractClientHook.java:297)
> at
> org.apache.cxf.dosgi.discovery.local.LocalDiscoveryService.triggerCallbacks(LocalDiscoveryService.java:340)
> at
> org.apache.cxf.dosgi.discovery.local.LocalDiscoveryService.triggerCallbacks(LocalDiscoveryService.java:313)
> at
> org.apache.cxf.dosgi.discovery.local.LocalDiscoveryService.addedServiceDescription(LocalDiscoveryService.java:152)
> at
> org.apache.cxf.dosgi.discovery.local.LocalDiscoveryService.findDeclaredRemoteServices(LocalDiscoveryService.java:137)
> at
> org.apache.cxf.dosgi.discovery.local.LocalDiscoveryService.bundleChanged(LocalDiscoveryService.java:111)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:916)
> at
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:220)
> at
> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:330)
> Caused by: javax.xml.bind.MarshalException
> - with linked exception:
> [javax.xml.bind.JAXBException: passobject.interfaces.MathHelper is not
> known to this context]
> at
> com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:331)
> at
> com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:257)
> at
> javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:100)
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject(JAXBEncoderDecoder.java:444)
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:138)
> ... 42 more
> Caused by: javax.xml.bind.JAXBException: passobject.interfaces.MathHelper
> is not known to this context
> at
> com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:242)
> at
> com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:257)
> at
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:143)
> at
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:185)
> at
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:305)
> at
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:312)
> at
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:71)
> at
> com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:490)
> at
> com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:328)
> ... 46 more
> Caused by: javax.xml.bind.JAXBException: passobject.interfaces.MathHelper
> is not known to this context
> at
> com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:587)
> at
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:140)
> ... 52 more
>
>
>> This property must've been published by the discovery service, the
>> logging
>> on
>> the server side should tell which properties have been published; if
>> you're
>> not using the discovery service then the client-side properties should
>> also
>> include a databinding property...
>>
>> cheers, Sergey
>>
>>
>> Saul Goode wrote:
>>>
>>> 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)
>>>
>>> 10.09.2009 14:30:46 org.apache.cxf.phase.PhaseInterceptorChain
>>> doIntercept
>>> WARNUNG: Interceptor has thrown exception, unwinding now
>>> 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)
>>> at
>>> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:530)
>>> at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:114)
>>> at
>>> org.apache.cxf.interceptor.DocLiteralInInterceptor.getPara(DocLiteralInInterceptor.java:240)
>>> at
>>> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:117)
>>> at
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
>>> at
>>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:104)
>>> at
>>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:302)
>>> at
>>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:266)
>>> at
>>> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70)
>>> at
>>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729)
>>> at
>>> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
>>> at
>>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>>> at org.mortbay.jetty.Server.handle(Server.java:324)
>>> at
>>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
>>> at
>>> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:843)
>>> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:647)
>>> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
>>> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
>>> at
>>> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
>>> at
>>> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)
>>> Caused by: javax.xml.bind.UnmarshalException
>>> - with linked exception:
>>> [javax.xml.bind.UnmarshalException: unexpected element
>>> (uri:"http://interfaces.passobject/", local:"arg0"). Expected elements
>>> are
>>> (none)]
>>> at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:421)
>>> at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:360)
>>> at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:330)
>>> at
>>> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:610)
>>> ... 20 more
>>> Caused by: javax.xml.bind.UnmarshalException: unexpected element
>>> (uri:"http://interfaces.passobject/", local:"arg0"). Expected elements
>>> are
>>> (none)
>>> at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:603)
>>> at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:244)
>>> at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:239)
>>> at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:116)
>>> at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext$DefaultRootLoader.childElement(UnmarshallingContext.java:1009)
>>> at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:446)
>>> at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:427)
>>> at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleStartElement(StAXStreamConnector.java:275)
>>> at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:209)
>>> at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:358)
>>> ... 22 more
>>> Caused by: javax.xml.bind.UnmarshalException: unexpected element
>>> (uri:"http://interfaces.passobject/", local:"arg0"). Expected elements
>>> are
>>> (none)
>>> ... 32 more
>>>
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/-DOSGi--Server-side-proxy-doesn%27t-work-correctly-tp25365318p25383348.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>>
>> ____________________________________________________________________________________
>> Introducing Branchr
>> Super Simple Advertising
>> http://click.lavabit.com/?pub=78&ad=0023&url=aHR0cDovL2JyYW5jaHIuY29tLw==
>> ____________________________________________________________________________________
>>
>
>
>
>
>
--
View this message in context: http://www.nabble.com/-DOSGi--Server-side-proxy-doesn%27t-work-correctly-tp25365318p25387009.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: [DOSGi] Server-side proxy doesn't work correctly
Posted by sa...@lavabit.com.
I'm not using the discovery service. I suppose, I have to set the property
in the OSGI-INF/remote-service/*.xml file, too. After doing that, I get an
exception on the client side:
10.09.2009 18:05:56
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service {http://interfaces.passobject/}PassObject from
class passobject.interfaces.PassObject
PassObject service found
10.09.2009 18:05:56 org.apache.cxf.phase.PhaseInterceptorChain doIntercept
WARNUNG: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Marshalling Error:
passobject.interfaces.MathHelper is not known to this context
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:159)
at org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:169)
at
org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(AbstractOutDatabindingInterceptor.java:105)
at
org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(BareOutInterceptor.java:68)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:472)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:302)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:254)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at org.apache.cxf.frontend.ClientProxy.invoke(ClientProxy.java:68)
at $Proxy34.passAnObject(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.cxf.dosgi.dsw.handlers.ServiceInvocationHandler.invoke(ServiceInvocationHandler.java:59)
at $Proxy34.passAnObject(Unknown Source)
at passobject.client.Activator$1.addingService(Activator.java:21)
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896)
at
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233)
at
org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:840)
at
org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:124)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:930)
at
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:220)
at
org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:149)
at
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:757)
at
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:712)
at
org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:129)
at
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:206)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:506)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:524)
at
org.apache.cxf.dosgi.dsw.hooks.AbstractClientHook.proxifyMatchingInterface(AbstractClientHook.java:118)
at
org.apache.cxf.dosgi.dsw.hooks.AbstractClientHook.processNotification(AbstractClientHook.java:91)
at
org.apache.cxf.dosgi.dsw.hooks.AbstractClientHook$DiscoveryCallback.serviceChanged(AbstractClientHook.java:297)
at
org.apache.cxf.dosgi.discovery.local.LocalDiscoveryService.triggerCallbacks(LocalDiscoveryService.java:340)
at
org.apache.cxf.dosgi.discovery.local.LocalDiscoveryService.triggerCallbacks(LocalDiscoveryService.java:313)
at
org.apache.cxf.dosgi.discovery.local.LocalDiscoveryService.addedServiceDescription(LocalDiscoveryService.java:152)
at
org.apache.cxf.dosgi.discovery.local.LocalDiscoveryService.findDeclaredRemoteServices(LocalDiscoveryService.java:137)
at
org.apache.cxf.dosgi.discovery.local.LocalDiscoveryService.bundleChanged(LocalDiscoveryService.java:111)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:916)
at
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:220)
at
org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:330)
Caused by: javax.xml.bind.MarshalException
- with linked exception:
[javax.xml.bind.JAXBException: passobject.interfaces.MathHelper is not
known to this context]
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:331)
at
com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:257)
at
javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:100)
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject(JAXBEncoderDecoder.java:444)
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:138)
... 42 more
Caused by: javax.xml.bind.JAXBException: passobject.interfaces.MathHelper
is not known to this context
at
com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:242)
at
com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:257)
at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:143)
at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:185)
at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:305)
at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:312)
at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:71)
at
com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:490)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:328)
... 46 more
Caused by: javax.xml.bind.JAXBException: passobject.interfaces.MathHelper
is not known to this context
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:587)
at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:140)
... 52 more
> This property must've been published by the discovery service, the logging
> on
> the server side should tell which properties have been published; if
> you're
> not using the discovery service then the client-side properties should
> also
> include a databinding property...
>
> cheers, Sergey
>
>
> Saul Goode wrote:
>>
>> 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)
>>
>> 10.09.2009 14:30:46 org.apache.cxf.phase.PhaseInterceptorChain
>> doIntercept
>> WARNUNG: Interceptor has thrown exception, unwinding now
>> 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)
>> at
>> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:530)
>> at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:114)
>> at
>> org.apache.cxf.interceptor.DocLiteralInInterceptor.getPara(DocLiteralInInterceptor.java:240)
>> at
>> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:117)
>> at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
>> at
>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:104)
>> at
>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:302)
>> at
>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:266)
>> at
>> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70)
>> at
>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729)
>> at
>> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
>> at
>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>> at org.mortbay.jetty.Server.handle(Server.java:324)
>> at
>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
>> at
>> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:843)
>> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:647)
>> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
>> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
>> at
>> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
>> at
>> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)
>> Caused by: javax.xml.bind.UnmarshalException
>> - with linked exception:
>> [javax.xml.bind.UnmarshalException: unexpected element
>> (uri:"http://interfaces.passobject/", local:"arg0"). Expected elements
>> are
>> (none)]
>> at
>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:421)
>> at
>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:360)
>> at
>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:330)
>> at
>> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:610)
>> ... 20 more
>> Caused by: javax.xml.bind.UnmarshalException: unexpected element
>> (uri:"http://interfaces.passobject/", local:"arg0"). Expected elements
>> are
>> (none)
>> at
>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:603)
>> at
>> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:244)
>> at
>> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:239)
>> at
>> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:116)
>> at
>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext$DefaultRootLoader.childElement(UnmarshallingContext.java:1009)
>> at
>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:446)
>> at
>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:427)
>> at
>> com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleStartElement(StAXStreamConnector.java:275)
>> at
>> com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:209)
>> at
>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:358)
>> ... 22 more
>> Caused by: javax.xml.bind.UnmarshalException: unexpected element
>> (uri:"http://interfaces.passobject/", local:"arg0"). Expected elements
>> are
>> (none)
>> ... 32 more
>>
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/-DOSGi--Server-side-proxy-doesn%27t-work-correctly-tp25365318p25383348.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
> ____________________________________________________________________________________
> Introducing Branchr
> Super Simple Advertising
> http://click.lavabit.com/?pub=78&ad=0023&url=aHR0cDovL2JyYW5jaHIuY29tLw==
> ____________________________________________________________________________________
>
Re: [DOSGi] Server-side proxy doesn't work correctly
Posted by Sergey Beryozkin <se...@iona.com>.
This property must've been published by the discovery service, the logging on
the server side should tell which properties have been published; if you're
not using the discovery service then the client-side properties should also
include a databinding property...
cheers, Sergey
Saul Goode wrote:
>
> 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)
>
> 10.09.2009 14:30:46 org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> WARNUNG: Interceptor has thrown exception, unwinding now
> 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)
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:530)
> at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:114)
> at
> org.apache.cxf.interceptor.DocLiteralInInterceptor.getPara(DocLiteralInInterceptor.java:240)
> at
> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:117)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:104)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:302)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:266)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
> at org.mortbay.jetty.Server.handle(Server.java:324)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:843)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:647)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
> at
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)
> Caused by: javax.xml.bind.UnmarshalException
> - with linked exception:
> [javax.xml.bind.UnmarshalException: unexpected element
> (uri:"http://interfaces.passobject/", local:"arg0"). Expected elements are
> (none)]
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:421)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:360)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:330)
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:610)
> ... 20 more
> Caused by: javax.xml.bind.UnmarshalException: unexpected element
> (uri:"http://interfaces.passobject/", local:"arg0"). Expected elements are
> (none)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:603)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:244)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:239)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:116)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext$DefaultRootLoader.childElement(UnmarshallingContext.java:1009)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:446)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:427)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleStartElement(StAXStreamConnector.java:275)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:209)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:358)
> ... 22 more
> Caused by: javax.xml.bind.UnmarshalException: unexpected element
> (uri:"http://interfaces.passobject/", local:"arg0"). Expected elements are
> (none)
> ... 32 more
>
>
>
>
--
View this message in context: http://www.nabble.com/-DOSGi--Server-side-proxy-doesn%27t-work-correctly-tp25365318p25383348.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: [DOSGi] Server-side proxy doesn't work correctly
Posted by sa...@lavabit.com.
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)
Re: [DOSGi] Server-side proxy doesn't work correctly
Posted by Sergey Beryozkin <se...@iona.com>.
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.
cheers, Sergey
Saul Goode wrote:
>
> Sergey Beryozkin wrote:
>> MathHelperImpl should probably have a field 'String name' as well as a
>> setName(String name) setter and it might make Aegis happy...Saul, can you
>> try it ?
>
> I tried it (see appended code), but the same exception was thrown on the
> server. The call to getName() already works. But the call to
> isGreaterZero(int) causes the exception.
>
> Greetings,
> Saul
>
>
> New source of MathHelperImpl:
>
> package passobject.impl;
> import passobject.interfaces.MathHelper;
>
> public class MathHelperImpl implements MathHelper {
> String name = "MyMathHelperWithSetter";
> public void setName(String name) { this.name = name; }
> public String getName() { return name; }
>
> public boolean isGreaterZero(int number) { return number > 0; }
> }
>
>
>
>
--
View this message in context: http://www.nabble.com/-DOSGi--Server-side-proxy-doesn%27t-work-correctly-tp25365318p25379808.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: [DOSGi] Server-side proxy doesn't work correctly
Posted by Benson Margulies <bi...@gmail.com>.
There's a JIRA bouncing around for this, and the problem is that the proxy
refuses to do the isGreaterZero operation.
On Wed, Sep 9, 2009 at 2:48 PM, <sa...@lavabit.com> wrote:
> Sergey Beryozkin wrote:
> > MathHelperImpl should probably have a field 'String name' as well as a
> > setName(String name) setter and it might make Aegis happy...Saul, can you
> > try it ?
>
> I tried it (see appended code), but the same exception was thrown on the
> server. The call to getName() already works. But the call to
> isGreaterZero(int) causes the exception.
>
> Greetings,
> Saul
>
>
> New source of MathHelperImpl:
>
> package passobject.impl;
> import passobject.interfaces.MathHelper;
>
> public class MathHelperImpl implements MathHelper {
> String name = "MyMathHelperWithSetter";
> public void setName(String name) { this.name = name; }
> public String getName() { return name; }
>
> public boolean isGreaterZero(int number) { return number > 0; }
> }
>
>
>
Re: [DOSGi] Server-side proxy doesn't work correctly
Posted by sa...@lavabit.com.
Sergey Beryozkin wrote:
> MathHelperImpl should probably have a field 'String name' as well as a
> setName(String name) setter and it might make Aegis happy...Saul, can you
> try it ?
I tried it (see appended code), but the same exception was thrown on the
server. The call to getName() already works. But the call to
isGreaterZero(int) causes the exception.
Greetings,
Saul
New source of MathHelperImpl:
package passobject.impl;
import passobject.interfaces.MathHelper;
public class MathHelperImpl implements MathHelper {
String name = "MyMathHelperWithSetter";
public void setName(String name) { this.name = name; }
public String getName() { return name; }
public boolean isGreaterZero(int number) { return number > 0; }
}
Re: [DOSGi] Server-side proxy doesn't work correctly
Posted by Sergey Beryozkin <se...@iona.com>.
MathHelperImpl should probably have a field 'String name' as well as a
setName(String name) setter and it might make Aegis happy...Saul, can you
try it ?
cheers, Sergey
David Bosschaert wrote:
>
> Ah, ok I understand - thanks for explaining.
> I've reassigned your problem to the Aegis Databinding, as I think
> that's where it may be...
>
> David
>
> 2009/9/9 Saul Goode <sa...@lavabit.com>:
>>
>>
>> David Bosschaert wrote:
>>>
>>> Hi Saul,
>>>
>>> Methods with arguments are supported, see the greeter demo for an
>>> example:
>>> http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html.
>>> This uses the following signature for the remote OSGi Service:
>>> public interface GreeterService {
>>> Map<GreetingPhrase, String> greetMe(String name) throws
>>> GreeterException;
>>> }
>>> [...]
>>>
>>
>> Thanks for the answer!
>>
>> I think I have to clarify my question. I know that it's possible to
>> remotely
>> expose a service which has a method with arguments. But my problem is
>> that I
>> pass an object to a remotely exposed service and can't call a method with
>> arguments on that object. Calling a method without arguments does work
>> though. See the code on <https://issues.apache.org/jira/browse/CXF-2420>.
>> --
>> View this message in context:
>> http://www.nabble.com/-DOSGi--Server-side-proxy-doesn%27t-work-correctly-tp25365318p25366737.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/-DOSGi--Server-side-proxy-doesn%27t-work-correctly-tp25365318p25368490.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: [DOSGi] Server-side proxy doesn't work correctly
Posted by David Bosschaert <da...@gmail.com>.
Ah, ok I understand - thanks for explaining.
I've reassigned your problem to the Aegis Databinding, as I think
that's where it may be...
David
2009/9/9 Saul Goode <sa...@lavabit.com>:
>
>
> David Bosschaert wrote:
>>
>> Hi Saul,
>>
>> Methods with arguments are supported, see the greeter demo for an
>> example:
>> http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html.
>> This uses the following signature for the remote OSGi Service:
>> public interface GreeterService {
>> Map<GreetingPhrase, String> greetMe(String name) throws
>> GreeterException;
>> }
>> [...]
>>
>
> Thanks for the answer!
>
> I think I have to clarify my question. I know that it's possible to remotely
> expose a service which has a method with arguments. But my problem is that I
> pass an object to a remotely exposed service and can't call a method with
> arguments on that object. Calling a method without arguments does work
> though. See the code on <https://issues.apache.org/jira/browse/CXF-2420>.
> --
> View this message in context: http://www.nabble.com/-DOSGi--Server-side-proxy-doesn%27t-work-correctly-tp25365318p25366737.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
Re: [DOSGi] Server-side proxy doesn't work correctly
Posted by Saul Goode <sa...@lavabit.com>.
David Bosschaert wrote:
>
> Hi Saul,
>
> Methods with arguments are supported, see the greeter demo for an
> example:
> http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html.
> This uses the following signature for the remote OSGi Service:
> public interface GreeterService {
> Map<GreetingPhrase, String> greetMe(String name) throws
> GreeterException;
> }
> [...]
>
Thanks for the answer!
I think I have to clarify my question. I know that it's possible to remotely
expose a service which has a method with arguments. But my problem is that I
pass an object to a remotely exposed service and can't call a method with
arguments on that object. Calling a method without arguments does work
though. See the code on <https://issues.apache.org/jira/browse/CXF-2420>.
--
View this message in context: http://www.nabble.com/-DOSGi--Server-side-proxy-doesn%27t-work-correctly-tp25365318p25366737.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: [DOSGi] Server-side proxy doesn't work correctly
Posted by David Bosschaert <da...@gmail.com>.
Hi Saul,
Methods with arguments are supported, see the greeter demo for an
example: http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html.
This uses the following signature for the remote OSGi Service:
public interface GreeterService {
Map<GreetingPhrase, String> greetMe(String name) throws GreeterException;
}
However, there are a couple of things that you need to be aware of:
* the types need to be appropriately visible by both the client and
the server. this is normally done by putting them in a shared bundle.
The 'Greeter Interface' bundle in the greeter example.
* invocation semantics are by-value
* generally you shouldn't make use of very complex types or types with
a lot of behaviour. Simple value types (or arrays/collections of
these) should be fine, or custom types that are built up from simple
value types should also work.
Hope this helps,
David
2009/9/9 <o5...@sneakemail.com>:
> Hi,
> I've got the following problem with DOSGi/CXF.
>
> I've got a Service PassObject exposed by CXF/DOSGi running on the server. This service contains a method passAnObject which receives an object of type MathHelper. MathHelper is an interface known both to the server and client. AFAIU the server transparently creates a proxy for MathHelper when the client passes a MathHelper object.
>
> Calls by the Server to methods of the MathHelper proxy only work on methods without arguments. A Call to a method with arguments raises an exception. The output of the server console is appended to this post.
>
> Is it unsupported to pass objects to a remote service provider? Or is this some kind of bug?
>
> Sample Code is on <https://issues.apache.org/jira/browse/CXF-2420>.
>
> Thanks for your help,
> Saul Goode
>
>
> Output of server console (isGreaterZero is a method of MathHelper with an argument of type int):
>
> 02.09.2009 17:29:10 org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> INFO: Application has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: isGreaterZero is not delegated.
> at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:148) ...
>