Re: [Fwd: Issue with ee/w2j/document/literal/MarshallTest]

[bu...@us.ibm.com]

FYI, here is Lance's response to our latest issue.  Just thought I'd pass
it on to the rest of you while I digest it.

Russell Butek
butek@us.ibm.com
---------------------- Forwarded by Russell Butek/Austin/IBM on 08/21/2002
12:38 PM ---------------------------





Lance Andersen <La...@sun.com> on 08/21/2002 12:17:02 PM

To:    Russell Butek/Austin/IBM@IBMUS
cc:

Subject:    Re: [Fwd: Issue with ee/w2j/document/literal/MarshallTest]




Hi Russell,

Sorry for the delay, but the test lead was out for a couple of days on
holiday and he and I and Rahul had to sync up.  The tests are fine.
Please see below.

I have enclosed the comments from Rahul based on our internal exchange
on the issue.

Regards,
Lance

 >
 > -------- Original Message --------
 > Subject: Issue with ee/w2j/document/literal/MarshallTest
 > Date: Wed, 7 Aug 2002 10:51:56 -0500
 > From: butek@us.ibm.com
 > Reply-To: axis-tck@xml.apache.org
 > To: Lance.Andersen@sun.com, axis-tck@xml.apache.org >
  >
 > We have another issue with ee/w2j/document/literal/MarshallTest. We'd
 > hate to throw this test out because it's a reasonable test, but a user
 > has discovered a problem that affects this test. Every operation follows
 > this pattern:
 >
 > <element name="echoString">
 > <complexType>
 > <sequence>
 > <element name="inputString" type="xsd:string" nillable="true"/>
 > </sequence>
 > </complexType></element>
 >
 > <message name="echoString">
 > <part name="body" element="s:echoString"/>
 > </message>
 > <message name="echoStringResponse">
 > <part name="return" element="s:echoString"/>
 > </message>
 >
 > <portType name="MarshallTest">
 > <operation name="echoString" parameterOrder="body" >
 > <input message="tns:echoString"/>
 > <output message="tns:echoStringResponse"/>
 > </operation>
 > </portType>
 >
 > The TCK expects this to map to:
 >
 > public String echoString(String inputString);

    Please note that in this example, there is a single unlisted
    message part in parameterOrder, so "return" is mapped to the
    return type and not OUT or INOUT parameter (and so not to
    Holders).

    So in this case, input message is bound to the method parameters
    using the doc-literal with wrapper mapping. The output message
    is mapped to the return type again using the doc/literal with
    wrapper mapping.

 > BUT THE SPEC DOES NOT SPECIFY THIS MAPPING! Another possibility,
  > and one which we prefer, is:

    Effectively in "doc/literal with wrapper" case, there is a single
    message part for input and output each.  The parameterOrder does
    not apply to the literal elements within the single message part
    for either input/output messages. Also, mapping to IN/OUT/INOUT
    elements is based on message parts not what is inside the message
    part. Please see section 4.3.4 in the spec.

 > public void echoString(StringHolder inputString);

    Based on the above description, section 4.3.4 in JAX-RPC spec and
    chapter 6 (that specifies doc-literal with wrapper mapping), the
    above form of mapping seems incorrect. The output message part
    maps to a return type.

 > The problem doesn't appear in this simple example, but it does if you
 > have more than one element in the complexType:
 >
 > <element name="echoString">
 > <complexType>
 > <sequence>
 > <element name="inputString" type="xsd:string" nillable="true"/>
 > <element name="anotherString" type="xsd:string" nillable="true"/>
 > </sequence>
 > </complexType></element>
 >
 > If we followed our preference, this would map to:
 >
 > public void echoString(StringHolder inputString, StringHolder
 > anotherString);

    The same logic applies here.

    The output message part (as the single unlisted message part in
    the parameter order) maps to a return type for the method. Since
    Java does not support multiple return types, the output message
    part (being a complexType) needs to be mapped to a JavaBean. So
    the method signature is:

    public EchoString echoString(String inputString,
          String anotherString);

    This what TCK tests for based on the spec.

 > If we followed what we believe is the TCK model, we would end up with:
 >
 > public String echoString(String inputString, String anotherString,
 > StringHolder anotherString);

   The single output message part is the return type.

 > This would not compile. I'm rather puzzled about what the RI actually
 > does, though:
 >
 > public EchoString echoString(String inputString, String anotherString);
 >
 > Where does the EchoString class come from? The spec certainly doesn't
 > detail THIS thing!

    EchoString is the mapping of output message part, which is an element
    of type complexType.