Re: Return type

[Rahul Sharma]

  I have been trying to follow "ReturnType" discussion. Here are a few
  points of clarifications.
  o Call implementation derives metadata for operation invocation from
    a combination of 1) WSDL document, 2) TypeMappingRegistry, 3) add-
    Parameter/setReturnType, and 4) Reflection of Java parameters to the
    Call.invoke() method. The way this information is combined within
    Call implementation is implementation specific.
  o DII Call supports both cases A) there is a WSDL document accessible
    to the Call implementation B) there is no WSDL. So in case (B), Call
    implementation has to deduce the required invocation metadata from a
    combination of 2, 3 and 4, While in case (B), Call implementation
    deduces the required invocation metadata using 1, 2 and 4. In case
    B, there is no need to invoke addParameter/setReturnType.
  o Call.invoke method throws exception if there is incorrect
    specification of the metadata or if there is any incorrect
    configuration. A developer can end up with this by incorrectly
    invoking addParameter/setReturnType or incorrectly configuring
    TypeMappingRegistry.
  o The method isPARSR is programmatic way to find out whether (for a
    specific operation name), Call implementation has the necessary
    metadata or not. The two derived sub-cases are:
    - If Call implementation requires that addParameter/setReturnType
      be called to provide the metadata, isPARSR is required to return
      true. For example, this may be the case if there is no WSDL
      metadata accessible to the Call.
    - If Call implementation does not require addParameter/setReturnType
      to be invoked (in the case, when Call has the necessary metadata
      available), then isPARSR is required to return false.
    As I explained, how isPARSR boolean flag is arrived at is specific
    to the Call implementation. It is using implementation's knowledge
    of the required Call metadata.
  o JAX-RPC considers case of partial mix--where developer calls a
    few addParameters/setReturnType, and ignores others and assumes
    that Call impl will do the necessary magic by deducing metadata--
    as out of scope. The model is to invoke either a) All addParameters/
    setReturnType or  b) None. In case (a), setReturnType is optional
    if method return type (in terms of Java mapping) is void.
  o In terms of the programming model, it is not a good practice to
    switch based on the isPARSR method using if-then-else condition.
    It is okay to test at the TCK level as both cases of invoking
    addParameter/SetReturnType and no invocation of addParameter/
    setReturnType are required by the spec.
    In the normal programming model, developer should develop using
    presumption about invoking ALL addParameter/setReturnType v/s
    No invocation of addParameter/setReturnType. Since the developer
    knows about providing WSDL as part of the Call creation from
    Service and also configuration of the TypeMappingRegistry, this
    presumtion at the development time is justified modulo runtime
    exceptions raised for any incorrect configuration or missing
    metadata.
    The exceptions from setReturnType/addParameter enable developer
    to avoid the partial mix usecase. Finally, the Call.invoke method
    also throws exception for any incorrect configuration or metadata
    specification.
  BTW we had this feature to support Axis usecase of having minimalistic
  programmatic specification of the Call metadata. The only restriction
  in JAX-RPC is to avoid partial metadata specification and relying on
  Call impl to deduce the rest. The latter partial mix is error-prone
  and not good for portable web service clients.
  Regards,
  Rahul
[EMAIL PROTECTED] wrote:
Kim,
Just to be clear, you wrote:
Dug's proposal for is...Required to always return false anyway means to 
me that the runtime can always figure out the answer and that 
addParameter/setReturnType never need to be called, and I, as a client, 
wouldn't, since I would have no idea what it means to do so.

That's not quite what I want - if I said that I mistyped. First, I don't 
think isPARSR() is needed at all and I would love it if it just went 
away. If people want to know if a Call object has all of the info it 
needs they should just ask for the returnType or the list of params and 
if they get back NULL then it hasn't been filled in. But as long as that 
method does exist I would prefer if it were used to know if the Call 
object was "prefilled" or not. If when creating the Call object the 
system had WSDL and prefilled the Call object then isPARSR() would 
return false - because all of the data is already there. The user can 
still change that data if they want thru addParam() or setReturnType() 
but then they would be overriding the WSDL - which is a good option to 
have (IMO). If the Call object was created w/o WSDL then isPARSR() would 
return true - meaning that if you want the system to know about the 
types then you need to do it manually. This is very different than "an 
exception is going to be thrown if you don't call addParam() or 
setReturnType()". So, yes, lets get isPARSR() better defined - and I 
vote for making it a "is the Call object prefilled for me" flag rather 
than a "will an exception be thrown" flag.
-Dug

Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: Return type

