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] |
Russell Butek/Austin/[EMAIL PROTECTED] 07/09/2002 08:31 AM Please respond to axis-tck |
To: [EMAIL PROTECTED] cc: Subject: Re: Return type |
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] 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].
Please respond to [EMAIL PROTECTED]
To: [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] 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]'" <[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]]
Sent: Monday, July 08, 2002 3:54 PM
To: [EMAIL PROTECTED]
Cc: [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]
To: Russell Butek/Austin/[EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
From: Doug Davis/Raleigh/[EMAIL PROTECTED]
Subject: RE: Return type Russell Butek
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]
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]
---------------------- Forwarded by Russell Butek/Austin/IBM on 07/08/2002 11:44 AM ---------------------------
Please respond to [email protected]
To: [email protected]
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]
Please respond to [email protected]
To: "'[email protected]'" <[email protected]>
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]]
Sent: Monday, July 08, 2002 12:19 PM
To: [email protected]
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]
Please respond to [email protected]
To: [email protected]
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 [email protected]
To: [email protected]
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]
Please respond to [email protected]
To: [email protected]
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: [email protected]
cc:
From: Doug Davis/Raleigh/[EMAIL PROTECTED]
Subject: RE: Return type Doug Davis
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 [email protected]
To: "'[email protected]'" <[email protected]>
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]]
Sent: Tuesday, July 02, 2002 10:07 AM
To: [email protected]
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]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
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:
<<inline: C6363243.gif>>
<<inline: C0112771.gif>>
