You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Dan Armbrust <da...@gmail.com> on 2005/06/01 17:37:31 UTC

Re: Blockers for Axis 1.2.1 Release(?)

If my opinion counts... this one is a critical blocker...

http://issues.apache.org/jira/browse/AXIS-2021

Dan

Davanum Srinivas wrote:

>Hi all,
>
>Let's get the ball rolling again...Anyone see blockers for a minor
>release? Please make sure the problem exists in latest CVS,
>write/upload a test case and finally change the priority on the JIRA
>issue to blocker.
>
>Thanks,
>dims
>  
>

Re: AXIS-2033 (Re: Blockers for Axis 1.2.1 Release(?))

Posted by Andreas Bohnert <ab...@weberhofer.at>.
dims,

I have tested a bit and I believe, the patch you have submitted works 
well, but I'm just not able to set chunked property :(

this seems not the way to do it :

        org.apache.axis.client.Call _call = createCall();

        MessageContext msgContext = _call.getMessageContext();
        Hashtable userHeaderTable = new Hashtable();
        
userHeaderTable.put(HTTPConstants.HEADER_TRANSFER_ENCODING_CHUNKED, 
"false");
        msgContext.setProperty(HTTPConstants.REQUEST_HEADERS, 
userHeaderTable );
       .....
        _resp = _call.invoke(new java.lang.Object[] {in0});


thanks,
andreas

Davanum Srinivas wrote:
>Andreas,
>
>if you can help with reviewing the code in CommonsHTTPSender and
>coming up with a patch that will be the quickest way to deal with
>this. you see I don't have a way to test this. Please open a new bug
>or add comments for me to reopen this one once u have a patch.
>
>thanks,
>dims
>
>On 6/13/05, Andreas Bohnert <ab...@weberhofer.at> wrote:
>  
>>hi,
>>
>>for me http://issues.apache.org/jira/browse/AXIS-2033 is still a
>>blocker. http 1.1 connections are not working with older apache proxies
>>(<=1.3.33)
>>
>>the issue is already marked as fixed, but unfortunately the patch
>>doesn't work for me. I still stuck with axis 1.2RC3
>>
>>I have added a comment to this issue together with a snippet of my
>>client code.
>>
>>
>>regards,
>>andreas
>>
>>    
>
>
>  


Re: AXIS-2033 (Re: Blockers for Axis 1.2.1 Release(?))

Posted by Andreas Bohnert <ab...@weberhofer.at>.
thanks!

