You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Sean C. Sullivan" <se...@seansullivan.com> on 2002/02/02 23:15:14 UTC
[httpclient] unit test code patches, src\test\org\apache\commons\httpclient
I updated the JUnit test code for the HttpClient.
I revised the code to comply with JUnit 3.7
I created the patch files using this command:
cvs diff -c Foo.java > Foo.patch
-Sean
Re: [httpclient] unit test code patches, src\test\org\apache\commons\httpclient
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
>I updated the JUnit test code for the HttpClient.
>
>I revised the code to comply with JUnit 3.7
>
>I created the patch files using this command:
>
> cvs diff -c Foo.java > Foo.patch
>
>-Sean
>
Hi Sean,
I applied the patches locally on my machine, and they all seem ok. The
project specifically mentions junit 3.5 as the level they have
pre-req'ed, so I'm going to do a build and see how things go with 3.7 to
see if all is still well.
Any committers from HttpClient listening? Any objections to moving to
Junit 3.7?
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] API design, Cookie.getExpiryDate, Cookie.setExpiryDate
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
My comments are below...
From: "dIon Gillard" <di...@multitask.com.au>
> Sean C. Sullivan wrote:
>
> >I updated the code for the HttpClient:
> >
> > Cookie.java
> > TestCookie.java
> >
> >
> >The modification changes the behavior of Cookie.getExpiryDate
> >
> >Instead of returning the internal Date object, we return a freshly
> >instantiated Date object.
> >
> >Why: Because java.util.Date is a mutable object.
> >
> >I created the patch files using this command:
> >
> > cvs diff -c Foo.java > Foo.patch
> >
> > -Sean
> >
>
> I'm not sure that the original behaviour is flawed as coded.
>
> The patch implies that passing setExpiryDate a Date object and then
> changing that object is a 'bad thing'. But this is the existing
> behaviour, so under the current code, I can do this:
> // uncompiled untested code
> Date d = new Date();
> cookie.setExpiryDate(d);
> d.setTime(System.currentTimeMillis());
>
> and based on the current code set, I expect the expiry date of the
> cookie to have changed. And ditto, on calling getExpiryDate() I expect
> to be able to change the Date and have it reflected in the cookie.
>
> The patch is effectively a change in the implied contract between httpclient
and the user....Comments?
I would like the HttpClient API to follow the API guidelines from Josh Bloch's
book:
Effective Java Programming Language Guide
http://www.amazon.com/exec/obidos/ASIN/0201310058/
Josh Bloch is a Senior Software Architect at Sun. Josh designed
the Java Collections API.
I highly recommend Josh's book.
In particular, I like these guidelines from Bloch's book:
==> Item 13: Favor immutability (immutable objects)
==> Item 12: Minimize the accessibility of classes and members
==> Item 6: Avoid finalizers
==> Item 21: Replace enum constructs with classes
==> Item 54: implement java.io.Serializable judiciously
==> Item 9: Always override toString()
==> Item 10: Override clone judiciously
==> Item 15: Design and document for inheritance or else prohibit it
==> Item 17: Use interfaces only to define types
==> Item 23: Check parameters for validity
==> Item 24: Make defensive copies when needed
==> Item 25: Design method signatures carefully
==> Item 27: Return zero-length arrays, not nulls
==> Item 28: Write doc comments for all exposed API elements
==> Item 38: Adhere to generally accepted naming conventions
==> Item 47: Don't ignore exceptions
-Sean
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] patches for Cookie.java, TestCookie.java
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
>I updated the code for the HttpClient:
>
> Cookie.java
> TestCookie.java
>
>
>The modification changes the behavior of Cookie.getExpiryDate
>
>Instead of returning the internal Date object, we return a freshly
>instantiated Date object.
>
>Why: Because java.util.Date is a mutable object.
>
>I created the patch files using this command:
>
> cvs diff -c Foo.java > Foo.patch
>
> -Sean
>
Hi Sean,
I'm not sure that the original behaviour is flawed as coded.
The patch implies that passing setExpiryDate a Date object and then
changing that object is a 'bad thing'. But this is the existing
behaviour, so under the current code, I can do this:
// uncompiled untested code
Date d = new Date();
cookie.setExpiryDate(d);
d.setTime(System.currentTimeMillis());
and based on the current code set, I expect the expiry date of the
cookie to have changed. And ditto, on calling getExpiryDate() I expect
to be able to change the Date and have it reflected in the cookie.
The patch is effectively a change in the implied contract between httpclient and the user....Comments?
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] patches for HttpClient.java, HttpConnection.java
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
>
> I updated the code for the HttpClient:
>
> HttpClient.java
> HttpConnection.java
>
>Patch files attached.
>
> I created the patch files using this command:
>
> cvs diff -c Foo.java > Foo.patch
>
>-Sean
>
Hi Sean,
for the HttpConnection patch, you've used a throw new
NullPointerException. From an API point of view, this makes more sense
(IMHO) as a IllegalArgumentException. What do you think?
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] patch for GetMethod.java, recycle() method in GetMethod class
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
> jakarta-commons httpclient inquiry + patch:
>
>The HttpMethod interface declares a method called
>recycle():
>
>----------------
>
> /**
> * Recycle this method so that it can be used again.
> * Note that all of my instance variables will be reset
> * once this method has been called.
> */
> public void recycle();
>
>----------------
>
>The GetMethod class implements the HttpMethod interface
>and the recycle method:
>
>#################
>
> // override recycle to reset redirects default
> public void recycle() {
> super.recycle();
> setFollowRedirects(true);
> }
>
>################
>
>
>GetMethod.recycle() does not reset its instance variables properly.
>
>I am attaching a patch for GetMethod.java (patch file: GetMethod.patch)
>
>Cheers,
>
>-Sean
>
Applied....
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[httpclient] patch for GetMethod.java, recycle() method in GetMethod class
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
jakarta-commons httpclient inquiry + patch:
The HttpMethod interface declares a method called
recycle():
----------------
/**
* Recycle this method so that it can be used again.
* Note that all of my instance variables will be reset
* once this method has been called.
*/
public void recycle();
----------------
The GetMethod class implements the HttpMethod interface
and the recycle method:
#################
// override recycle to reset redirects default
public void recycle() {
super.recycle();
setFollowRedirects(true);
}
################
GetMethod.recycle() does not reset its instance variables properly.
I am attaching a patch for GetMethod.java (patch file: GetMethod.patch)
Cheers,
-Sean
Re: [httpclient] question regarding HttpMethod interface: getResponseBody method
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
>From: "dIon Gillard" <di...@multitask.com.au>
>
>
>>Sean C. Sullivan wrote:
>>
>>>Currently, HttpMethod.java (an interface) defines a
>>>method called "getResponseBody":
>>>
>>> /**
>>> * Return my response body, if any,
>>> * as a byte array.
>>> * Otherwise return <tt>null</tt>.
>>> */
>>> public byte[] getResponseBody();
>>>
>>>
>>>I would prefer if this method returns a zero-length array instead
>>>of null.
>>>
>>>Returning a zero-length array is one of the API design tips that
>>>is recommended in Josh Bloch's book:
>>>
>>> Effective Java Programming Language Guide
>>> http://www.amazon.com/exec/obidos/ASIN/0201310058/
>>>
>>>
>>>==> Item 27: Return zero-length arrays, not nulls
>>>
>>given I don't have the book handy, this doesn't make for a very
>>convincing argument as to why we should change the API. [...]
>>
>>Can you please provide some more info on why you'd like the change?
>>
>
>First, I want the behavior of getResponseBody to be consistent with
>the behavior of other "standard" (java.*) classes.
>
>Example 1: java.util.Vector.toArray
>
> The return value, Object[], will never be null.
>
>Example 2: java.lang.String.getBytes
>
> The return value, byte[], will never be null.
>
>In Josh Bloch's book, "Effective Java Programming Language Guide",
>Item 27 states:
>
> Return zero-length arrays, not nulls
>
>Rationale:
>
>If the method sometimes returns null and other times returns a non-null array,
>the programmer is forced to always check for null.
>
>With the current HttpMethod interface, programmers must write:
>
> byte[] result = hm.getResponseBody();
> if (result != null)
> {
> processBody(result);
> }
>
>If we return a zero-length array instead of null, programmers can write:
>
> byte[] result = hm.getResponseBody();
> processBody(result);
>
>>As well, the current api documents returning null. Which is cheaper from the
>>
>JVM
>
>>perspective than creating a new byte array.
>>
>
>Bloch (page 134) writes:
>
> "It is sometimes argued that a null return value is preferable to a
>zero-length
> array because it avoids the expense of allocating the array. This argument
>fails
> on two counts. First, it is inadvisable to worry about performance at this
>level
> unless profiling has shown that the method in question is a real contributor
>to
> performance problems. Second, it is possible to return the same zero-length
> array from every invocation that returns no items because zero-length arrays
> are immutable and immutable objects may be shared freely."
>
>Solution: declare a static zero-length array variable
>
> private final static byte[] ZERO_LENGTH_BYTE_ARRAY = new byte[0];
>
>Regards,
>
This assumes that there is no difference between null (no response body
exists) vs a returned response of length 0. I'm not sure this is the
case and I think we do need to differentiate between the two.
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] question regarding HttpMethod interface: getResponseBody method
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
From: "dIon Gillard" <di...@multitask.com.au>
>
> Sean C. Sullivan wrote:
>
> >Currently, HttpMethod.java (an interface) defines a
> >method called "getResponseBody":
> >
> > /**
> > * Return my response body, if any,
> > * as a byte array.
> > * Otherwise return <tt>null</tt>.
> > */
> > public byte[] getResponseBody();
> >
> >
> >I would prefer if this method returns a zero-length array instead
> >of null.
> >
> >Returning a zero-length array is one of the API design tips that
> >is recommended in Josh Bloch's book:
> >
> > Effective Java Programming Language Guide
> > http://www.amazon.com/exec/obidos/ASIN/0201310058/
> >
> >
> >==> Item 27: Return zero-length arrays, not nulls
> >
>
> given I don't have the book handy, this doesn't make for a very
> convincing argument as to why we should change the API. [...]
>
> Can you please provide some more info on why you'd like the change?
>
First, I want the behavior of getResponseBody to be consistent with
the behavior of other "standard" (java.*) classes.
Example 1: java.util.Vector.toArray
The return value, Object[], will never be null.
Example 2: java.lang.String.getBytes
The return value, byte[], will never be null.
In Josh Bloch's book, "Effective Java Programming Language Guide",
Item 27 states:
Return zero-length arrays, not nulls
Rationale:
If the method sometimes returns null and other times returns a non-null array,
the programmer is forced to always check for null.
With the current HttpMethod interface, programmers must write:
byte[] result = hm.getResponseBody();
if (result != null)
{
processBody(result);
}
If we return a zero-length array instead of null, programmers can write:
byte[] result = hm.getResponseBody();
processBody(result);
> As well, the current api documents returning null. Which is cheaper from the
JVM
> perspective than creating a new byte array.
Bloch (page 134) writes:
"It is sometimes argued that a null return value is preferable to a
zero-length
array because it avoids the expense of allocating the array. This argument
fails
on two counts. First, it is inadvisable to worry about performance at this
level
unless profiling has shown that the method in question is a real contributor
to
performance problems. Second, it is possible to return the same zero-length
array from every invocation that returns no items because zero-length arrays
are immutable and immutable objects may be shared freely."
Solution: declare a static zero-length array variable
private final static byte[] ZERO_LENGTH_BYTE_ARRAY = new byte[0];
Regards,
-Sean
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] question regarding HttpMethod interface: getResponseBody method
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
>jakarta-commons httpclient inquiry:
>
>
>Currently, HttpMethod.java (an interface) defines a
>method called "getResponseBody":
>
> /**
> * Return my response body, if any,
> * as a byte array.
> * Otherwise return <tt>null</tt>.
> */
> public byte[] getResponseBody();
>
>
>I would prefer if this method returns a zero-length array instead
>of null.
>
>Returning a zero-length array is one of the API design tips that
>is recommended in Josh Bloch's book:
>
> Effective Java Programming Language Guide
> http://www.amazon.com/exec/obidos/ASIN/0201310058/
>
>
>==> Item 27: Return zero-length arrays, not nulls
>
Hi Sean,
given I don't have the book handy, this doesn't make for a very
convincing argument as to why we should change the API. As well, the
current api documents returning null. Which is cheaper from the JVM
perspective than creating a new byte array.
Can you please provide some more info on why you'd like the change?
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] minimum supported JDK version
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
>What is the minimum supported JDK version for
>the HttpClient class library?
>
From status.html, JDK 1.2 for run time, although the 'external'
interface is 1.1 compliant.
>
>
>Will HttpClient run on JDK 1.1.x?
>
Not sure. I'm certain it won't compile on it. Use of List etc...
>
>
>Is the intent to avoid using any JDK 1.2.x features
>so that the library will run on JDK 1.1.x?
>
Not AFAIK.
>I have some changes that I'd like to make to HttpClient.
>My changes assume that JDK 1.2.x is the minimum JDK environment.
>
>Please advise.
>
>Regards,
>
>-Sean
>
Could you also try to include some more info with your patches on
why/what is being patched. It's hard sometimes to have to read the patch
and work out what's being changed, rather than a short blurb in the
patch posting itself.
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[httpclient] minimum supported JDK version
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
What is the minimum supported JDK version for
the HttpClient class library?
Will HttpClient run on JDK 1.1.x?
Is the intent to avoid using any JDK 1.2.x features
so that the library will run on JDK 1.1.x?
I have some changes that I'd like to make to HttpClient.
My changes assume that JDK 1.2.x is the minimum JDK environment.
Please advise.
Regards,
-Sean
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[httpclient] question regarding HttpMethod interface: getResponseBody method
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
jakarta-commons httpclient inquiry:
Currently, HttpMethod.java (an interface) defines a
method called "getResponseBody":
/**
* Return my response body, if any,
* as a byte array.
* Otherwise return <tt>null</tt>.
*/
public byte[] getResponseBody();
I would prefer if this method returns a zero-length array instead
of null.
Returning a zero-length array is one of the API design tips that
is recommended in Josh Bloch's book:
Effective Java Programming Language Guide
http://www.amazon.com/exec/obidos/ASIN/0201310058/
==> Item 27: Return zero-length arrays, not nulls
Regards,
-Sean
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[httpclient] parameter validation, NullPointerException vs IllegalArgumentException
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
From: "dIon Gillard" <di...@multitask.com.au>
>
> Sean C. Sullivan wrote:
>
> >NameValuePair.java
> >
> >--------------------------
> >
> > /**
> > * Constructor.
> > */
> > public NameValuePair(String name, String value) {
> >
> > this.name = name;
> > this.value = value;
> >
> > }
> >
> >--------------------------
> >
> >With this constructor, it is allowable for a caller to do this:
> >
> > NameValuePair nvp = new NameValuePair(null, null);
> >
> >I would prefer if the NameValuePair constructor did not allow null
parameters.
> >
> >I prefer this constructor:
> >
> > /**
> > * Constructor.
> > */
> > public NameValuePair(String name, String value) {
> >
> > if (null == name) {
> > throw new NullPointerException("name parameter is null");
> > }
> > if (null == value) {
> > throw new NullPointerException("value parameter is null");
> > }
> >
> > this.name = name;
> > this.value = value;
> >
> > }
> >
> >
> Again,
>
> my call would be if these are illegal arguments, it should throw
> IllegalArgumentException, not NullPointerException.
In the core Java packages (java.*), Sun throws a NullPointerException
when a null parameter is unexpectedly detected:
Example: java/io/File.java
////////////////////
public File(String pathname) {
if (pathname == null) {
throw new NullPointerException();
}
/// .... etc .....
}
//////////
Also, Josh Bloch recommends throwing a NullPointerException
when a parameter is unexpectedly null ( "Item 23: Check Parameters for
Validity", [1], pages 120-121 ).
-Sean
[1] Effective Java Programming Language Guide by Josh Bloch
http://www.amazon.com/exec/obidos/ASIN/0201310058/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [httpclient] question regarding NameValuePair constructor, null parameters
Posted by Michael Smith <mi...@iammichael.org>.
From: dIon Gillard [mailto:dion@multitask.com.au]
> my call would be if these are illegal arguments, it should throw
> IllegalArgumentException, not NullPointerException.
NullPointerException makes perfect sense in that case. The API
documentation for NullPointerException specifically states it should be
used to indicate an illegal use of a null object. While
IllegalArgumentException is also applicable in the same sense -- an
illegal value. The difference, for me at least, is that a
NullPointerException provide more specific information as to what the
problem is. It's also more common in the JDK to see
NullPointerException thrown when a null argument is passed. In fact, I
can't think of any places where an IllegalArgumentException is thrown
when a null argument is passed, but know of a few where both are
declared (one for invalid objects passed in, and the other when a null
is passed).
For example:
http://java.sun.com/j2se/1.3/docs/api/java/lang/reflect/Array.html#get(j
ava.lang.Object,%20int)
declares it throws IllegalArgumentException *and* NullPointerException.
NullPointer if the arg is null, and IllegalArgument if the arg is not an
array.
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] question regarding NameValuePair constructor, null parameters
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
>Jakarta-commons HttpClient inquiry:
>
>Why does the NameValuePair constructor allow
>null parameters?
>
>This is how the code currently looks:
>
>NameValuePair.java
>
>--------------------------
>
> /**
> * Constructor.
> */
> public NameValuePair(String name, String value) {
>
> this.name = name;
> this.value = value;
>
> }
>
>--------------------------
>
>With this constructor, it is allowable for a caller to do this:
>
> NameValuePair nvp = new NameValuePair(null, null);
>
>I would prefer if the NameValuePair constructor did not allow null parameters.
>
>I prefer this constructor:
>
> /**
> * Constructor.
> */
> public NameValuePair(String name, String value) {
>
> if (null == name) {
> throw new NullPointerException("name parameter is null");
> }
> if (null == value) {
> throw new NullPointerException("value parameter is null");
> }
>
> this.name = name;
> this.value = value;
>
> }
>
>
Again,
my call would be if these are illegal arguments, it should throw
IllegalArgumentException, not NullPointerException.
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[httpclient] question regarding NameValuePair constructor, null parameters
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
Jakarta-commons HttpClient inquiry:
Why does the NameValuePair constructor allow
null parameters?
This is how the code currently looks:
NameValuePair.java
--------------------------
/**
* Constructor.
*/
public NameValuePair(String name, String value) {
this.name = name;
this.value = value;
}
--------------------------
With this constructor, it is allowable for a caller to do this:
NameValuePair nvp = new NameValuePair(null, null);
I would prefer if the NameValuePair constructor did not allow null parameters.
I prefer this constructor:
/**
* Constructor.
*/
public NameValuePair(String name, String value) {
if (null == name) {
throw new NullPointerException("name parameter is null");
}
if (null == value) {
throw new NullPointerException("value parameter is null");
}
this.name = name;
this.value = value;
}
Regards,
-Sean
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] patch for HttpMethodBase.java
Posted by dIon Gillard <di...@multitask.com.au>.
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 for null parameters
>
> updated javadoc comments for: execute
>
> added "log.isDebugEnabled" for each log.debug statement
>
>
>I executed the tests and everything passed.
>
>-Sean
>
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[httpclient] patch for RequestOutputStream.java
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
Here is another patch for RequestOutputStream.java
A patch file is attached.
I created the patch file using this command:
cvs diff -u Foo.java > Foo.patch
Changes in RequestOutputStream:
updated the class javadoc with an "@see"
fixed erroneous javadoc parameter comments
the method "public void print(String)" will no longer accept a null
parameter
I executed the tests and everything passed.
-Sean
Re: [httpclient] patches for RequestOutputStream.java, ResponseInputStream.java
Posted by dIon Gillard <di...@multitask.com.au>.
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 for Sean C. Sullivan
>
> fixed the erroneous comment for the OutputStream member variable
>
> the close() method now makes use of the "close" member variable
>
Applied.
>
>
>Changes in ResponseInputStream:
>
> removed email address for Sean C. Sullivan
>
> added method: public boolean isUsingChunking
>
Only applied removal of email address as method (isUsingChunking) is not
called anywhere.
>
>I executed the tests and everything passed.
>
> -Sean
>
Thanks again.
>
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[httpclient] patches for RequestOutputStream.java, ResponseInputStream.java
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
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 for Sean C. Sullivan
fixed the erroneous comment for the OutputStream member variable
the close() method now makes use of the "close" member variable
Changes in ResponseInputStream:
removed email address for Sean C. Sullivan
added method: public boolean isUsingChunking
I executed the tests and everything passed.
-Sean
[httpclient] patch for HttpMethodBase.java
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
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 for null parameters
updated javadoc comments for: execute
added "log.isDebugEnabled" for each log.debug statement
I executed the tests and everything passed.
-Sean
Re: [httpclient] patch for HttpClient.java
Posted by dIon Gillard <di...@multitask.com.au>.
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 parameter.
>
> executeMethod will now throw an IllegalStateException if the
> session has not been started
>
> updated javadoc comments for: getState, setState, startSession,
>endSession,
> and executeMethod
>
>I executed the tests and everything passed.
>
>-Sean
>
>
>------------------------------------------------------------------------
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[httpclient] patch for HttpClient.java
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
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 parameter.
executeMethod will now throw an IllegalStateException if the
session has not been started
updated javadoc comments for: getState, setState, startSession,
endSession,
and executeMethod
I executed the tests and everything passed.
-Sean
Re: [httpclient] patch for RequestInputStream.java
Posted by dIon Gillard <di...@multitask.com.au>.
Applied,
thanks!
Sean C. Sullivan wrote:
>This is a patch for RequestInputStream.java
>
>The patch file is attached.
>
> I created the patch files using this command:
>
> cvs diff -u Foo.java > Foo.patch
>
> Changes:
>
> Bug fix: One of the constructors was ignoring the InputStream parameter.
> Added javadoc comments to one of the constructors.
> In both constructors: check for null parameters
>
> I executed the tests and everything passed.
>
> -Sean
>
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[httpclient] patch for RequestInputStream.java
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
This is a patch for RequestInputStream.java
The patch file is attached.
I created the patch files using this command:
cvs diff -u Foo.java > Foo.patch
Changes:
Bug fix: One of the constructors was ignoring the InputStream parameter.
Added javadoc comments to one of the constructors.
In both constructors: check for null parameters
I executed the tests and everything passed.
-Sean
Re: [httpclient] patch for RequestOutputStream.java
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
>I updated the code for the RequestOutputStream.java
>
>A patch file is attached.
>
> I created the patch files using this command:
>
> cvs diff -u Foo.java > Foo.patch
>
>Changes:
>
> The simple 1 arg constructor now calls the 2 arg constructor.
> In the 2 arg constructor, throw NullPointerException if the stream parameter
>is null.
> Changed some private variables to "private static final".
>
>I executed the tests and everything passed.
>
Cool, and thanks. My only hassle is that the code uses stuff like
"0".getBytes() to initialize a byte array. I'm not particularly thrilled
that this is the most readable and efficient way of doing the
initialization. I'll look into it and see what the differences between
that and a simple new byte[] {'0'} are.
>
>
>-Sean
>
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] patch for RequestOutputStream.java
Posted by dIon Gillard <di...@multitask.com.au>.
Patches applied,
thanks!
Sean C. Sullivan wrote:
>I updated the code for the RequestOutputStream.java
>
>A patch file is attached.
>
> I created the patch files using this command:
>
> cvs diff -u Foo.java > Foo.patch
>
>Changes:
>
> The simple 1 arg constructor now calls the 2 arg constructor.
> In the 2 arg constructor, throw NullPointerException if the stream parameter
>is null.
> Changed some private variables to "private static final".
>
>I executed the tests and everything passed.
>
>-Sean
>
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[httpclient] patch for RequestOutputStream.java
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
I updated the code for the RequestOutputStream.java
A patch file is attached.
I created the patch files using this command:
cvs diff -u Foo.java > Foo.patch
Changes:
The simple 1 arg constructor now calls the 2 arg constructor.
In the 2 arg constructor, throw NullPointerException if the stream parameter
is null.
Changed some private variables to "private static final".
I executed the tests and everything passed.
-Sean
Re: [httpclient] patches for HttpClient.java, HttpConnection.java
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
>
> I updated the code for the HttpClient:
>
> HttpClient.java
> HttpConnection.java
>
>Patch files attached.
>
> I created the patch files using this command:
>
> cvs diff -c Foo.java > Foo.patch
>
>-Sean
>
I've applied the HttpClient patch. Will do the HttpConnection patch
soon. However, one thing I've noticed is that the formatting of the code
doesn't match the patch, i.e. I have to manually go fix code formatting
once the patch is applied.
Also, as per the getting involved guidelines, if you could submit the
patches with -u rather than -c, that would make life easier. I'm also
making sure that the code compiles after the patch, and rerunning the
test suites (the ones that work behind the firewall @ work) before
committing. I'd be a lot more comfortable if I knew you'd done it first.
Thanks!
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[httpclient] patches for HttpClient.java, HttpConnection.java
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
I updated the code for the HttpClient:
HttpClient.java
HttpConnection.java
Patch files attached.
I created the patch files using this command:
cvs diff -c Foo.java > Foo.patch
-Sean
[httpclient] patches for Cookie.java, TestCookie.java
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
I updated the code for the HttpClient:
Cookie.java
TestCookie.java
The modification changes the behavior of Cookie.getExpiryDate
Instead of returning the internal Date object, we return a freshly
instantiated Date object.
Why: Because java.util.Date is a mutable object.
I created the patch files using this command:
cvs diff -c Foo.java > Foo.patch
-Sean