RE: cvs commit: xml-axis/java/src/org/apache/axis/client Stub.jav a

[Tom Jordahl <to...@macromedia.com>]

+1
*Response* headers should NOT automatically get sent in the next request.

Should headers set in the Stub be sent for every *request*?
Example:
 Stub.setHeader("user", "foo");
 Stub.myOperation(...);  // header "user" sent
 Stub.myOtherOp(...); // should the "user" header be sent again?

I can see a case both ways, but I think I prefer to require request headers be set for each operation.  This doesn't violate the principle of least surprise.  

Anyone know what the Sun implementation does with stuff like this?

--
Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: Glen Daniels [mailto:gdaniels@macromedia.com] 
Sent: Thursday, April 10, 2003 1:43 AM
To: 'axis-dev@ws.apache.org'
Subject: RE: cvs commit: xml-axis/java/src/org/apache/axis/client Stub.jav a


Oh, for cryin'....

OK, now I understand the problem - I didn't see that "headers.add()" line before when I glanced through the code.  I'd have to go through the logs to see who put that in, but IMHO this is a *REALLY BAD* idea - response headers do not necessarily mean that you should update request headers; that depends COMPLETELY on the semantics of the extension in question.  Here's a great example - the client is already managing the session header itself, and will happily put one in each outgoing message via the SimpleSessionHandler.  When the "send back all the response headers on the next request" code in the Stub gets invoked, it breaks the model.  Your fix makes it better, Chris, for this particular case, but not in general.  What about a response header that indicates "hey this message is encrypted"?  That certainly shouldn't be turned around and thrown in the next request message, since it'd be a lie unless the message was in fact encrypted, which again should be the job of a Handler to take care of, not the Stub.

I propose we remove both the code Chris added to patch the problem with sessions, and the "headers.add()" so that we avoid not only this problem but a ton of other potential ones.  If people want an easy API for "reflect back particular response headers" we can add that later, after we design it correctly.

--Glen

> -----Original Message-----
> From: haddadc@apache.org [mailto:haddadc@apache.org]
> Sent: Wednesday, April 09, 2003 8:36 PM
> To: xml-axis-cvs@apache.org
> Subject: cvs commit: xml-axis/java/src/org/apache/axis/client 
> Stub.java
> 
> 
> haddadc     2003/04/09 17:36:00
> 
>   Modified:    java/src/org/apache/axis/client Stub.java
>   Log:
>   since we have QNames, use them to make the code more readable.
>   PR: 18854
>   
>   Revision  Changes    Path
>   1.26      +1 -2      
> xml-axis/java/src/org/apache/axis/client/Stub.java
>   
>   Index: Stub.java
>   ===================================================================
>   RCS file: 
> /home/cvs/xml-axis/java/src/org/apache/axis/client/Stub.java,v
>   retrieving revision 1.25
>   retrieving revision 1.26
>   diff -u -r1.25 -r1.26
>   --- Stub.java	10 Apr 2003 00:19:37 -0000	1.25
>   +++ Stub.java	10 Apr 2003 00:36:00 -0000	1.26
>   @@ -438,8 +438,7 @@
>     
>          for(int iScan=0;iScan<vElems.size();iScan++) {
>            SOAPHeaderElement oElem = 
> (SOAPHeaderElement)vElems.get(iScan);
>   -        if ( 
> (oElem.getNamespaceURI().equals(oHeader.getNamespaceURI()) == 
>   -            true) && 
> (oElem.getName().equals(oHeader.getName()) == true) ) {
>   +        if (oElem.getQName().equals(oHeader.getQName()) == true) {
>                return iScan;           
>              }
>     
>   
>   
>   
>