1. The example from the TCK shown below does not follow the example in the spec. In the JAX-RPC example (and in .NET) the element name is the same as the operation name; in the TCK it is not. (from my original note)
2. JAX-RPC section 6.4.3 shows TWO possible Java mappings for the given WSDL. Therefore the TCK cannot mandate one. (from Rich's response)
3. Once upon a time JAX-RPC said that, if the binding info affects the signatures of the SEI methods, then the name of the SEI is derived from the name of the binding instead of the portType. JAX-RPC no longer says that. The implication of the absence of that statement is that the SEI will be the same no matter the binding. Consider a WSDL that contains the following:
- a portType named "PT"
- an rpc/encoded binding for "PT"
- a doc/lit binding for "PT"
The name of the SEI for BOTH these bindings will be derived from the portType "PT". Unless the SEI is the same for both, we have an interface clash. Therefore, the fact that a binding is doc/lit must not affect the SEI.
Russell Butek
[EMAIL PROTECTED]
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: apache jaxrpc issues
Sam,
I need Rahul to comment on Rich's concern. �Let us give him a little time and then I will follow-up again.
Regards,
Lance
[EMAIL PROTECTED] wrote:
Lance/Rahul: Additional information on wrapped/doc lit, from Rich Scheurle....
- JSR 101 v1.0 clearly indicates that the parameters of the signature are
obtained from the message parts. �This information is used to determine
order, holders, etc. �There is no mention of unwrapping an part's element=
attribute to populate the parameter list.
What if the complexType TradePriceRequest contained two elements
(tickerSymbol and companyName) ? �Would the TCK expect the following
signature:
public float getLastTradePrice(String body, String body) throws
RemoteException; �// NOTE Two Parameters with the same name!
Axis-dev'ers: below is outlook on schedule, process, etc.
Everyone: what is the right process for Apache to approach the Expert Group? - Sam Ruby
---------------------- Forwarded by Sam Ruby/Raleigh/IBM on 07/09/2002 01:40 PM ---------------------------
To: Sam Ruby/Raleigh/[EMAIL PROTECTED]
cc:
Subject: Re: apache jaxrpc issues
Hi Sam,
Yes it was excellent thank you. �Could have used a bit more time but
that is always the case after a holiday. �How was your 4th? �Hopefully
you took some time off as well.
Yes I am getting traffic on the list.
For the content-id header, if either you or dims could fill out the
template, that would be ideal. �I really need to know which tests and
the section(s) of the spec which are in question. This just in, dims
just sent me the challenge (and called me).... so I will take a look now.
We are going to do a patch for jaxrpc based on the issues that you had
raised previously and I have responded to. � �If you have other issues,
please forward when you have a chance so that we can review. �My goal is
to address any issues that we feel need patched. � Issues that do not
get patched and we concur with, will be excluded. �I don't have an exact
ETA for the patch as I want to see what other issues you have that we
can address at the same time.
I also followed up with Rahul again on the following issue. �He believes
the tests are correct in their design. �His comments follow the issue
description and your team's comments. �I think if there is still a
concern, that it should be revisited in the Expert Group regarding the
spec requirements. �Please let me know your thoughts.
>>>>
>>>> wrapped doc/lit
>>>> The TCK is expecting wrapped doc/lit signatures (like what .NET
>>>> does). �We do not believe it should.
>>>>
>>>> Here's a WSDL snippet from the TCK's stock quote test:
>>>>
>>>> <element name="TradePriceRequest">
>>>> �<complexType>
>>>> � �<sequence>
>>>> � � �<element name="tickerSymbol" type="string"/>
>>>> � �</sequence>
>>>> �</complexType>
>>>> </element>
>>>> <element name="TradePrice">
>>>> �<complexType>
>>>> � �<sequence>
>>>> � � �<element name="price" type="float"/>
>>>> � �</sequence>
>>>> �</complexType>
>>>> </element>
>>>>
>>>> <message name="GetLastTradePriceInput">
>>>> �<part name="body" element="xsd1:TradePriceRequest"/>
>>>> </message>
>>>>
>>>> <message name="GetLastTradePriceOutput">
>>>> �<part name="body" element="xsd1:TradePrice"/>
>>>> </message>
>>>>
>>>> <portType name="StockQuotePortType">
>>>> �<operation name="GetLastTradePrice">
>>>> � �<input message="tns:GetLastTradePriceInput"/>
>>>> � �<output message="tns:GetLastTradePriceOutput"/>
>>>> �</operation>
>>>> </portType>
>>>>
>>>> (the binding for this WSDL is doc/lit). �This is ALMOST like .NET's
>>>> doc/lit style. �But it's not quite. �AXIS generates:
>>>>
>>>> public TradePrice getLastTradePrice(TradePriceRequest body) throws
>>>> RemoteException;
>>>>
>>>> Unfortunately the TCK expects the following signature:
>>>>
>>>> public float getLastTradePrice(String body) throws RemoteException;
>>>>
>>>> We don't read anything in JAX-RPC that allows or requires this
>>>> signature, so we do not believe the TCK should expect this signature.
>>>
>>>
>>>
>>>
>>> � Doc/literal with wrapper is required as per 6.2. There is also an
>>> � example in section 6.4.
>>>
>>> � So this is not an issue.
>>
>>
>>
>>
>>
>> This is not an issue. I am expecting what the spec says regarding
>> doc/literal.
>>
>>
<rjs>
You are looking at the first mapping in section 6.4.3. Read futher in
the same section. "Another possible mapping of the doExample method is
as follows. In this example, the part named body in the DoExample
message is mapped as xsd:complexType:
DoExampleResponse doExample(DoExample body) throws
java.rmi.RemoteException;"
This is the kind of mapping that Axis uses. Also note that the last
paragraph of 6.4.1 indicates that the mapping is specific to a JAX-RPC
implementation and is not portable. So this is not a valid test.
</rjs>
As per specification, the section 6.2 requires support for wrapper
element for doc/literal style of operations. This is used as part
of the mapping. Please see details in this section 6.2.
--- rahul's comments ----
- The section 6.4.1 specifies mapping of literal message parts. In case
of standard required set of XML/Java types, use of doc/literal wrapper
style mapping is required as per the section 6.2. The spec can clarify
this further (in maintenance release) if this is not entirely clear.
- For extended (beyond the standard) set of XSD types, the mapping
to SOAPElement is the required mapping (per section 6.4.1). Spec also
allows implementation specific data binding (in absence of JAXB) but
the latter is optional.
- The section 6.4.2 provides examples about requirements in the section
6.2 and 6.4.1. The intent of examples is to be illustrative. The
requirements are still derived from sections 6.2 and 6.4.1.
- So JAX-RPC requires doc-literal with wrapper style of mapping for
operations based on the standard required set of XML schema types.
This is how TCK tests this case. So TCK tests are okay.
- Beyond the standard set, mapping to SOAPElement is required with any
any implementation-specific data binding being optional. This with
additional requirement that a portable application should not rely on
any implementation specific data binding in the XML/WSDL->Java
mapping.
Regards,
Lance
[EMAIL PROTECTED] wrote:
> I trust you had a nice holiday?
>
> Are you receiving axis-tck mailing list traffic yet?
>
> I'd like to start discussions with an issue concerning when the
> "Content-Id" headers (CID) for attachment parts are created. As near
> as we can tell the SAAJ TCK is dependent on the precise timing of when
> these ids are created by the TCK.
>
> How do we proceed?
>
> - Sam Ruby
--
Lance Andersen � � � � � � � � � � � email: [EMAIL PROTECTED]
Sun Microsystems Inc. � � � � � � � �phone: (781) 442-2037
1 Network Drive, UBUR02-301 � � � � �fax �: (781) 442-1610
Burlington, MA 01803
--
Lance Andersen email: [EMAIL PROTECTED]Sun Microsystems Inc. phone: (781) 442-2037
1 Network Drive, UBUR02-301 fax : (781) 442-1610
Burlington, MA 01803