Davanum Srinivas wrote:
>The jdk15 comes with dom3 which is a not compatible with SAAJ 1.2
>spec. can you please drop the xercesImpl.jar and xmlParserAPIs.jar in
>java/lib directory. if that does not work, please drop them into
>JDK15\jre\lib\endorsed directory (as per
>http://java.sun.com/j2se/1.4.2/docs/guide/standards/).
>
>thanks,
>dims
>
>
>On 6/13/05, Andreas Bohnert <ab...@weberhofer.at> wrote:
>  
>>hi dims,
>>
>>I would like to help, but I am not able to compile the sources.
>>the problem is related to org.w3c.dom.* which comes with the the jdk 1.5
>>(rt.jar).
>>I get this:
>>
>>    [javac]
>>/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/NodeImpl.java:45:
>>org.apache.axis.message.NodeImpl is not abstract and does not override
>>abstract method getUserData(java.lang.String) in org.w3c.dom.Node
>>    [javac] public class NodeImpl implements org.w3c.dom.Node,
>>javax.xml.soap.Node,
>>    [javac] ^
>>    [javac]
>>/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/MessageElement.java:73:
>>org.apache.axis.message.MessageElement is not abstract and does not
>>override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
>>    [javac] public class MessageElement extends NodeImpl implements
>>SOAPElement,
>>    [javac] ^
>>    [javac]
>>/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPHeaderElement.java:40:
>>org.apache.axis.message.SOAPHeaderElement is not abstract and does not
>>override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
>>    [javac] public class SOAPHeaderElement extends MessageElement
>>    [javac] ^
>>    [javac]
>>/home/abo/workspace/ws-axis/java/src/org/apache/axis/SOAPPart.java:90:
>>org.apache.axis.SOAPPart is not abstract and does not override abstract
>>method renameNode(org.w3c.dom.Node,java.lang.String,java.lang.String) in
>>org.w3c.dom.Document
>>    [javac] public class SOAPPart extends javax.xml.soap.SOAPPart
>>implements Part
>>    [javac] ^
>>    [javac]
>>/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPEnvelope.java:50:
>>org.apache.axis.message.SOAPEnvelope is not abstract and does not
>>override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
>>    [javac] public class SOAPEnvelope extends MessageElement
>>    [javac] ^
>>    [javac]
>>/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPHeader.java:50:
>>org.apache.axis.message.SOAPHeader is not abstract and does not override
>>abstract method getUserData(java.lang.String) in org.w3c.dom.Node
>>    [javac] public class SOAPHeader extends MessageElement
>>    [javac] ^
>>    [javac]
>>/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPBody.java:46:
>>org.apache.axis.message.SOAPBody is not abstract and does not override
>>abstract method getUserData(java.lang.String) in org.w3c.dom.Node
>>    [javac] public class SOAPBody extends MessageElement
>>    [javac] ^
>>    [javac]
>>/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPBodyElement.java:37:
>>org.apache.axis.message.SOAPBodyElement is not abstract and does not
>>override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
>>    [javac] public class SOAPBodyElement extends MessageElement
>>
>>regards,
>>andreas
>>
>>
>>Davanum Srinivas wrote:
>>    
>>>Andreas,
>>>
>>>if you can help with reviewing the code in CommonsHTTPSender and
>>>coming up with a patch that will be the quickest way to deal with
>>>this. you see I don't have a way to test this. Please open a new bug
>>>or add comments for me to reopen this one once u have a patch.
>>>
>>>thanks,
>>>dims
>>>
>>>On 6/13/05, Andreas Bohnert <ab...@weberhofer.at> wrote:
>>>
>>>      
>>>>hi,
>>>>
>>>>for me http://issues.apache.org/jira/browse/AXIS-2033 is still a
>>>>blocker. http 1.1 connections are not working with older apache proxies
>>>>(<=1.3.33)
>>>>
>>>>the issue is already marked as fixed, but unfortunately the patch
>>>>doesn't work for me. I still stuck with axis 1.2RC3
>>>>
>>>>I have added a comment to this issue together with a snippet of my
>>>>client code.
>>>>
>>>>
>>>>regards,
>>>>andreas
>>>>
>>>>
>>>>        
>>>
>>>      
>>    
>
>
>  


Re: AXIS-2033 (Re: Blockers for Axis 1.2.1 Release(?))

Posted by Davanum Srinivas <da...@gmail.com>.
The jdk15 comes with dom3 which is a not compatible with SAAJ 1.2
spec. can you please drop the xercesImpl.jar and xmlParserAPIs.jar in
java/lib directory. if that does not work, please drop them into
JDK15\jre\lib\endorsed directory (as per
http://java.sun.com/j2se/1.4.2/docs/guide/standards/).

thanks,
dims


On 6/13/05, Andreas Bohnert <ab...@weberhofer.at> wrote:
> hi dims,
> 
> I would like to help, but I am not able to compile the sources.
> the problem is related to org.w3c.dom.* which comes with the the jdk 1.5
> (rt.jar).
> I get this:
> 
>     [javac]
> /home/abo/workspace/ws-axis/java/src/org/apache/axis/message/NodeImpl.java:45:
> org.apache.axis.message.NodeImpl is not abstract and does not override
> abstract method getUserData(java.lang.String) in org.w3c.dom.Node
>     [javac] public class NodeImpl implements org.w3c.dom.Node,
> javax.xml.soap.Node,
>     [javac] ^
>     [javac]
> /home/abo/workspace/ws-axis/java/src/org/apache/axis/message/MessageElement.java:73:
> org.apache.axis.message.MessageElement is not abstract and does not
> override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
>     [javac] public class MessageElement extends NodeImpl implements
> SOAPElement,
>     [javac] ^
>     [javac]
> /home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPHeaderElement.java:40:
> org.apache.axis.message.SOAPHeaderElement is not abstract and does not
> override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
>     [javac] public class SOAPHeaderElement extends MessageElement
>     [javac] ^
>     [javac]
> /home/abo/workspace/ws-axis/java/src/org/apache/axis/SOAPPart.java:90:
> org.apache.axis.SOAPPart is not abstract and does not override abstract
> method renameNode(org.w3c.dom.Node,java.lang.String,java.lang.String) in
> org.w3c.dom.Document
>     [javac] public class SOAPPart extends javax.xml.soap.SOAPPart
> implements Part
>     [javac] ^
>     [javac]
> /home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPEnvelope.java:50:
> org.apache.axis.message.SOAPEnvelope is not abstract and does not
> override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
>     [javac] public class SOAPEnvelope extends MessageElement
>     [javac] ^
>     [javac]
> /home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPHeader.java:50:
> org.apache.axis.message.SOAPHeader is not abstract and does not override
> abstract method getUserData(java.lang.String) in org.w3c.dom.Node
>     [javac] public class SOAPHeader extends MessageElement
>     [javac] ^
>     [javac]
> /home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPBody.java:46:
> org.apache.axis.message.SOAPBody is not abstract and does not override
> abstract method getUserData(java.lang.String) in org.w3c.dom.Node
>     [javac] public class SOAPBody extends MessageElement
>     [javac] ^
>     [javac]
> /home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPBodyElement.java:37:
> org.apache.axis.message.SOAPBodyElement is not abstract and does not
> override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
>     [javac] public class SOAPBodyElement extends MessageElement
> 
> regards,
> andreas
> 
> 
> Davanum Srinivas wrote:
> >Andreas,
> >
> >if you can help with reviewing the code in CommonsHTTPSender and
> >coming up with a patch that will be the quickest way to deal with
> >this. you see I don't have a way to test this. Please open a new bug
> >or add comments for me to reopen this one once u have a patch.
> >
> >thanks,
> >dims
> >
> >On 6/13/05, Andreas Bohnert <ab...@weberhofer.at> wrote:
> >
> >>hi,
> >>
> >>for me http://issues.apache.org/jira/browse/AXIS-2033 is still a
> >>blocker. http 1.1 connections are not working with older apache proxies
> >>(<=1.3.33)
> >>
> >>the issue is already marked as fixed, but unfortunately the patch
> >>doesn't work for me. I still stuck with axis 1.2RC3
> >>
> >>I have added a comment to this issue together with a snippet of my
> >>client code.
> >>
> >>
> >>regards,
> >>andreas
> >>
> >>
> >
> >
> >
> 
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

Re: AXIS-2033 (Re: Blockers for Axis 1.2.1 Release(?))

Posted by Andreas Bohnert <ab...@weberhofer.at>.
hi dims,

I would like to help, but I am not able to compile the sources.
the problem is related to org.w3c.dom.* which comes with the the jdk 1.5 
(rt.jar).
I get this:

    [javac] 
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/NodeImpl.java:45: 
org.apache.axis.message.NodeImpl is not abstract and does not override 
abstract method getUserData(java.lang.String) in org.w3c.dom.Node
    [javac] public class NodeImpl implements org.w3c.dom.Node, 
javax.xml.soap.Node,
    [javac] ^
    [javac] 
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/MessageElement.java:73: 
org.apache.axis.message.MessageElement is not abstract and does not 
override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
    [javac] public class MessageElement extends NodeImpl implements 
SOAPElement,
    [javac] ^
    [javac] 
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPHeaderElement.java:40: 
org.apache.axis.message.SOAPHeaderElement is not abstract and does not 
override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
    [javac] public class SOAPHeaderElement extends MessageElement
    [javac] ^
    [javac] 
/home/abo/workspace/ws-axis/java/src/org/apache/axis/SOAPPart.java:90: 
org.apache.axis.SOAPPart is not abstract and does not override abstract 
method renameNode(org.w3c.dom.Node,java.lang.String,java.lang.String) in 
org.w3c.dom.Document
    [javac] public class SOAPPart extends javax.xml.soap.SOAPPart 
implements Part
    [javac] ^
    [javac] 
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPEnvelope.java:50: 
org.apache.axis.message.SOAPEnvelope is not abstract and does not 
override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
    [javac] public class SOAPEnvelope extends MessageElement
    [javac] ^
    [javac] 
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPHeader.java:50: 
org.apache.axis.message.SOAPHeader is not abstract and does not override 
abstract method getUserData(java.lang.String) in org.w3c.dom.Node
    [javac] public class SOAPHeader extends MessageElement
    [javac] ^
    [javac] 
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPBody.java:46: 
org.apache.axis.message.SOAPBody is not abstract and does not override 
abstract method getUserData(java.lang.String) in org.w3c.dom.Node
    [javac] public class SOAPBody extends MessageElement
    [javac] ^
    [javac] 
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPBodyElement.java:37: 
org.apache.axis.message.SOAPBodyElement is not abstract and does not 
override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
    [javac] public class SOAPBodyElement extends MessageElement

regards,
andreas


Davanum Srinivas wrote:
>Andreas,
>
>if you can help with reviewing the code in CommonsHTTPSender and
>coming up with a patch that will be the quickest way to deal with
>this. you see I don't have a way to test this. Please open a new bug
>or add comments for me to reopen this one once u have a patch.
>
>thanks,
>dims
>
>On 6/13/05, Andreas Bohnert <ab...@weberhofer.at> wrote:
>  
>>hi,
>>
>>for me http://issues.apache.org/jira/browse/AXIS-2033 is still a
>>blocker. http 1.1 connections are not working with older apache proxies
>>(<=1.3.33)
>>
>>the issue is already marked as fixed, but unfortunately the patch
>>doesn't work for me. I still stuck with axis 1.2RC3
>>
>>I have added a comment to this issue together with a snippet of my
>>client code.
>>
>>
>>regards,
>>andreas
>>
>>    
>
>
>  


AXIS-2033 (Re: Blockers for Axis 1.2.1 Release(?))

Posted by Davanum Srinivas <da...@gmail.com>.
Andreas,

if you can help with reviewing the code in CommonsHTTPSender and
coming up with a patch that will be the quickest way to deal with
this. you see I don't have a way to test this. Please open a new bug
or add comments for me to reopen this one once u have a patch.

thanks,
dims

On 6/13/05, Andreas Bohnert <ab...@weberhofer.at> wrote:
> hi,
> 
> for me http://issues.apache.org/jira/browse/AXIS-2033 is still a
> blocker. http 1.1 connections are not working with older apache proxies
> (<=1.3.33)
> 
> the issue is already marked as fixed, but unfortunately the patch
> doesn't work for me. I still stuck with axis 1.2RC3
> 
> I have added a comment to this issue together with a snippet of my
> client code.
> 
> 
> regards,
> andreas
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

Re: Blockers for Axis 1.2.1 Release(?)

Posted by Andreas Bohnert <ab...@weberhofer.at>.
hi,

for me http://issues.apache.org/jira/browse/AXIS-2033 is still a 
blocker. http 1.1 connections are not working with older apache proxies 
(<=1.3.33)

the issue is already marked as fixed, but unfortunately the patch 
doesn't work for me. I still stuck with axis 1.2RC3

I have added a comment to this issue together with a snippet of my 
client code.


regards,
andreas

Re: AXIS-895 (Re: Blockers for Axis 1.2.1 Release(?))

Posted by Davanum Srinivas <da...@gmail.com>.
please see my comment in the bug.

thanks,
dims

On 6/13/05, Gerry Gao <gj...@hotmail.com> wrote:
> Hi dims,
> 
> I have submit a patch to http://issues.apache.org/jira/browse/AXIS-895.
> 
> I don't know what's wrong with JIRA, the patch's name is wrong.
> 
> Anyway it is the one named HTTPSender and with 11kb size.
> 
> http://issues.apache.org/jira/secure/attachment/12310695/HTTPSender.java
> 
> regards
> Gerry
> 
> ----- Original Message -----
> From: "Davanum Srinivas" <da...@gmail.com>
> To: "Gerry Gao" <gj...@hotmail.com>
> Cc: <ax...@ws.apache.org>
> Sent: Monday, June 13, 2005 6:59 PM
> Subject: AXIS-895 (Re: Blockers for Axis 1.2.1 Release(?))
> 
> 
> Gerry,
> 
> Please submit a patch for HTTPSender/CommonsHTTPSender ASAP!. Don't
> worry about a test case right now...i'd like to review the code patch
> first.
> 
> thanks,
> dims
> 
> On 6/13/05, Gerry Gao <gj...@hotmail.com> wrote:
> > Hi dims,
> >
> > Well done! And hope this is not too late.
> >
> > I still have some concern about http://issues.apache.org/jira/browse/AXIS-895.
> >
> > As I reviewed the latest CVS code and do a basic test on it, I think there is still some issue will the cookie stuff in HTTPSender and CommonsHTTPSender.
> >
> > Now the HTTPSender and CommonsHTTPSender have different cookie behavior for "maintainSession" client, and both of the behaviors are not completely correct.
> >
> > According to my test, now HTTPSender is a closer to the perfect.
> >
> > Here is a sample for HTTPSender now (paste from tcpmon):
> >
> > request 1:
> > <no cookie>
> > respones 1:
> > Set-Cookie: JSESSIONID=14qbbc5mptua2;Path=/axis
> > Set-Cookie: a=a
> > Set-Cookie: b=b
> >
> > request 2:
> > Cookie: JSESSIONID=14qbbc5mptua2
> > Cookie: a=a
> > Cookie: b=b
> > respnonse 2:
> > Set-Cookie: a=a1
> > Set-Cookie: c=c
> >
> > request 3:
> > Cookie: JSESSIONID=14qbbc5mptua2
> > Cookie: a=a
> > Cookie: b=b
> > Cookie: a=a1
> > Cookie: c=c
> >
> > IMO, the reqesut 3 should only have one cookie with name "a" and it should be "a=a1" instead of tow cookies.
> >
> > For the same sitation for CommonsHTTPSender, it can't even maintain the session correctly!
> >
> > request 1:
> > <no cookie>
> > respones 1:
> > Set-Cookie: JSESSIONID=bpg1ne69gl099;Path=/axis
> > Set-Cookie: a=a
> > Set-Cookie: b=b
> >
> > request 2:
> > Cookie: JSESSIONID=bpg1ne69gl099
> > Cookie: a=a
> > Cookie: b=b
> > respnonse 2:
> > Set-Cookie: a=a1
> > Set-Cookie: c=c
> >
> >
> > request 3:
> > Cookie: a=a1
> > Cookie: c=c
> >
> > With CommonsHTTPSender, it only send to sever the cookies which are added in the very last response.
> >
> > This result is consistent with the code I reviewed.
> >
> > IMO, it should use HashMap or Hashtable instead of String[] to handle multicookies.
> > Hope this helps.
> >
> > BTW, I do want submit a test case to reoccur this, but I don't know if it must be a standalone runnable JUnit test case. Actually, don't know how to pack a test comfortable for AXIS.
> >
> > Gerry
> >
> > ----- Original Message -----
> > From: "Davanum Srinivas" <da...@gmail.com>
> > To: <ax...@ws.apache.org>; <ax...@ws.apache.org>
> > Sent: Monday, June 13, 2005 11:03 AM
> > Subject: Re: Blockers for Axis 1.2.1 Release(?)
> >
> >
> > Team, Folks,
> >
> > Zero blockers now...Please try latest CVS / Nightly ASAP!
> >
> > thanks,
> > dims
> >
> 
> 
> --
> Davanum Srinivas -http://blogs.cocoondev.org/dims/
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

Re: AXIS-895 (Re: Blockers for Axis 1.2.1 Release(?))

Posted by Gerry Gao <gj...@hotmail.com>.
Hi dims, 

I have submit a patch to http://issues.apache.org/jira/browse/AXIS-895.

I don't know what's wrong with JIRA, the patch's name is wrong.

Anyway it is the one named HTTPSender and with 11kb size.

http://issues.apache.org/jira/secure/attachment/12310695/HTTPSender.java

regards
Gerry

----- Original Message ----- 
From: "Davanum Srinivas" <da...@gmail.com>
To: "Gerry Gao" <gj...@hotmail.com>
Cc: <ax...@ws.apache.org>
Sent: Monday, June 13, 2005 6:59 PM
Subject: AXIS-895 (Re: Blockers for Axis 1.2.1 Release(?))


Gerry,

Please submit a patch for HTTPSender/CommonsHTTPSender ASAP!. Don't
worry about a test case right now...i'd like to review the code patch
first.

thanks,
dims

On 6/13/05, Gerry Gao <gj...@hotmail.com> wrote:
> Hi dims,
> 
> Well done! And hope this is not too late.
> 
> I still have some concern about http://issues.apache.org/jira/browse/AXIS-895.
> 
> As I reviewed the latest CVS code and do a basic test on it, I think there is still some issue will the cookie stuff in HTTPSender and CommonsHTTPSender.
> 
> Now the HTTPSender and CommonsHTTPSender have different cookie behavior for "maintainSession" client, and both of the behaviors are not completely correct.
> 
> According to my test, now HTTPSender is a closer to the perfect.
> 
> Here is a sample for HTTPSender now (paste from tcpmon):
> 
> request 1:
> <no cookie>
> respones 1:
> Set-Cookie: JSESSIONID=14qbbc5mptua2;Path=/axis
> Set-Cookie: a=a
> Set-Cookie: b=b
> 
> request 2:
> Cookie: JSESSIONID=14qbbc5mptua2
> Cookie: a=a
> Cookie: b=b
> respnonse 2:
> Set-Cookie: a=a1
> Set-Cookie: c=c
> 
> request 3:
> Cookie: JSESSIONID=14qbbc5mptua2
> Cookie: a=a
> Cookie: b=b
> Cookie: a=a1
> Cookie: c=c
> 
> IMO, the reqesut 3 should only have one cookie with name "a" and it should be "a=a1" instead of tow cookies.
> 
> For the same sitation for CommonsHTTPSender, it can't even maintain the session correctly!
> 
> request 1:
> <no cookie>
> respones 1:
> Set-Cookie: JSESSIONID=bpg1ne69gl099;Path=/axis
> Set-Cookie: a=a
> Set-Cookie: b=b
> 
> request 2:
> Cookie: JSESSIONID=bpg1ne69gl099
> Cookie: a=a
> Cookie: b=b
> respnonse 2:
> Set-Cookie: a=a1
> Set-Cookie: c=c
> 
> 
> request 3:
> Cookie: a=a1
> Cookie: c=c
> 
> With CommonsHTTPSender, it only send to sever the cookies which are added in the very last response.
> 
> This result is consistent with the code I reviewed.
> 
> IMO, it should use HashMap or Hashtable instead of String[] to handle multicookies.
> Hope this helps.
> 
> BTW, I do want submit a test case to reoccur this, but I don't know if it must be a standalone runnable JUnit test case. Actually, don't know how to pack a test comfortable for AXIS.
> 
> Gerry
> 
> ----- Original Message -----
> From: "Davanum Srinivas" <da...@gmail.com>
> To: <ax...@ws.apache.org>; <ax...@ws.apache.org>
> Sent: Monday, June 13, 2005 11:03 AM
> Subject: Re: Blockers for Axis 1.2.1 Release(?)
> 
> 
> Team, Folks,
> 
> Zero blockers now...Please try latest CVS / Nightly ASAP!
> 
> thanks,
> dims
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

AXIS-895 (Re: Blockers for Axis 1.2.1 Release(?))

Posted by Davanum Srinivas <da...@gmail.com>.
Gerry,

Please submit a patch for HTTPSender/CommonsHTTPSender ASAP!. Don't
worry about a test case right now...i'd like to review the code patch
first.

thanks,
dims

On 6/13/05, Gerry Gao <gj...@hotmail.com> wrote:
> Hi dims,
> 
> Well done! And hope this is not too late.
> 
> I still have some concern about http://issues.apache.org/jira/browse/AXIS-895.
> 
> As I reviewed the latest CVS code and do a basic test on it, I think there is still some issue will the cookie stuff in HTTPSender and CommonsHTTPSender.
> 
> Now the HTTPSender and CommonsHTTPSender have different cookie behavior for "maintainSession" client, and both of the behaviors are not completely correct.
> 
> According to my test, now HTTPSender is a closer to the perfect.
> 
> Here is a sample for HTTPSender now (paste from tcpmon):
> 
> request 1:
> <no cookie>
> respones 1:
> Set-Cookie: JSESSIONID=14qbbc5mptua2;Path=/axis
> Set-Cookie: a=a
> Set-Cookie: b=b
> 
> request 2:
> Cookie: JSESSIONID=14qbbc5mptua2
> Cookie: a=a
> Cookie: b=b
> respnonse 2:
> Set-Cookie: a=a1
> Set-Cookie: c=c
> 
> request 3:
> Cookie: JSESSIONID=14qbbc5mptua2
> Cookie: a=a
> Cookie: b=b
> Cookie: a=a1
> Cookie: c=c
> 
> IMO, the reqesut 3 should only have one cookie with name "a" and it should be "a=a1" instead of tow cookies.
> 
> For the same sitation for CommonsHTTPSender, it can't even maintain the session correctly!
> 
> request 1:
> <no cookie>
> respones 1:
> Set-Cookie: JSESSIONID=bpg1ne69gl099;Path=/axis
> Set-Cookie: a=a
> Set-Cookie: b=b
> 
> request 2:
> Cookie: JSESSIONID=bpg1ne69gl099
> Cookie: a=a
> Cookie: b=b
> respnonse 2:
> Set-Cookie: a=a1
> Set-Cookie: c=c
> 
> 
> request 3:
> Cookie: a=a1
> Cookie: c=c
> 
> With CommonsHTTPSender, it only send to sever the cookies which are added in the very last response.
> 
> This result is consistent with the code I reviewed.
> 
> IMO, it should use HashMap or Hashtable instead of String[] to handle multicookies.
> Hope this helps.
> 
> BTW, I do want submit a test case to reoccur this, but I don't know if it must be a standalone runnable JUnit test case. Actually, don't know how to pack a test comfortable for AXIS.
> 
> Gerry
> 
> ----- Original Message -----
> From: "Davanum Srinivas" <da...@gmail.com>
> To: <ax...@ws.apache.org>; <ax...@ws.apache.org>
> Sent: Monday, June 13, 2005 11:03 AM
> Subject: Re: Blockers for Axis 1.2.1 Release(?)
> 
> 
> Team, Folks,
> 
> Zero blockers now...Please try latest CVS / Nightly ASAP!
> 
> thanks,
> dims
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

Re: Blockers for Axis 1.2.1 Release(?)

Posted by Gerry Gao <gj...@hotmail.com>.
Hi dims,

Well done! And hope this is not too late.

I still have some concern about http://issues.apache.org/jira/browse/AXIS-895.

As I reviewed the latest CVS code and do a basic test on it, I think there is still some issue will the cookie stuff in HTTPSender and CommonsHTTPSender.

Now the HTTPSender and CommonsHTTPSender have different cookie behavior for "maintainSession" client, and both of the behaviors are not completely correct.

According to my test, now HTTPSender is a closer to the perfect.

Here is a sample for HTTPSender now (paste from tcpmon):

request 1:
<no cookie>
respones 1:
Set-Cookie: JSESSIONID=14qbbc5mptua2;Path=/axis
Set-Cookie: a=a
Set-Cookie: b=b

request 2:
Cookie: JSESSIONID=14qbbc5mptua2
Cookie: a=a
Cookie: b=b
respnonse 2:
Set-Cookie: a=a1
Set-Cookie: c=c

request 3:
Cookie: JSESSIONID=14qbbc5mptua2
Cookie: a=a
Cookie: b=b
Cookie: a=a1
Cookie: c=c

IMO, the reqesut 3 should only have one cookie with name "a" and it should be "a=a1" instead of tow cookies.

For the same sitation for CommonsHTTPSender, it can't even maintain the session correctly!

request 1:
<no cookie>
respones 1:
Set-Cookie: JSESSIONID=bpg1ne69gl099;Path=/axis
Set-Cookie: a=a
Set-Cookie: b=b

request 2:
Cookie: JSESSIONID=bpg1ne69gl099
Cookie: a=a
Cookie: b=b
respnonse 2:
Set-Cookie: a=a1
Set-Cookie: c=c


request 3:
Cookie: a=a1
Cookie: c=c

With CommonsHTTPSender, it only send to sever the cookies which are added in the very last response.

This result is consistent with the code I reviewed.

IMO, it should use HashMap or Hashtable instead of String[] to handle multicookies.
Hope this helps.

BTW, I do want submit a test case to reoccur this, but I don't know if it must be a standalone runnable JUnit test case. Actually, don't know how to pack a test comfortable for AXIS.

Gerry

----- Original Message ----- 
From: "Davanum Srinivas" <da...@gmail.com>
To: <ax...@ws.apache.org>; <ax...@ws.apache.org>
Sent: Monday, June 13, 2005 11:03 AM
Subject: Re: Blockers for Axis 1.2.1 Release(?)


Team, Folks,

Zero blockers now...Please try latest CVS / Nightly ASAP!

thanks,
dims

Re: Blockers for Axis 1.2.1 Release(?)

Posted by Davanum Srinivas <da...@gmail.com>.
Team, Folks,

Zero blockers now...Please try latest CVS / Nightly ASAP!

thanks,
dims

Re: Blockers for Axis 1.2.1 Release(?)

Posted by Davanum Srinivas <da...@gmail.com>.
Team, Folks,

Zero blockers now...Please try latest CVS / Nightly ASAP!

thanks,
dims

Re: Blockers for Axis 1.2.1 Release(?)

Posted by Davanum Srinivas <da...@gmail.com>.
2 blockers remaining...

http://issues.apache.org/jira/browse/AXIS-1976
http://issues.apache.org/jira/browse/AXIS-1366

-- dims

Re: Blockers for Axis 1.2.1 Release(?)

Posted by Vy Ho <st...@drexel.edu>.
Is there any chance that this issue:

http://issues.apache.org/jira/browse/AXIS-1903

get fixed?  It seems to have problem with many platforms.

Davanum Srinivas wrote:

>Folks,
>
>I see 5 blockers...Does anyone else have others that needs fixed ASAP?
>I may or may not downgrade some of these depending on various factors
>(which i will of course add to the comments).
>
>http://issues.apache.org/jira/browse/AXIS-2046
>http://issues.apache.org/jira/browse/AXIS-1986
>http://issues.apache.org/jira/browse/AXIS-1985
>http://issues.apache.org/jira/browse/AXIS-1976
>http://issues.apache.org/jira/browse/AXIS-1366
>
>thanks,
>dims
>
>On 6/1/05, Dan Armbrust <da...@gmail.com> wrote:
>  
>
>>If my opinion counts... this one is a critical blocker...
>>
>>http://issues.apache.org/jira/browse/AXIS-2021
>>
>>Dan
>>
>>Davanum Srinivas wrote:
>>
>>    
>>


Re: Blockers for Axis 1.2.1 Release(?)

Posted by Davanum Srinivas <da...@gmail.com>.
2 blockers remaining...

http://issues.apache.org/jira/browse/AXIS-1976
http://issues.apache.org/jira/browse/AXIS-1366

-- dims

Re: Blockers for Axis 1.2.1 Release(?)

Posted by Davanum Srinivas <da...@gmail.com>.
Folks,

I see 5 blockers...Does anyone else have others that needs fixed ASAP?
I may or may not downgrade some of these depending on various factors
(which i will of course add to the comments).

http://issues.apache.org/jira/browse/AXIS-2046
http://issues.apache.org/jira/browse/AXIS-1986
http://issues.apache.org/jira/browse/AXIS-1985
http://issues.apache.org/jira/browse/AXIS-1976
http://issues.apache.org/jira/browse/AXIS-1366

thanks,
dims

On 6/1/05, Dan Armbrust <da...@gmail.com> wrote:
> If my opinion counts... this one is a critical blocker...
> 
> http://issues.apache.org/jira/browse/AXIS-2021
> 
> Dan
> 
> Davanum Srinivas wrote:
> 
> >Hi all,
> >
> >Let's get the ball rolling again...Anyone see blockers for a minor
> >release? Please make sure the problem exists in latest CVS,
> >write/upload a test case and finally change the priority on the JIRA
> >issue to blocker.
> >
> >Thanks,
> >dims
> >
> >
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

Re: Blockers for Axis 1.2.1 Release(?)

Posted by Davanum Srinivas <da...@gmail.com>.
Folks,

I see 5 blockers...Does anyone else have others that needs fixed ASAP?
I may or may not downgrade some of these depending on various factors
(which i will of course add to the comments).

http://issues.apache.org/jira/browse/AXIS-2046
http://issues.apache.org/jira/browse/AXIS-1986
http://issues.apache.org/jira/browse/AXIS-1985
http://issues.apache.org/jira/browse/AXIS-1976
http://issues.apache.org/jira/browse/AXIS-1366

thanks,
dims

On 6/1/05, Dan Armbrust <da...@gmail.com> wrote:
> If my opinion counts... this one is a critical blocker...
> 
> http://issues.apache.org/jira/browse/AXIS-2021
> 
> Dan
> 
> Davanum Srinivas wrote:
> 
> >Hi all,
> >
> >Let's get the ball rolling again...Anyone see blockers for a minor
> >release? Please make sure the problem exists in latest CVS,
> >write/upload a test case and finally change the priority on the JIRA
> >issue to blocker.
> >
> >Thanks,
> >dims
> >
> >
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/