1 Reply Latest reply on Feb 18, 2005 4:20 AM by Ole Matzura

    serialization problems disected..

    Ole Matzura Novice

      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..

      <root-type-qname xmlns:typeNS="our namespace">typeNS:OurRequestType</root-type-qname>

      in the wsdl these are defined as follows;

       <xsd:schema targetNamespace="our namespace">
       <xsd:element name="ourRequestElement" type="OurRequestType/>
       <message name="ServiceInputMessage">
       <part name="request" element="ourRequestElement"/>

      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;

       encodingStyle="" qname="ns:ourRequestElement"
       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

      <root-type-qname xmlns:typeNS="our namespace">typeNS:ourRequestElement</root-type-qname>

      (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?



        • 1. serialization problems disected.. part 2
          Ole Matzura Novice

          ok.. more testing shows the following; the above described scenario applies to ejb's exposing a web-service. When they also act as a ws-client, jbossws behaves slightly different;

          We have generated client stubs from existing docliteral wsdls using wscompile and added the according service-refs. wscompile generates the same type of mapping files as described above..

          our findings for the client calls are:

          1) "outgoing" serialization from our client (ie the request) needs the above mentioned modifications to work
          2) "incoming" deserialization (ie the remote response) works without modifications (!), ie for response elements/complexTypes jbossws correctly finds these in the generated mapping file

          ok.. next step is to test all the above with nodatabinding, both as server and client.. stay tuned..