serialization problems disected..
omatzura Feb 17, 2005 10:04 AMok.. 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