Uploaded image for project: 'Apache Flex'
  1. Apache Flex
  2. FLEX-22624

Invalid message generated for doc literal wrapped methods with complex arguments

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Cannot Reproduce
    • Adobe Flex SDK 4.5 (Release)
    • None
    • RPC: WebService
    • None
    • Affected OS(s): All OS Platforms
      Affected OS(s): All OS Platforms
      Language Found: English

    Description

      New Reproduce steps:

      1. use the attached test app
      2. set up a wsdl file(using bookServiceDocLitWrap.xml, make sure the schemaLocation="bookServiceDocLitWrapElements.xml"
      3. try to generate as classes in flash builder by clicking menu

      Data->Connect to Web Service ..., use the wsdl in step2).

      4. enable network monitor in flash builder when debugging the test app

      5. check soap request:
      ->SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <SOAP-ENV:Body>
      <tns:addBook xmlns:tns="http://service.test.com/">
      <arg0>
      <author>test</author>
      <bookid>1234</bookid>
      <name>this is a test</name>
      <price>18.88</price>
      </arg0>
      </tns:addBook>
      </SOAP-ENV:Body></SOAP-ENV:Envelope>

      so I see the soaprequest is expected now.

      Steps to reproduce:
      1. Create a java web service that uses doc literal wrapped binding
      2. Create a flex 4 project (or flex 3.4.1 as the code appears to be exactly the same and same problem is encountered)
      3. Attempt to bind to web service call that expects a complex object.

      Actual Results:
      The code attempts to find the properties of the complex type argument on the wrapper object that flex generates for the web service rather than the argument itself. For example, flex generates the invalid:

      <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <SOAP-ENV:Body>
      <tns:addBook xmlns:tns="http://service.test.com/">
      <arg0/>
      </tns:addBook>
      </SOAP-ENV:Body>
      </SOAP-ENV:Envelope>

      In this example, XMLEncoder.as encodeComplexType (line 767 of sdk 4.0.0) is attempting to encode the complex type Book (which has bookid, price, author, and name children elements). It passes the AddBook object down rather than the embedded argument (arg0 in this case). Not sure if that's the spot that needs to change, but seems suspect since the subsequent methods will eventually call resolveNamedProperty with the parent set to the AddBook instance and the value set to, for example, 'author'.

      Also, I would think that since the wsdl specifies that various book properties are required that an exception would be thrown due to the above invalid request (e.g. - no bookid). However, the encodeComplexType function just ignores the fact that (in this example) a require sequence was not satisfied (encodeSequence call returns false, but encodeComplexType does nothing with this return value).

      Expected Results:
      The service call will be made with the specified values. For example, generate the following SOAP request:

      <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <SOAP-ENV:Body>
      <ns1:addBook xmlns:ns1="http://service.test.com/">
      <arg0>
      <author>test</author>
      <bookid>2934</bookid>
      <name>A Test Book Name</name>
      <price>1.24</price>
      </arg0>
      </ns1:addBook>
      </SOAP-ENV:Body>
      </SOAP-ENV:Envelope>

      Workaround (if any):
      None - other than not using non-primitives as web service arguments, which really isn't a workaround...

      Attachments

        Activity

          People

            adobejira Adobe JIRA
            adobejira Adobe JIRA
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: