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]
