Toll Free: 888-576-4102
International: 484-630-3398
Passcode: 75258
Russell Butek
[EMAIL PROTECTED]
To: Russell Butek/Austin/[EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: Re: JAX-RPC TCK and wrapped doc/lit
[EMAIL PROTECTED] wrote:
> Rahul,
>
> We received your doc/lit comments at about the same time I sent out the
> note below. I don't believe your comments address these points.
>
> AXIS has a weekly telecon on Wednesdays, 8-9 AM. Might there be a chance
> that you (and Lance?) could join us for that hour? We might save
> ourselves some time if we could discuss this directly rather than
> swapping email every few days. If you can't make that time, then we look
> forward to your email response.
- Can you send me the teleconf details. I will try my best to attend.
Is it 8-9am PDT?
Regards,
Rahul
>
> To: [EMAIL PROTECTED]
> cc:
> Subject: Re: apache jaxrpc issues
>
>
>
> I haven't heard anything all week on this. I just want to keep this
> discussion going. Here is a list of reasons we have that the doc/lit
> test in the TCK is invalid (#2 should be enouh to justify our position
> that the doc/lit tests as they stand today are invalid, but it's not our
> only point).
>
> 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] <mailto:[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] <mailto:[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]
> <mailto:[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]
> <mailto:[EMAIL PROTECTED]>Sun Microsystems Inc.
> phone: (781) 442-2037
> 1 Network Drive, UBUR02-301 fax : (781) 442-1610
> Burlington, MA 01803
>
>
>
>
