You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/03/13 22:51:35 UTC
[sca-java-integration-branch] Missing WSDL type imports causes aymetrical behviour
Hi
I remember Dan discussing this on the list before but I can't put my finger
on the thread....
If I run the databinding WS tests without including the factory for the WSDL
XML types in the composite...
<dbsdo:import.sdo factory="
org.apache.tuscany.sca.itest.databinding.services.ServicesFactory"/>
Then the web service call fails with the following:
java.lang.ClassCastException: org.apache.tuscany.sdo.util.BasicSequenceincompat
ible with org.apache.tuscany.sca.itest.databinding.types.PersonType
at $Proxy26.greetPersonType(Unknown Source)
at
org.apache.tuscany.sca.itest.sdodatabinding.GreeterServiceClientImpl.
greetPersonType(GreeterServiceClientImpl.java:47)
...
In the case where I am getting the error Tuscany can't convert the wrapped
return type from the call back to the type expected in the client. This is
clearly something to do with Tuscany not having the correct types registered
(adding the above import fixes it). But the thing that confuses me is that
it only fails on processing the return message in the client. It has quite
happily
1/ Converted the request message into a wrapped message on the client
2/ Converted the wrapped message back into the required message on the
server
3/ Converted the response message into a wrapped response on the server
only to fail at the final hurdle when trying to unwrap the response on the
client. So it seems to be able to do quite a lot without the imported
information. Why is it required for the last step.
I'm happy to look into this if there is not an obvious answer. If nothing
else we need better error messages here.
Regards
Simon
Re: [sca-java-integration-branch] Missing WSDL type imports causes aymetrical behviour
Posted by Simon Laws <si...@googlemail.com>.
On 3/13/07, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> The ClassCastException will only happen if we try to get the child element
> out of the repsonse wrapper (which is an instance of AnyTypeDataObjectImpl
> because the model is not registered with SDO runtime) and cast it to a
> generated SDO interface. If the ServiceFactory is not registered, the data
> (from the inline schema of the WSDL) are then represented by
> "org.apache.tuscany.sdo.impl.AnyTypeDataObjectImpl" which doesn't have
> problems to convert to XML or vice versa. But now the child of
> AnyTypeDataObjectImpl is BasicSequence instead of the real PersonType
> since
> the types are not known.
>
> It's very common that we define XSD elements and types in the inline
> schemas
> of WSDL. These need to be registered so SDO runtime can work correctly. I
> could try to make your special case working (your wsdl only has element
> definitions) and I don't see much value.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Simon Laws" <si...@googlemail.com>
> To: "tuscany-dev" <tu...@ws.apache.org>
> Sent: Tuesday, March 13, 2007 2:51 PM
> Subject: [sca-java-integration-branch] Missing WSDL type imports causes
> aymetrical behviour
>
>
> > Hi
> >
> > I remember Dan discussing this on the list before but I can't put my
> > finger
> > on the thread....
> >
> > If I run the databinding WS tests without including the factory for the
> > WSDL
> > XML types in the composite...
> >
> > <dbsdo:import.sdo factory="
> > org.apache.tuscany.sca.itest.databinding.services.ServicesFactory"/>
> >
> > Then the web service call fails with the following:
> >
> > java.lang.ClassCastException:
> > org.apache.tuscany.sdo.util.BasicSequenceincompat
> > ible with org.apache.tuscany.sca.itest.databinding.types.PersonType
> > at $Proxy26.greetPersonType(Unknown Source)
> > at
> > org.apache.tuscany.sca.itest.sdodatabinding.GreeterServiceClientImpl.
> > greetPersonType(GreeterServiceClientImpl.java:47)
> > ...
> >
> > In the case where I am getting the error Tuscany can't convert the
> wrapped
> > return type from the call back to the type expected in the client. This
> is
> > clearly something to do with Tuscany not having the correct types
> > registered
> > (adding the above import fixes it). But the thing that confuses me is
> that
> > it only fails on processing the return message in the client. It has
> quite
> > happily
> >
> > 1/ Converted the request message into a wrapped message on the client
> > 2/ Converted the wrapped message back into the required message on the
> > server
> > 3/ Converted the response message into a wrapped response on the server
> >
> > only to fail at the final hurdle when trying to unwrap the response on
> the
> > client. So it seems to be able to do quite a lot without the imported
> > information. Why is it required for the last step.
> >
> > I'm happy to look into this if there is not an obvious answer. If
> nothing
> > else we need better error messages here.
> >
> > Regards
> >
> > Simon
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Hi Raymond, thanks for the info.
I still don't understand how this works with the requst message (as opposed
to the response message). At the target component the message handlers (?)
are converting from the XML to the wrapped object and from there to the
child object successfully. What extra information is available at the target
component for request processing that isn't available for response
processing at the client component?
Simon
Re: [sca-java-integration-branch] Missing WSDL type imports causes aymetrical behviour
Posted by Raymond Feng <en...@gmail.com>.
Hi,
The ClassCastException will only happen if we try to get the child element
out of the repsonse wrapper (which is an instance of AnyTypeDataObjectImpl
because the model is not registered with SDO runtime) and cast it to a
generated SDO interface. If the ServiceFactory is not registered, the data
(from the inline schema of the WSDL) are then represented by
"org.apache.tuscany.sdo.impl.AnyTypeDataObjectImpl" which doesn't have
problems to convert to XML or vice versa. But now the child of
AnyTypeDataObjectImpl is BasicSequence instead of the real PersonType since
the types are not known.
It's very common that we define XSD elements and types in the inline schemas
of WSDL. These need to be registered so SDO runtime can work correctly. I
could try to make your special case working (your wsdl only has element
definitions) and I don't see much value.
Thanks,
Raymond
----- Original Message -----
From: "Simon Laws" <si...@googlemail.com>
To: "tuscany-dev" <tu...@ws.apache.org>
Sent: Tuesday, March 13, 2007 2:51 PM
Subject: [sca-java-integration-branch] Missing WSDL type imports causes
aymetrical behviour
> Hi
>
> I remember Dan discussing this on the list before but I can't put my
> finger
> on the thread....
>
> If I run the databinding WS tests without including the factory for the
> WSDL
> XML types in the composite...
>
> <dbsdo:import.sdo factory="
> org.apache.tuscany.sca.itest.databinding.services.ServicesFactory"/>
>
> Then the web service call fails with the following:
>
> java.lang.ClassCastException:
> org.apache.tuscany.sdo.util.BasicSequenceincompat
> ible with org.apache.tuscany.sca.itest.databinding.types.PersonType
> at $Proxy26.greetPersonType(Unknown Source)
> at
> org.apache.tuscany.sca.itest.sdodatabinding.GreeterServiceClientImpl.
> greetPersonType(GreeterServiceClientImpl.java:47)
> ...
>
> In the case where I am getting the error Tuscany can't convert the wrapped
> return type from the call back to the type expected in the client. This is
> clearly something to do with Tuscany not having the correct types
> registered
> (adding the above import fixes it). But the thing that confuses me is that
> it only fails on processing the return message in the client. It has quite
> happily
>
> 1/ Converted the request message into a wrapped message on the client
> 2/ Converted the wrapped message back into the required message on the
> server
> 3/ Converted the response message into a wrapped response on the server
>
> only to fail at the final hurdle when trying to unwrap the response on the
> client. So it seems to be able to do quite a lot without the imported
> information. Why is it required for the last step.
>
> I'm happy to look into this if there is not an obvious answer. If nothing
> else we need better error messages here.
>
> Regards
>
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org