Issue with ee/w2j/document/literal/MarshallTest

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

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);

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

public void echoString(StringHolder inputString);

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);

If we followed what we believe is the TCK model, we would end up with:

public String echoString(String inputString, String anotherString,
StringHolder anotherString);

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!

A simple change to the test would avoid this problem.  Instead of reusing
the "echoString" element, the input and output messages should refer to
different elements.  The portType could remain the same.  The types and
messages would look like:

<element name="echoString">
<complexType>
  <sequence>
    <element name="inputString" type="xsd:string" nillable="true"/>
  </sequence>
</complexType></element>
<element name="echoStringResponse">
<complexType>
  <sequence>
    <element name="outputString" 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:echoStringResponse"/>
</message>

Since JAX-RPC does not specify the mapping for doc/lit input/output
parameters with the same name, we think the TCK should change this test as
I suggested above so it models something that the spec DOES specify.

Russell Butek
butek@us.ibm.com

Re: Issue with ee/w2j/document/literal/MarshallTest

[Lance Andersen <La...@sun.com>]

I am going to have to follow-up with Rahul on this for you as I thought 
we were all set with these tests. Stay tuned :-)

butek@us.ibm.com wrote:

> 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);
>
> BUT THE SPEC DOES NOT SPECIFY THIS MAPPING! Another possibility, and 
> one which we prefer, is:
>
> public void echoString(StringHolder inputString);
>
> 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);
>
> If we followed what we believe is the TCK model, we would end up with:
>
> public String echoString(String inputString, String anotherString, 
> StringHolder anotherString);
>
> 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!
>
> A simple change to the test would avoid this problem. Instead of 
> reusing the "echoString" element, the input and output messages should 
> refer to different elements. The portType could remain the same. The 
> types and messages would look like:
>
> <element name="echoString">
> <complexType>
> <sequence>
> <element name="inputString" type="xsd:string" nillable="true"/>
> </sequence>
> </complexType></element>
> <element name="echoStringResponse">
> <complexType>
> <sequence>
> <element name="outputString" 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:echoStringResponse"/>
> </message>
>
> Since JAX-RPC does not specify the mapping for doc/lit input/output 
> parameters with the same name, we think the TCK should change this 
> test as I suggested above so it models something that the spec DOES 
> specify.
>
> Russell Butek
> butek@us.ibm.com