My comments (sent 10/24/2001 to JAXRPC-INTEREST about the 0.4 draft) 
were on a different point, but were intended to clarify when an 
exception would be thrown with respect to addParameter and invoke calls:

Issue:
JAX-RPC, section 8.2.3, says "...The Call implementation class 
determines the types and modes of the parameters in an implementation 
specific manner. For example, a Call implementation class can determine 
parameter types by using the Java reflection and configured type mapping 
registry. In this case, the client code is not required to call any 
addParameter and setReturnType methods before calling the invoke method."

      I think more constraints are required in this case to ensure that
      Java objects are mapped to SOAP parameters having the correct
      name. In the case of there being no addParameter calls, how does
      the JAXRPC runtime map the Java objects passed in the 'params'
      array to the corresponding parameter names in the SOAP Request or
Response?
      If there are zero on one parameters, it's trivial. If there are
      multiple parameters and they are all of disjoint types, you can
      match up the Java type with the XML type. But if there are
      multiple parameters having the same type (say 2 String objects in
      the params array) how to you match them up to the proper SOAP
parameter names?
      If parameterOrder is present, the JAXRPC runtime might assume that
      it represents the order of parameters in the params array, but is
      isn't specified that it does. (As a matter of fact, neither is it
      said that the order that addParameter calls are made corresponds
      to the position of the corresponding value in the params array,
      but it's pretty implicit). But what should be done in the case
where this is no parameterOrder?
      On a slightly different point, the interpretation of the params
      array is underspecified in all cases. What exactly is the
      relationship between the WSDL message parts, addParameter calls
      (or the absence of them) and the indices of Java objects in the
params array?
Proposed Resolution:
      3) JAX-RPC, section 8.2.3, says "...The Call implementation class
      determines the types and modes of the parameters in an
      implementation specific manner. For example, a Call implementation
      class can determine parameter types by using the Java reflection
      and configured type mapping registry. In this case, the client
      code is not required to call any addParameter and setReturnType
methods before calling the invoke method."
      I think more constraints are required in this case to ensure that
      Java objects are mapped to SOAP parameters having the correct
      name. In the case of there being no addParameter calls, how does
      the JAXRPC runtime map the Java objects passed in the 'params'
      array to the corresponding parameter names in the SOAP Request or
Response?
      If there are zero on one parameters, it's trivial. If there are
      multiple parameters and they are all of disjoint types, you can
      match up the Java type with the XML type. But if there are
      multiple parameters having the same type (say 2 String objects in
      the params array) how to you match them up to the proper SOAP
parameter names?
      If parameterOrder is present, the JAXRPC runtime might assume that
      it represents the order of parameters in the params array, but is
      isn't specified that it does. (As a matter of fact, neither is it
      said that the order that addParameter calls are made corresponds
      to the position of the corresponding value in the params array,
      but it's pretty implicit). But what should be done in the case
where this is no parameterOrder?
      On a slightly different point, the interpretation of the params
      array is underspecified in all cases. What exactly is the
      relationship between the WSDL message parts, addParameter calls
      (or the absence of them) and the indices of Java objects in the
params array?
Comment
It was my intention in the remarks above that the runtime analyze the 
(WSDL,reflective) information available about each operation, and on a 
per-operation basis indicate whether addParameter/setReturnType calls 
were required. For example, a void operation with no parameters would 
always return false.
Dug's proposal for is...Required to always return false anyway means to 
me that the runtime can always figure out the answer and that 
addParameter/setReturnType never need to be called, and I, as a client, 
wouldn't, since I would have no idea what it means to do so.

I agree with Dug that the behavior is underspecified. I disagree with 
Dug that it's safe to always return false, since the assumptions in the 
spec would lead most clients to never call addParameter or setReturnType.

Kim Rochat, IBM WebSphere Foundation Development, Austin, Texas, USA
tl 793-, voice 512-823-8792, fax 512-838-1032, [EMAIL PROTECTED]
____________________________________________________________
[IMAGE]Russell Butek/Austin/[EMAIL PROTECTED]

