axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Jordahl <t...@macromedia.com>
Subject RE: cvs commit: xml-axis/java/src/org/apache/axis/client Stub.jav a
Date Thu, 10 Apr 2003 13:37:32 GMT

+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;           
>              }
>     
>   
>   
>   
> 

Mime
View raw message