Hi Raymond/Frank I saw that you create TUSCANY-684. Could you describe the extent of this issue? Is this a major or minor issue? I understand that there's a bunch of development work going on right now, but do you have a feel for the time to resolution? If possible, we'd like to demo Tuscany a couple times next month.
Re commonj.sdo.DataObject: Yes, this works. Does SDO or the factory methods gen'd by the plugin have a utility/method to transfrom the DataObject into a Patient object? I'll look around. Also, we have a small test case to replicate the issue: http://firestruck.com/temp/complexhelloworldws.zip (web service, deploy to web container) http://firestruck.com/temp/complexhelloworldwsclient.zip (Tuscany client) Let us know where/how we can help. -Chris On 8/31/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, I think we probably have a problem with the proper scoping for the SDO types (especially static types which are registered by classloaders today). I'll start a new thread to involve the folks on the SDO side. Meanwhile, can you try to use "commonj.sdo.DataObject" for your business interface to see if it helps? Thanks, Raymond ----- Original Message ----- From: "Chris Wall" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, August 30, 2006 5:27 PM Subject: Re: Returning DynamicDataObjectImpl from web service call produces TargetException leads to ClassCastException > Hi Raymond. Thanks for your patience. > > With the factory declaraion I'm getting the same thing... > > org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{ > http://www.bea.com/medrec}getString' not found in registered SDO types. > at org.apache.tuscany.binding.celtix.io.NodeDataWriter.toXMLDocument( > NodeDataWriter.java:142) > at org.apache.tuscany.binding.celtix.io.NodeDataWriter.writeWrapper( > NodeDataWriter.java:84) > at org.apache.tuscany.binding.celtix.io.NodeDataWriter.writeWrapper( > NodeDataWriter.java:47) > at org.objectweb.celtix.bus.bindings.soap.SOAPBindingImpl.addParts( > SOAPBindingImpl.java:567) > at org.objectweb.celtix.bus.bindings.soap.SOAPBindingImpl.marshal( > SOAPBindingImpl.java:119) > at org.objectweb.celtix.bindings.Request.process(Request.java:91) > > > org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{ > http://www.bea.com/medrec}getPatient' not found in registered SDO types. > > Updated scdl: > > E:/sca/tuscany/java/samples/sca/medrec 190$ cat > target/classes/META-INF/sca/default.scdl > <?xml version="1.0" encoding="UTF-8"?> > <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"; > > xmlns:system="http://tuscany.apache.org/xmlns/system/1.0-SNAPSHOT > " > name="tuscanyWS2WLS"> > > <!--<import.sdo location="wsdl/MedRecWebServices.wsdl"/>--> > > <import.sdo factory="com.bea.proto.webservice.MedRecWebServicesFactory "/> > > <component name="MedRecWebServicesServiceComponent"> > <implementation.java class=" > com.bea.proto.webservice.client.MedRecWebServicesServiceComponent"/> > <references> > <reference > name="medRecWebServicesService">MedRecWebServicesService</reference> > </references> > </component> > > <reference name="MedRecWebServicesService"> > <interface.java interface=" > com.bea.proto.webservice.client.MedRecWebServicesService"/> > <binding.ws endpoint=" > http://www.bea.com/medrec#wsdl.endpoint(MedRecWebServices/MedRecWebServicesPort) > " > location="wsdl/MedRecWebServices.wsdl" /> > </reference> > > </composite> > > > On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote: >> >> Hi, Chris. >> >> You probably need to use the following "import.sdo": >> >> <import.sdo factory="com.bea.proto.webservice.MedRecWebServicesFactory "/> >> >> Thanks, >> Raymond >> >> ----- Original Message ----- >> From: "Chris Wall" <[EMAIL PROTECTED]> >> To: <[email protected]> >> Sent: Wednesday, August 30, 2006 4:24 PM >> Subject: Re: Returning DynamicDataObjectImpl from web service call >> produces >> TargetException leads to ClassCastException >> >> >> > Hey. Comments inline... >> > >> > >> > On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote: >> >> >> >> Hi, Chris. >> >> >> >> If you have <import.sdo location="wsdl/MedRecWebServices.wsdl"/>, it >> >> means >> >> that you prefer to use the dynamic SDO model derived from the >> >> WSDL/XSD. >> I >> >> have two questions: >> > >> > >> > CW: Ahh, I did not know. Yet, if I remove the import the following >> line >> > throws an exception: >> > >> > [NodeDataWriter} >> > Property property = xsdHelper.getGlobalProperty( >> > elementQName.getNamespaceURI(), elementQName.getLocalPart (), >> > true); >> > >> > org.apache.tuscany.spi.wire.InvocationRuntimeException: Type '{ >> > http://www.bea.com/medrec}getString' not found in registered SDO types. >> > >> > With import.sdo, this web service call returns successfully. >> > >> > 1) Is the exception from client side or server side? >> > >> > >> > CW: Client. Occurs within Proxy.getPatient(...). >> > >> > 2) What's our business interface expecting? The strongly-typed java >> >> class/interface generated by SDO or the dynamic DataObject? >> > >> > >> > CW: Strongly-typed: >> > >> > com.bea.proto.webservice.Patient >> > getPatient(com.bea.proto.webservice.PatientpPatient) throws Exception; >> > >> > >> > Basically, the "import.sdo" needs to be consistent with your business >> >> interface signature. >> >> >> >> Thanks, >> >> Raymond >> >> >> >> ----- Original Message ----- >> >> From: Chris Wall >> >> To: Raymond Feng >> >> Sent: Wednesday, August 30, 2006 4:05 PM >> >> Subject: Re: Returning DynamicDataObjectImpl from web service call >> >> produces >> >> TargetException leads to ClassCastException >> >> >> >> >> >> Hey Raymond. >> >> >> >> Our *client* scdl has: >> >> <import.sdolocation="wsdl/MedRecWebServices.wsdl"/>. >> >> >> >> Deserialized into the dynamic SDO makes >> >> sense. XMLStreamReader2XMLDocument >> >> parses the stream and creates a DynamicDataObjectImpl as it's root >> >> object. >> >> DynamicDataObjectImpl is aware of it's Patient context - >> >> name=getPatientResponse, package=java: com.bea.proto.webservice, and >> >> attributes. It's the root object that is returned from the binding. >> >> >> >> Shouldn't there be an intermediate step that generates a Patient >> object? >> >> >> >> -Chris >> >> >> >> >> >> >> >> On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> >> >> It seems that the exception is thrown from the target component and >> it's >> >> related to the static/dynamic SDO (The incoming XML got deserialized >> into >> >> the dynamic SDO instead of the generated static class which your >> >> component >> >> implementation code expects). >> >> >> >> What does the "import.sdo" look like on the server side? Using "< >> >> import.sdo >> >> factory="..."/>"? >> >> >> >> Thanks, >> >> Raymond >> >> ----- Original Message ----- >> >> From: Chris Wall >> >> To: [email protected] ; [EMAIL PROTECTED] >> >> Sent: Wednesday, August 30, 2006 2:37 PM >> >> Subject: Returning DynamicDataObjectImpl from web service call >> >> produces >> >> TargetException leads to ClassCastException >> >> >> >> >> >> Hi. After a successful invocation of a web service, a TargetException >> >> occurs ("Cannot evaulate $Proxy35.toString()") after body is returned >> >> from >> >> JDKOutboundInvocationHandler. This eventually leads to a >> >> ClassCastException: >> >> >> >> java.lang.ClassCastException: >> >> org.apache.tuscany.sdo.impl.DynamicDataObjectImpl >> >> at $Proxy35.getPatient(Unknown Source) >> >> at >> >> >> >> >> com.bea.proto.webservice.client.MedRecWebServicesServiceComponent.getPatient >> >> ( >> >> MedRecWebServicesServiceComponent.java:26) >> >> >> >> Unfortunately I couldn't figure out how to get the full stacktrace >> >> from >> >> TargetException. >> >> >> >> Admittedly, this one has me confused. My first question is why is >> >> this >> >> happening? My second question is when, if ever, does the SDO layer >> >> convert >> >> the DynamicDataObjectImpl back to the intended return object (in this >> >> case >> >> a >> >> Patient object). >> >> >> >> Thanks. >> >> >> >> -Chris >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
