Uploaded image for project: 'Axis'
  1. Axis
  2. AXIS-1673

Problem with array of beans in 1.2RC2 (wrapped/literal)

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.2RC2
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      Server : Windows 2000
      Client : Windows Xp
      JVM : Sun 1.4.2

      Description

      There's a strange bug in axis 1.2RC2, dealing with array of beans.

      The signature of the called method is :
      public ArrayBean echoArrayBean(ArrayBean param);

      ArrayBean is defined like this :
      public class ArrayBean implements Serializable {
      private String stringData;
      private SimpleBean[] simpleBeanArrayData;
      ... accessors ...
      }

      And SimpleBean :
      public class SimpleBean implements Serializable

      { private String stringData; private int intData; ... accessors ... } The corresponding part of the WSDL generated by Axis follows (in different namespaces, but we don't care here) : <element name="echoArrayBean"> <complexType> <sequence> <element name="in0" type="tns1:ArrayBean"/> </sequence> </complexType> </element> <complexType name="ArrayOf_tns1_SimpleBean"> <sequence> <element maxOccurs="unbounded" minOccurs="0" name="item" type="tns1:SimpleBean"/> </sequence> </complexType> <complexType name="SimpleBean"> <sequence> <element name="intData" type="xsd:int"/> <element name="stringData" nillable="true" type="xsd:string"/> </sequence> </complexType> <complexType name="ArrayBean"> <sequence> <element name="simpleBeanArrayData" nillable="true" type="impl:ArrayOf_tns1_SimpleBean"/> <element name="stringData" nillable="true" type="xsd:string"/> </sequence> </complexType> What's important here is that "item" is correctly specified as an element of Array_Of_tns1_SimpleBean. When I try to invoke this operation with a Weblogic client, I get the following exception : java.rmi.RemoteException: SOAP Fault:javax.xml.rpc.soap.SOAPFaultException: org.xml.sax.SAXException: Invalid element in test.bean.SimpleBean - item The corresponding part in the soap message is : <n1:echoArrayBean><n1:in0><n2:simpleBeanArrayData xsi:type="n1:ArrayOf_tns1_SimpleBean"> <n1:item xsi:type="n2:SimpleBean"><n2:intData>-123456</n2:intData><n2:stringData>ces données sontcomplexes [à@}

      ]</n2:stringData></n1:item>
      <n1:item xsi:type="n2:SimpleBean"><n2:intData>-123456</n2:intData><n2:stringData>ces données sontcomplexes [à@}]</n2:stringData></n1:item>
      </n2:simpleBeanArrayData><n3:stringData>data</n3:stringData></n1:in0></n1:echoArrayBean>

      This message seems to be correct, according to the WSDL. Yet, Axis doesn't like it :/

      Note : we just tried with an Axis client: same soap message, same behaviour.

      Julien Wajsberg

      1. BeanPropertyDescriptor-diff.txt
        3 kB
        Jongjin Choi
      2. wrapped_literal_array_test.zip
        25 kB
        Jongjin Choi

        Activity

        Hide
        flashfr Julien Wajsberg added a comment -

        Quoted from the mailing list :

        "I have encountered this same situation with .NET. To fix the problem we had
        to make the array property a Java Bean Indexed Property. Your ArrayBean
        needs to have not only the simple getter and setter from simpleBeanArrayData
        but also a getter and setter by index, getSimpleBeanArrayData(int i) and
        setSimpleBeanArrayData(int i, SimpleBean bean).

        This keeps Axis from generating the ArrayOf_ type (which is not valid based
        on the WS-I spec)."

        This workaround works perfectly. The WSDL is slightly different, for the description of ArrayBean :

        <complexType name="ArrayBean">
        <sequence>
        <element maxOccurs="unbounded" name="simpleBeanArrayData" nillable="true" type="tns1:SimpleBean"/>
        <element name="stringData" nillable="true" type="xsd:string"/>
        </sequence>
        </complexType>
        </schema>

        Here, there isn't any wrapping element "item".

        I think however that the initial behavior is a bug. I can think of two different correct behaviors :

        • without this getter and setter, axis generates the same WSDL as this one
        • it should accept the SOAP message that is described in the generated WSDL

        I tried implementing the service with beans without accessor, using the client to the other service (therefore without "item" elements): the service accepted the message, but it wasn't correctly deserialized (I only got one item in the array).

        Show
        flashfr Julien Wajsberg added a comment - Quoted from the mailing list : "I have encountered this same situation with .NET. To fix the problem we had to make the array property a Java Bean Indexed Property. Your ArrayBean needs to have not only the simple getter and setter from simpleBeanArrayData but also a getter and setter by index, getSimpleBeanArrayData(int i) and setSimpleBeanArrayData(int i, SimpleBean bean). This keeps Axis from generating the ArrayOf_ type (which is not valid based on the WS-I spec)." This workaround works perfectly. The WSDL is slightly different, for the description of ArrayBean : <complexType name="ArrayBean"> <sequence> <element maxOccurs="unbounded" name="simpleBeanArrayData" nillable="true" type="tns1:SimpleBean"/> <element name="stringData" nillable="true" type="xsd:string"/> </sequence> </complexType> </schema> Here, there isn't any wrapping element "item". I think however that the initial behavior is a bug. I can think of two different correct behaviors : without this getter and setter, axis generates the same WSDL as this one it should accept the SOAP message that is described in the generated WSDL I tried implementing the service with beans without accessor, using the client to the other service (therefore without "item" elements): the service accepted the message, but it wasn't correctly deserialized (I only got one item in the array).
        Hide
        jongjinchoi Jongjin Choi added a comment -

        I remember that the wrapped/literal array problem has been arisen several times.

        When starting from WSDL, I think, Axis can handle both cases (ArrayOf_XXX or complex-type embeded unbounded element). The generated classes from WSDL which has ArrayOf_XXX complex type contains the class ArrayOf_XXX.java, which is needed in the deserialization and serialization process.

        When starting from Java class, the problem may occurs. The javabean which has no indexed properties is mapped to ArrayOf_XXX complexType in WSDL and the client will send the unexpected element 'item' to server in this case.

        I think that your option 1 would be right.
        Accroding to JAX-RPC 1.1 '5.4.1 XML Mapping', there is no standard mapping of indexed properties. If Axis depends on the indexed properties to handle the wrapped/literal array properly, it may hurt the JAX-RPC 1.1 compliance.

        The org.apache.axis.utils.BeanPropertyDescriptor depends on indexed properties for array handling. I patched it and got the same wsdl.

        The patch will be attached.

        Show
        jongjinchoi Jongjin Choi added a comment - I remember that the wrapped/literal array problem has been arisen several times. When starting from WSDL, I think, Axis can handle both cases (ArrayOf_XXX or complex-type embeded unbounded element). The generated classes from WSDL which has ArrayOf_XXX complex type contains the class ArrayOf_XXX.java, which is needed in the deserialization and serialization process. When starting from Java class, the problem may occurs. The javabean which has no indexed properties is mapped to ArrayOf_XXX complexType in WSDL and the client will send the unexpected element 'item' to server in this case. I think that your option 1 would be right. Accroding to JAX-RPC 1.1 '5.4.1 XML Mapping', there is no standard mapping of indexed properties. If Axis depends on the indexed properties to handle the wrapped/literal array properly, it may hurt the JAX-RPC 1.1 compliance. The org.apache.axis.utils.BeanPropertyDescriptor depends on indexed properties for array handling. I patched it and got the same wsdl. The patch will be attached.
        Hide
        jongjinchoi Jongjin Choi added a comment -

        The patch for org.apache.axis.utils.BeanPropertyDescriptor is attached.

        Show
        jongjinchoi Jongjin Choi added a comment - The patch for org.apache.axis.utils.BeanPropertyDescriptor is attached.
        Hide
        dims Davanum Srinivas added a comment -

        Can you please submit a test case? and have you run "ant clean all-tests"?

        thanks,
        dims

        Show
        dims Davanum Srinivas added a comment - Can you please submit a test case? and have you run "ant clean all-tests"? thanks, dims
        Hide
        jongjinchoi Jongjin Choi added a comment -

        Dims, I ran the all-tests and passed.
        I'll upload the testcase.

        A few comments...
        Had we some interop problem with .NET on this issue?
        I think we need more interop test with .NET on this.
        As far as I remember, The .NET interop of wrapped array was one of the customization points of Axis to my company's was TmaxSoft's JEUS last year.
        I will test it more.

        Show
        jongjinchoi Jongjin Choi added a comment - Dims, I ran the all-tests and passed. I'll upload the testcase. A few comments... Had we some interop problem with .NET on this issue? I think we need more interop test with .NET on this. As far as I remember, The .NET interop of wrapped array was one of the customization points of Axis to my company's was TmaxSoft's JEUS last year. I will test it more.
        Hide
        jongjinchoi Jongjin Choi added a comment -

        .NET client works well with the generated WSDL.

        Show
        jongjinchoi Jongjin Choi added a comment - .NET client works well with the generated WSDL.
        Hide
        flashfr Julien Wajsberg added a comment -

        This bug is still present in Axis 1.2RC3; do you plan to fix it before Axis 1.2 final ?

        Show
        flashfr Julien Wajsberg added a comment - This bug is still present in Axis 1.2RC3; do you plan to fix it before Axis 1.2 final ?
        Hide
        dims Davanum Srinivas added a comment -

        blocker??

        Show
        dims Davanum Srinivas added a comment - blocker??
        Hide
        flashfr Julien Wajsberg added a comment -

        Because :

        • it's a regression (IIRC in 1.2RC1 it worked)
        • there seems to be a working patch
        Show
        flashfr Julien Wajsberg added a comment - Because : it's a regression (IIRC in 1.2RC1 it worked) there seems to be a working patch
        Hide
        dims Davanum Srinivas added a comment -

        just tried latest CVS. works fine. only change was a typo in server-config.wsdd.

        <parameter name="allowedMethods" value="echoSimpleBeanArray echoArrayBean"/>

        thanks,
        dims

        Show
        dims Davanum Srinivas added a comment - just tried latest CVS. works fine. only change was a typo in server-config.wsdd. <parameter name="allowedMethods" value="echoSimpleBeanArray echoArrayBean"/> thanks, dims

          People

          • Assignee:
            Unassigned
            Reporter:
            flashfr Julien Wajsberg
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development