[IMAGE]
      [IMAGE]
      Russell Butek/Austin/[EMAIL PROTECTED]
      07/09/2002 08:31 AM
      Please respond to axis-tck
            [IMAGE]
            To: [EMAIL PROTECTED]
            cc:
            Subject: Re: Return type
Before I go on, Dug, could you answer a question of mine? Why can't you 
just call setReturnType?

There's a lot more to this problem than isParameterAndReturnSpecRequired 
(yuck, ptew, ptew!). This is the wrong forum to discuss changing the 
spec, but if we can show the TCK folks that there is ambiguity, then 
perhaps we can convince them to remove/change some tests.

A few months back, Kim Rochat sent to the EG a detailed interpretation 
of parameters/return type. None of his text ever made it into the spec. 
Let me see whether he still has that note. It might be a good basis for 
defining the issue to the TCK folks.

Russell Butek
[EMAIL PROTECTED]
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: Return type

ok - thanks Lance.
Sam - can we get this raised as an issue?
-Dug
To: [EMAIL PROTECTED], Doug Davis/Raleigh/[EMAIL PROTECTED]
cc:
Subject: Re: Return type

I have attached the specification.
For apache TCK issues, the contacts I been given so far are:
jaxrpc  - Sam
saaj      - Dims
When the apache team starts working with a new tck, the lead needs to 
inform me, copying sam as he is our primary point of contact.   This 
will allow me to know who to expect queries from.

Regards,
Lance
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> wrote:
What about non-SAAJ issues?
-Dug
ps. I just joined this list so I don't think I saw your template - can 
you send it to me at [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>.

Please respond to [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
cc:
Subject: Re: Return type

Hi Dug,
Please see my previous email.  For SAAJ TCK issues for apache, they 
should come to me from your TCK lead for SAAJ which I believe is Dims. 
The template that I provided needs to be filled out with the necessary 
info.   This will help us witht he evaluation process as it should give 
us the details we need.

Regards,
Lance
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> wrote:
I believe this test is invalid since I can't find anyplace in the spec 
where it says an exception MUST be thrown in that case. The closest it 
comes it to say an exception _may_ be thrown when isPARSR() returns 
'false' and someone calls addParameter (notice "may" not "MUST") but 
even that's by the addParam call not the invoke. One of the problems I 
have with this entire thing is that the spec doesn't actually define 
that the heck isPARSR() is for. Yes you can infer what it means by the 
name but that's not good enough because w/o the text to explain it, it 
leaves it open to interpretation. I look at that method as a means for 
someone to know if the Call object is prefilled or not - hence I have to 
fill it in myself since the system won't do it for me. Other people 
might view it differently but if the spec isn't clear on it then I don't 
think its valid for the TCK to test for it. What's the proper way to get 
this issue to the TCK guys?
-Dug

ps. Yes we all hate Notes just as much as you do. :-)
To: "'[EMAIL PROTECTED]'" <mailto:[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]>, Doug 
Davis/Raleigh/[EMAIL PROTECTED]
cc:
Subject: RE: Return type


 
Just to be crystal clear:
 
The TCK has a test which says basically:
 
------------
if (!call.isParamAndReturnSpecRequired())
    endTest();
 
call.addParameter(...);
// don't set return type
 
try
    call.invoke(...);
} catch (Exception e) {
    // success, it barfed!
}
 
fail("No Exception thrown");
-------------
 
?
 
--Glen
 
P.S.  What the heck is going on with the fonts below?  I hate 
non-plain-text email...
 
 
 -----Original Message-----
