ok.. another lenghty post about serialization issues..
we are implementing a number of docliteral web services generate from existing
wsdls. When generating our mapping files with wscompile, they contain the
following type-mappings for the message request/response parts in the schema..
| <java-xml-type-mapping>
| <java-type>our.request.Class</java-type>
| <root-type-qname xmlns:typeNS="our
namespace">typeNS:OurRequestType</root-type-qname>
| <qname-scope>complexType</qname-scope>
| <variable-mapping>
| etc..
|
in the wsdl these are defined as follows;
| ...
| <types>
| <xsd:schema targetNamespace="our namespace">
| <xsd:element name="ourRequestElement"
type="OurRequestType/>
| ....
| </xsd:schema>
| </types>
|
| <message name="ServiceInputMessage">
| <part name="request" element="ourRequestElement"/>
| </message>
|
|
this is in accordance with Basic Profile which "prohibts" the specification of
the complex type directly in the part definition;
R2204 A document-literal binding in a DESCRIPTION MUST refer, in each of its
soapbind:body element(s), only to wsdl:part element(s) that have been defined
using the element attribute.
Unfortunaly, when deploying our service, JBossWS fails to find the defined
mapping and gives a warning;
| [JavaWsdlMapping] Cannot find jaxrpc-mapping for type: {our
namespace}ourRequestElement
|
when invoking the service we get the (well known) fault;
| Deserializing parameter 'ourRequestElement': could not find deserializer
for type {our namespace}ourRequestElement
|
We have found 2 alternative solutions;
1) Add our own BeanSerializer mapping to ws4ee-deployment.xml;
| <typeMapping
| deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory"
| encodingStyle="" qname="ns:ourRequestElement"
| serializer="org.apache.axis.encoding.ser.BeanSerializerFactory"
| type="java:our.request.Class" xmlns:schema="our namespace"/>
|
This is not a good solution as it creates new problems; the BeanSerializer does
not seem to generate xml compliant with the complex types schema (see my other
post regarding element ordering).
2) Change the generated mapping to
| <java-xml-type-mapping>
| <java-type>our.class</java-type>
| <root-type-qname xmlns:typeNS="our
namespace">typeNS:ourRequestElement</root-type-qname>
| <qname-scope>element</qname-scope>
| <variable-mapping>
| etc..
|
(element specification instead of complex type)
This is the better solution as the generated xml now seems to comply with the
schema. Unfortunately for complex messages, changing generated files is not
very efficent :-)
>From my point of view, JBossWS should be able to handle the generated mapping
>file directly (ie specification of complexType instead of element).. is this a
>bug or am I (once again) missing something obvious?
regards!
/Ole
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3866930#3866930
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3866930
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
JBoss-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-user
