Hi David, I think I'm getting hung up on "shared both on the consumer side as well as on the provider side". The class (interface) in question is definitely deployed and exported on both the client and the server, and both the client is able to initiate the call, and the server is able to publish the call using the interface in question. I'm guessing it's not 'shared enough' on the server side, though. It appears it fails when the server side is trying to unmarshall the XML and create the associated class. So I'm wondering what needs to be done to give the bundle that's doing the unmarshalling work the visibility into the classes that it will be unmarshalling into. In other words, is aegis complaining because it has no idea where to find the class, and if so, how do I tell it where to find it?
Thanks, Thom -----Original Message----- From: David Bosschaert [mailto:[email protected]] Sent: Thursday, September 10, 2009 2:32 AM To: [email protected] Subject: Re: [DOSGi] with complex types in a service Hi Thom, Well, the greeter demo (http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html) uses a user-defined type as a return value (and a user-defined type as an exception). Having a user-defined type as a method argument would use the same mechanics I think... There are certainly limits to this, AFAIK mostly the limits that the Aegis Data binding has, but in general what you need to do is put your user-defined types in an interfaces bundle which is shared both on the consumer side as well as on the provider side. This is also done in the greeter demo. Hope this helps, David 2009/9/10 Shulok, Thomas <[email protected]>: > Hi All, > > Potentially stupid question, but here goes... > > I've worked through the various demos, and have DOSGi via web service > transport working well. None of the examples I've seen indicate how to > expose an interface with complex types, though. By complex, I mean something > that's not part of the natural Java distribution. For example, you have your > own interace Foo that you pass as an argument to one of the members of your > service, a la > > interface MyService > { > void invoke(Foo aFoo); > } > > I did run across this in the broader CXF docs > > /* Advanced usecase of passing an Interface in. JAX-WS/JAXB does not > * support interfaces directly. Special XmlAdapter classes need to > * be written to handle them > */ > String sayHiToUser(User user); > > > but I'm unclear how this fits into the picture when the wsdl is being > generated on the fly from an exported DOSGi interface. To be sure, the wsdl > does get generated, but when it's invoked, the underlying Aegis code > complains that it can't instantiate the class: > > Sep 9, 2009 5:18:15 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept > WARNING: Interceptor has thrown exception, unwinding now > org.apache.cxf.interceptor.Fault: Couldn't instantiate class. > com.utility.JDBCSelectStatement. Nested exception is > java.lang.InstantiationException: com.utility.JDBCSelectStatement > at > org.apache.cxf.aegis.databinding.XMLStreamDataReader.read(XMLStreamDataReader.java:63) > at > org.apache.cxf.aegis.databinding.XMLStreamDataReader.read(XMLStreamDataReader.java:38) > 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:205) > 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: org.apache.cxf.aegis.DatabindingException: Couldn't instantiate > class. com.utility.JDBCSelectStatement. Nested exception is > java.lang.InstantiationException: com.utility.JDBCSelectStatement > > > Is there a way to use complex types with DOSGi? Anyone have a simple example? > > Many thanks, > Thom > >