From: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> [mailto:[EMAIL PROTECTED]
Sent: Monday, July 08, 2002 3:54 PM
To: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Subject: RE: Return type

The spec says
A. if you must call addParameter/setReturnType, then iPARSR returns true
B. if the call object has been prefilled, iPARSR returns false.
This IMPLIES
I. If iPARSR returns true, you must call addParameter/setReturnType
II. If iPARSR returns false, you can't call addParameter/setReturnType
These aren't quite the same thing, but this IS how most folks are going 
to treat it. This is how the TCK treats it. If you really think this is 
an issue, we should bring it up with the JAX-RPC folks and try to get 
JAX-RPC 2.0 to address it. I personally don't think we can touch it now. 
We MUST pass the TCK.

By the way, I've forgotten. Why is this such an issue for you? Why can't 
you just add a call to setReturnType?

Russell Butek
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
To: Russell Butek/Austin/[EMAIL PROTECTED]
cc: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
From: Doug Davis/Raleigh/[EMAIL PROTECTED]
Subject: RE: Return type Russell Butek 
<Notes:///862563BF00528B1D/A24CF79FA927570285256356005827C4/A6A84EDA53FD205585256BF000693016>

Let me try a different way - the assumption is that if isPARSR() returns 
"true" then an exception MUST be thrown if addParam or setReturnType is 
not called. Where does it say that in the spec? Ignore what that 
gawd-awful method's name is - for all I care about it can be called 
"foo" - where in the description of that method does it say "if this 
method returns 'true' then an exception MUST be thrown if setReturnType 
is not called"? If I just missed it then there's no point in discussing 
it - you're right. If however it doesn't actually say that then there's 
an open issue. There are two ways to look at the isPARSR() method - (1) 
view it as an indicator of whether or not an exception is going to be 
thrown if addParam/setReturnType is not called - (2) is to look at it as 
an informational method that tells you whether or not the Call object 
was prefilled for you. You're looking at it as #1, I want to look at 
like #2.
-Dug

To: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
cc: Doug Davis/Raleigh/[EMAIL PROTECTED]
From: Russell Butek/Austin/[EMAIL PROTECTED]
Subject: RE: Return type
Glen, the issue Dug brought up on axis-dev is related to the TCK. There 
are a number of TCK tests that have code essentially like the code I 
presented on axis-dev:

/jaxrpctck/src/com/sun/ts/tests/jaxrpc/api/javax_xml_rpc/Call/Client.java
/jaxrpctck/src/com/sun/ts/tests/jaxrpc/api/javax_xml_rpc/Service/Client.java
/jaxrpctck/src/com/sun/ts/tests/jaxrpc/ee/j2w/simpletest/Client.java
/jaxrpctck/src/com/sun/ts/tests/jaxrpc/ee/w2j/rpc/encoded/simpletest/Client.java
If we implement Doug's suggestion, we'll fail the TCK.
(Dug, don't know whether you're on axis-tck. Let's move this discussion 
here and keep it off of axis-dev as that's too public.)

Russell Butek
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
---------------------- Forwarded by Russell Butek/Austin/IBM on 
07/08/2002 11:44 AM ---------------------------

Please respond to axis-dev@xml.apache.org <mailto:axis-dev@xml.apache.org>
To: axis-dev@xml.apache.org <mailto:axis-dev@xml.apache.org>
cc:
Subject: RE: Return type

The following code, which the spec implies should work, would not:
Call call = ...;
if (call.isParameterAndReturnSpecRequired())
// The call object needs the info
call.addParameter(...);
call.setReturnType(...);
}
else {
// I assume the call object has the info, so don't do anything
}
call.invoke(...);
Russell Butek
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Please respond to axis-dev@xml.apache.org <mailto:axis-dev@xml.apache.org>
To: "'axis-dev@xml.apache.org'" <mailto:[EMAIL PROTECTED]> 
<axis-dev@xml.apache.org> <mailto:axis-dev@xml.apache.org>
cc:
Subject: RE: Return type


While your point is well-taken, Russell, all Doug is suggesting is that 
Axis allow you to be more lenient.  What code can you imagine "not 
porting to Axis" if we make this possible (as it used to be before we 
JAX-RPCified)?
 
