froehlich02/02/17 03:24:15
Modified:simplestore/src/java/org/apache/commons/simplestore/persistence
TypeConverter.java
Log:
fixed typo in javadoc
Revision ChangesPath
1.2 +2 -2
Applied and fixed formatting.
Sean C. Sullivan wrote:
This is a patch for HttpClient.java
The patch file, HttpClient.patch, is attached.
I created the patch files using this command:
cvs diff -u Foo.java Foo.patch
Changes:
executeMethod now checks for a null
Applied and fixed formatting
Sean C. Sullivan wrote:
This is a patch for HttpMethodBase.java
The patch file, HttpMethodBase.patch, is attached.
I created the patch file using this command:
cvs diff -u Foo.java Foo.patch
Changes:
the execute method will now check
Sean C. Sullivan wrote:
Here are patches for RequestOutputStream.java and ResponseInputStream.java
Two patch files are attached.
I created the patch files using this command:
cvs diff -u Foo.java Foo.patch
Changes in RequestOutputStream:
removed email address
I have had a closer look at my code ... :-) and the problem is not where
I though it was. Actually, I do specify the domain for each cookie so
this is not the issue.
The issue is with the cookie path. I do not specify any path for my
cookies. This is in conformance with the Cookie class that has
Here is another patch for ResponseInputStream.java
A patch file is attached.
I created the patch file using this command:
cvs diff -u Foo.java Foo.patch
Changes in ResponseInputStream:
improved javadoc comments
improved code comments in constructor
James:
James Strachan wrote:
Hi Thomas
From: Thomas Marsh [EMAIL PROTECTED]
All:
I didn't see a -user list for commons, so I'm posting this here. If
there is a better place to post this, please let me know.
This is the best place to post.
Has anyone used commons messenger
- Original Message -
From: Thomas Marsh [EMAIL PROTECTED]
James:
James Strachan wrote:
Hi Thomas
From: Thomas Marsh [EMAIL PROTECTED]
All:
I didn't see a -user list for commons, so I'm posting this here. If
there is a better place to post this, please let me know.
Just wondering if there is a release in the near future.
Is there some work that someone (like me) who is new to open source and
Jakarta could do to help contribute?
Also, I'd like to suggest adding an isEnabledFor method to the API since
it is part of the log4j API. I would be interested in
dion02/02/17 03:46:15
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpClient.java
Log:
Added patches from Sean C Sullivan which included javadoc and parameter/
state checking in execute method.
Fixed some code formatting as well
dion02/02/17 04:04:29
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpMethodBase.java
Log:
Patches provided by Sean C Sullivan, fixed if statement formatting
Revision ChangesPath
1.25 +122 -88
dion02/02/17 04:15:56
Modified:httpclient/src/java/org/apache/commons/httpclient
RequestOutputStream.java
Log:
Applied patches from Sean C. Sullivan about closing of streams not being
done correctly
Revision ChangesPath
1.8 +23 -14
dion02/02/17 04:20:06
Modified:httpclient/src/java/org/apache/commons/httpclient
ResponseInputStream.java
Log:
Removed Sean's email address
Revision ChangesPath
1.13 +5 -6
baliuka 02/02/17 06:09:04
Modified:simplestore/src/java/org/apache/commons/simplestore/persistence
MetaClass.java OIDGenerator.java Storage.java
TypeConverter.java
dIon Gillard wrote:
Definitely. But the place it is breaking is on the compare, which is
used for sorting the cookies. Should null always match a domain?
Should it always be less than another domain? I need to think this one
through.
Must be mad, replying to myself, but null domains
dIon, thanks for taking care of this.
-Vincent
-Original Message-
From: dIon Gillard [mailto:[EMAIL PROTECTED]]
Sent: 17 February 2002 23:10
To: Jakarta Commons Developers List
Subject: Re: [httpclient] New change to Cookie.java breaks Cactus
dIon Gillard wrote:
Definitely.
Waldhoff, Rodney wrote:
My analysis is that the previous Cookie class
was more lenient WRT the cookie domain
(i.e. it could be null). However it seems the new
Cookie.compare() method throws a NPE if it is null.
Questions :
1/ Is this done voluntarily (i.e. force the user
to always specify
I wrote test code for the HttpStatus class.
The new test file is attached: TestHttpStatus.java
I had to make patches to HttpStatus.java and
TestNoHost.java
The patches are attached.
I had to update HttpStatus.java because many status
codes were missing from the status code text map.
I ran
I was looking at the
org.apache.commons.httpclient.Authenticator
class. The class implements Basic authentication only.
It does not implement the Digest authentication scheme.
The Digest authentication scheme is described in RFC 2617:
ftp://ftp.isi.edu/in-notes/rfc2617.txt
Is
Sean C. Sullivan wrote:
From: dIon Gillard [EMAIL PROTECTED]
these patches failed to apply. Could you recreate them off the latest code?
Revised patches are attached.
-Sean
Here is another patch for RequestOutputStream.java
A patch file is attached.
I created the patch file
AFAIK, the change to print would've broken
existing code compatibility.
True, although the current behavior:
if(s == null) s = null;
is a bit quirky, don't you think?
I'd be in favor of not allowing null, but just let the s.length() call throw
the NullPointerException rather than explictly
Rod,
how about the parameters passed to parse.
From reading of the javadoc, the domain and
path passed to parse shouldn't be null.
Is this correct?
I don't see it specified one way or the other in the javadoc, but it looks
like currently none of the parse methods will accept null for
22 matches
Mail list logo