--Glen
-----Original Message-----
From: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> [mailto:[EMAIL PROTECTED]
Sent: Monday, July 08, 2002 12:19 PM
To: axis-dev@xml.apache.org <mailto:axis-dev@xml.apache.org>
Subject: RE: Return type

The spec says:
"In terms of the specification of parameters and return value, a Call 
implementation class
is required to support the following cases:

â The Call implementation class determines the types of the parameters 
and return
value from the invocation of addParameter and setReturnType methods in the
client code. The method isParameterAndReturnSpecRequired is required to 
return
true in this case.

â The Call implementation class determines the types and modes of the 
parameters in
an implementation specific manner. For example, a Call implementation 
class may
determine parameter types by using Java reflection on parameters, using WSDL
service description and the configured type mapping registry. In this 
case, the client
code is not required to invoke any addParameter and setReturnType methods
before calling the invoke method. The method 
isParameterAndReturnSpec-Required
is required to return false in this case. The methods addParameter,
removeAllParameters and setReturnType may throw JAXRPCException if invoked
in this case."

This IMPLIES that Call determines the types of parameters and return 
EITHER by addParameter/setReturnType OR some implementation specific 
manner. What you're saying is that, for AXIS, addParameter/setReturnType 
are part of the implementation specific manner. I doubt most folks would 
read it that way. Code written to assume an exclusive or use of 
addParameter/setReturnType will not port to AXIS code if we do what you 
suggest.

Russell Butek
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Please respond to axis-dev@xml.apache.org <mailto:axis-dev@xml.apache.org>
To: axis-dev@xml.apache.org <mailto:axis-dev@xml.apache.org>
cc:
Subject: RE: Return type

But the spec doesn't mandate that isParameterAndReturnSpecRequired MUST 
return "true". In fact, it says that we can have an implementation 
specific way of doing it and if so it is legal for it to return "false" 
in ALL cases - which is basically what I'm suggesting. We've been 
through this before - just because isParameterAndReturnSpecRequired 
returns "false" does not mean you can't still call addParameter - the 
spec says that method _may_ throw an exception not MUST throw an 
exception. So, let's have it return "false" and make our lives easier.
-Dug

Please respond to axis-dev@xml.apache.org <mailto:axis-dev@xml.apache.org>
To: axis-dev@xml.apache.org <mailto:axis-dev@xml.apache.org>
cc:
Subject: RE: Return type

Dug, it seems to me the name of the method itself - 
isParameterAndReturnSpecRequired - tells us that you MUST specify the 
return as well as parameters.

Russell Butek
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Please respond to axis-dev@xml.apache.org <mailto:axis-dev@xml.apache.org>
To: axis-dev@xml.apache.org <mailto:axis-dev@xml.apache.org>
cc:
Subject: RE: Return type

Glen?
If no one can show me where in the spec it says this
I'd like to remove the check(s).
-Dug
---------------------- Forwarded by Doug Davis/Raleigh/IBM on 07/04/2002 
06:51 AM ---------------------------

To: axis-dev@xml.apache.org <mailto:axis-dev@xml.apache.org>
cc:
From: Doug Davis/Raleigh/[EMAIL PROTECTED]
Subject: RE: Return type Doug Davis 
<Notes:///852562810063750E/03130DD61C5BDA0A8525635600580590/D992F9997328B21385256BEA00595690>

Can you point me to where in the spec it says that?
I can't find anyplace in the spec where it says a return
type is required. In fact it does talk about "implementation
specific manner" of when talking about what to do with
addParam/setReturn types so why can't we just make
this "our implementation manner"?
-Dug
Please respond to axis-dev@xml.apache.org <mailto:axis-dev@xml.apache.org>
To: "'axis-dev@xml.apache.org'" <mailto:[EMAIL PROTECTED]> 
<axis-dev@xml.apache.org> <mailto:axis-dev@xml.apache.org>
cc:
Subject: RE: Return type


I agree with you, Doug.  This is a JAX-RPCism.  Personally, I think you 
should be able to specify as much or as little metadata as you want, and 
you takes your chances (for instance, there'll either be xsi:types on 
the return or not), but the other JAX-RPC experts disagreed.
 
--Glen
-----Original Message-----
From: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 02, 2002 10:07 AM
To: axis-dev@xml.apache.org <mailto:axis-dev@xml.apache.org>
Subject: Return type


If I create a Service object and a Call object w/o any WSDL
and then call addParameter() I get an error saying that
I _must_ also specify a return type. Why do we require this?
If the return type is so important then it should not be triggered
based on me calling addParameter it should just be required
in all cases. With the current logic if I have a no-arg method
I won't get this error, but if I have a one-arg method I will. This
inconsistency isn't good. Personally, I'd prefer if we didn't
require it at all. Can someone explain the logic here?
-Dug
[IMAGE]
[IMAGE]
[IMAGE]




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


1. Licensee Name:
2. TCK and version:
3. SDK version:
4. Priority (low, medium, high, ):
5. Specification Reference:
      - Spec Name:
      - Spec version
      - Spec date:
      - Page/Section to reference:
6. Test Name(s):
7. Problem Description: