cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections CursorableLinkedList.java StaticBucketMap.java DefaultMapBag.java ExtendedProperties.java
scolebourne2003/06/20 01:00:00
Modified:collections/src/java/org/apache/commons/collections
CursorableLinkedList.java StaticBucketMap.java
DefaultMapBag.java ExtendedProperties.java
Log:
Converted inner classes to static nested classes where possible
From Janek Bogucki
Revision ChangesPath
1.13 +5 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/CursorableLinkedList.java
Index: CursorableLinkedList.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/CursorableLinkedList.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- CursorableLinkedList.java 11 May 2003 14:15:23 - 1.12
+++ CursorableLinkedList.java 20 Jun 2003 07:59:59 - 1.13
@@ -87,6 +87,7 @@
* @version $Revision$ $Date$
*
* @author Rodney Waldhoff
+ * @author Janek Bogucki
*/
public class CursorableLinkedList implements List, Serializable {
// TODO: use weak references to cursors in case they aren't closed directly
@@ -942,7 +943,7 @@
//--- inner classes --
-class Listable implements Serializable {
+static class Listable implements Serializable {
private Listable _prev = null;
private Listable _next = null;
private Object _val = null;
@@ -1092,7 +1093,7 @@
}
}
-public class Cursor extends ListIter implements ListIterator {
+class Cursor extends ListIter implements ListIterator {
boolean _valid = false;
Cursor(int index) {
1.10 +4 -3
jakarta-commons/collections/src/java/org/apache/commons/collections/StaticBucketMap.java
Index: StaticBucketMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/StaticBucketMap.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- StaticBucketMap.java 16 May 2003 14:58:42 - 1.9
+++ StaticBucketMap.java 20 Jun 2003 07:59:59 - 1.10
@@ -137,6 +137,7 @@
* @author a href=mailto:[EMAIL PROTECTED]Michael A. Smith/a
* @author Paul Jack
* @author Leo Sutic
+ * @author Janek Bogucki
*/
public final class StaticBucketMap implements Map {
@@ -489,7 +490,7 @@
/**
* The Map.Entry for the StaticBucketMap.
*/
-private final class Node implements Map.Entry
+private static final class Node implements Map.Entry
{
protected Object key;
protected Object value;
1.9 +4 -3
jakarta-commons/collections/src/java/org/apache/commons/collections/DefaultMapBag.java
Index: DefaultMapBag.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/DefaultMapBag.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- DefaultMapBag.java16 May 2003 14:24:55 - 1.8
+++ DefaultMapBag.java20 Jun 2003 07:59:59 - 1.9
@@ -83,6 +83,7 @@
* @author Chuck Burdick
* @author a href=mailto:[EMAIL PROTECTED]Michael A. Smith/a
* @author Stephen Colebourne
+ * @author Janek Bogucki
*/
public abstract class DefaultMapBag implements Bag {
private Map _map = null;
@@ -240,7 +241,7 @@
return new BagIterator(this, extractList().iterator());
}
-private class BagIterator implements Iterator {
+static class BagIterator implements Iterator {
private DefaultMapBag _parent = null;
private Iterator _support = null;
private Object _current = null;
1.12 +5 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/ExtendedProperties.java
Index: ExtendedProperties.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/ExtendedProperties.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- ExtendedProperties.java 16 May 2003 14:36:40 - 1.11
+++ ExtendedProperties.java 20 Jun 2003 07:59:59 - 1.12
@@ -169,6 +169,7 @@
* @author a href=mailto:[EMAIL PROTECTED]Kent Johnson/a
* @author a href=mailto:[EMAIL PROTECTED]Daniel Rall/a
* @author a href=mailto:[EMAIL PROTECTED]Ilkka Priha/a
+ * @author Janek Bogucki
*/
public class ExtendedProperties extends Hashtable {
@@ -254,7 +255,7 @@
* backslash sign a the end of the line. This is used to
* concatenate multiple lines
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang ArrayUtils.java
scolebourne2003/06/20 01:03:51
Modified:lang/src/java/org/apache/commons/lang ArrayUtils.java
Log:
Remove unused code
Revision ChangesPath
1.13 +1 -106
jakarta-commons/lang/src/java/org/apache/commons/lang/ArrayUtils.java
Index: ArrayUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/ArrayUtils.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- ArrayUtils.java 16 Jun 2003 02:28:16 - 1.12
+++ ArrayUtils.java 20 Jun 2003 08:03:51 - 1.13
@@ -220,111 +220,6 @@
return map;
}
-///**
-// * pOutput the array as a String./p
-// *
-// * pMulti-dimensional arrays are handled by the Object[] method./p
-// *
-// * pThe format is that of Java source code, for example {1,2}./p
-// *
-// * @param array the array to get a toString for, must not be
codenull/code
-// * @return a String representation of the array
-// * @throws IllegalArgumentException if the array is codenull/code
-// */
-//public static String toString(long[] array) {
-//return new ToStringBuilder(array,
ToStringStyle.SIMPLE_STYLE).append(array).toString();
-//}
-//
-///**
-// * pOutput the array as a String./p
-// *
-// * pMulti-dimensional arrays are handled by the Object[] method./p
-// *
-// * pThe format is that of Java source code, for example {1,2}./p
-// *
-// * @param array the array to get a toString for, must not be
codenull/code
-// * @return a String representation of the array
-// * @throws IllegalArgumentException if the array is codenull/code
-// */
-//public static String toString(int[] array) {
-//return new ToStringBuilder(array,
ToStringStyle.SIMPLE_STYLE).append(array).toString();
-//}
-//
-///**
-// * pOutput the array as a String./p
-// *
-// * pMulti-dimensional arrays are handled by the Object[] method./p
-// *
-// * pThe format is that of Java source code, for example {1,2}./p
-// *
-// * @param array the array to get a toString for, must not be
codenull/code
-// * @return a String representation of the array
-// * @throws IllegalArgumentException if the array is codenull/code
-// */
-//public static String toString(short[] array) {
-//return new ToStringBuilder(array,
ToStringStyle.SIMPLE_STYLE).append(array).toString();
-//}
-//
-///**
-// * pOutput the array as a String./p
-// *
-// * pMulti-dimensional arrays are handled by the Object[] method./p
-// *
-// * pThe format is that of Java source code, for example {1,2}./p
-// *
-// * @param array the array to get a toString for, must not be
codenull/code
-// * @return a String representation of the array
-// * @throws IllegalArgumentException if the array is codenull/code
-// */
-//public static String toString(byte[] array) {
-//return new ToStringBuilder(array,
ToStringStyle.SIMPLE_STYLE).append(array).toString();
-//}
-//
-///**
-// * pOutput the array as a String./p
-// *
-// * pMulti-dimensional arrays are handled by the Object[] method./p
-// *
-// * pThe format is that of Java source code, for example {1.0,2.0}./p
-// *
-// * @param array the array to get a toString for, must not be
codenull/code
-// * @return a String representation of the array
-// * @throws IllegalArgumentException if the array is codenull/code
-// */
-//public static String toString(double[] array) {
-//return new ToStringBuilder(array,
ToStringStyle.SIMPLE_STYLE).append(array).toString();
-//}
-//
-///**
-// * pOutput the array as a String./p
-// *
-// * pMulti-dimensional arrays are handled by the Object[] method./p
-// *
-// * pThe format is that of Java source code, for example {1.0,2.0}./p
-// *
-// * @param array the array to get a toString for, must not be
codenull/code
-// * @return a String representation of the array
-// * @throws IllegalArgumentException if the array is codenull/code
-// */
-//public static String toString(float[] array) {
-//return new ToStringBuilder(array,
ToStringStyle.SIMPLE_STYLE).append(array).toString();
-//}
-//
-///**
-// * pOutput the array as a String./p
-// *
-// * pMulti-dimensional arrays are handled by the Object[] method./p
-// *
-// * pThe format is that of Java source code, for example {true,false}./p
-// *
-// * @param array the array to get a toString for, must not be
codenull/code
-// *
DO NOT REPLY [Bug 14120] - [FileUpload] uploading files with non-ASCII filenames
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14120. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14120 [FileUpload] uploading files with non-ASCII filenames --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 08:49 --- I would like to know, when will this 'added interfaces' refrect to Struts? Now, 'Struts 1.1 Release Candidate 2 Released' doesn't call 'setHeaderEncoding ()'. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] {@link} tag for constructor with parameters?
Does anyone know how to make a [EMAIL PROTECTED] work for a constructor with parameters? I tried fixing a [EMAIL PROTECTED] tag in DefaultMapBag: * (or invoke the [EMAIL PROTECTED] #DefaultMapBag(java.util.Map) Map-constructor}) but I couldn't make it work. This is the warning generated when doing '$ ant doc' on tonight's CVS version: [javadoc] javadoc: warning - org.apache.commons.collections.DefaultMapBag: Tag @link: can't find DefaultMapBag(java.util.Map) in org.apache.commons.collections.DefaultMapBag I have tried RTFM but failed to see anything amiss with the tag. I get the same result with both Java 1.3 and 1.4. -Janek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] {@link} tag for constructor with parameters?
Maybe #init(java.util.Map) ?? Stephen from:Janek Bogucki [EMAIL PROTECTED] date:Fri, 20 Jun 2003 02:47:57 to: [EMAIL PROTECTED] subject: Re: [collections] [EMAIL PROTECTED] tag for constructor with parameters? Does anyone know how to make a [EMAIL PROTECTED] work for a constructor with parameters? I tried fixing a [EMAIL PROTECTED] tag in DefaultMapBag: * (or invoke the [EMAIL PROTECTED] #DefaultMapBag(java.util.Map) Map-constructor}) but I couldn't make it work. This is the warning generated when doing '$ ant doc' on tonight's CVS version: [javadoc] javadoc: warning - org.apache.commons.collections.DefaultMapBag: Tag @link: can't find DefaultMapBag(java.util.Map) in org.apache.commons.collections.DefaultMapBag I have tried RTFM but failed to see anything amiss with the tag. I get the same result with both Java 1.3 and 1.4. -Janek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] {@link} tag for constructor with parameters?
On Fri, 2003-06-20 at 09:23, [EMAIL PROTECTED] wrote: Maybe #init(java.util.Map) ?? Stephen There is nothing wrong with the [EMAIL PROTECTED] tag. Changing the constructor access modifier from protected to public allowed the [EMAIL PROTECTED] tag to work. -Janek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Clazz] subclassing vs. configuration (Was: Extending Clazz)
Dmitry: 2. The reason all those things are implemented as subclasses rather than configuration-based instances is precisely to avoid the need for configuration. In any complex environment you are working with lots of ClassLoaders, which are allocated by some container. A ClazzLoader is automatically allocated by Clazz for each ClassLoader as needed. Where would we put the hook for configuration? Victor: But the fifth step, adding the new ClazzLoader, _is_ a configuration anyway. Dmitry: It's done at the factory level: you register your custom ClazzLoader class (not instance) with a ClazzLoaderFactory. The factory will instantiate it as needed. Sorry, I do not understand it. You do not want configuration because you are not sure where to put the configuration hook. But where (in my client code) do I register the ClazzLoader class. Here I have the configuration hook. Or is the problem based on registering a ClazzLoader class and not an instance? I have further looked into the code and the problem seems to be based on creating a ClazzLoader (zz) instance for each ClassLoader (ss). Is this necessary? Why not have another getClazzForName(String) method that takes a ClassLoader? getClazzForName(String, ClassLoader) Wouldn't that be much simpler? Victor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP] Build Failure - commons-codec
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-06-20/commons-codec.html
Buildfile: build.xml
init:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/codec/target/lib
get-deps:
compile:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/codec/target/classes
[javac] Compiling 15 source files to
/home/rubys/jakarta/jakarta-commons/codec/target/classes
compile-tests:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/codec/target/test-classes
[javac] Compiling 9 source files to
/home/rubys/jakarta/jakarta-commons/codec/target/test-classes
[javac]
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/base64/Base64Test.java:67:
package junit.framework does not exist
[javac] import junit.framework.Test;
[javac]^
[javac]
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/base64/Base64Test.java:68:
package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac]
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/base64/Base64Test.java:69:
package junit.framework does not exist
[javac] import junit.framework.TestSuite;
[javac]^
[javac]
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/base64/Base64Test.java:76:
cannot resolve symbol
[javac] symbol : class TestCase
[javac] location: class org.apache.commons.codec.base64.Base64Test
[javac] public class Base64Test extends TestCase {
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/base64/Base64Test.java:98:
cannot resolve symbol
[javac] symbol : class Test
[javac] location: class org.apache.commons.codec.base64.Base64Test
[javac] public static Test suite() {
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/binary/Base64Test.java:67:
package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac]
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/binary/Base64Test.java:76:
cannot resolve symbol
[javac] symbol : class TestCase
[javac] location: class org.apache.commons.codec.binary.Base64Test
[javac] public class Base64Test extends TestCase {
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/binary/HexTest.java:66:
package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac]
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/binary/HexTest.java:74:
cannot resolve symbol
[javac] symbol : class TestCase
[javac] location: class org.apache.commons.codec.binary.HexTest
[javac] public class HexTest extends TestCase {
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/language/RefinedSoundexTest.java:63:
package junit.framework does not exist
[javac] import junit.framework.Test;
[javac]^
[javac]
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/language/RefinedSoundexTest.java:64:
package junit.framework does not exist
[javac] import junit.framework.TestSuite;
[javac]^
[javac]
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/language/RefinedSoundexTest.java:66:
cannot resolve symbol
[javac] symbol : class StringEncoder
[javac] location: package codec
[javac] import org.apache.commons.codec.StringEncoder;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/StringEncoderAbstractTest.java:63:
package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac]
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/StringEncoderAbstractTest.java:70:
cannot resolve symbol
[javac] symbol : class TestCase
[javac] location: class org.apache.commons.codec.StringEncoderAbstractTest
[javac] public abstract class StringEncoderAbstractTest extends TestCase {
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/language/RefinedSoundexTest.java:79:
cannot resolve symbol
[javac] symbol : class Test
[javac] location: class
Re: [collections] {@link} tag for constructor with parameters?
A name in the Java Language, namely the name of a package, class, interface, field, constructor or method. A name can be fully-qualified, such as java.lang.String.equals(java.lang.Object), or partially-qualified, such as equals(Object). It must work: @link #DefaultMapBag(java.util.Map) - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 20, 2003 11:23 AM Subject: Re: [collections] [EMAIL PROTECTED] tag for constructor with parameters? Maybe #init(java.util.Map) ?? Stephen from:Janek Bogucki [EMAIL PROTECTED] date:Fri, 20 Jun 2003 02:47:57 to: [EMAIL PROTECTED] subject: Re: [collections] [EMAIL PROTECTED] tag for constructor with parameters? Does anyone know how to make a [EMAIL PROTECTED] work for a constructor with parameters? I tried fixing a [EMAIL PROTECTED] tag in DefaultMapBag: * (or invoke the [EMAIL PROTECTED] #DefaultMapBag(java.util.Map) Map-constructor}) but I couldn't make it work. This is the warning generated when doing '$ ant doc' on tonight's CVS version: [javadoc] javadoc: warning - org.apache.commons.collections.DefaultMapBag: Tag @link: can't find DefaultMapBag(java.util.Map) in org.apache.commons.collections.DefaultMapBag I have tried RTFM but failed to see anything amiss with the tag. I get the same result with both Java 1.3 and 1.4. -Janek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] {@link} tag for constructor with parameters?
On Fri, 2003-06-20 at 11:16, Janek Bogucki wrote:
There is nothing wrong with the [EMAIL PROTECTED] tag. Changing the constructor
access modifier from protected to public allowed the [EMAIL PROTECTED] tag to
work.
-Janek
This diff gets it working without having to modify DefaultMapBag.java.
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-commons/collections/build.xml,v
retrieving revision 1.38
diff -u -r1.38 build.xml
--- build.xml 13 Jan 2003 23:54:38 - 1.38
+++ build.xml 20 Jun 2003 10:38:46 -
@@ -180,7 +180,7 @@
windowtitle=${Name-Long}
doctitle=${Name-Long}
bottom=lt;smallgt;Copyright amp;copy; 2001-${year} Apache Software
Foundation. Documenation generated ${TODAY}lt;/smallgt;.
- public=true
+ protected=true
version=true
author=true
overview=${source.src.java}/org/apache/commons/collections/package.html
-Janek
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient HttpMethodBase.java
adrian 2003/06/20 06:30:02
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpMethodBase.java
Log:
Avoids a SocketException being thrown when the Content-Length header is missing.
PR: bug 20938
Reviewed by: Michael Becke and Oleg Kalnichevski
CVS: --
CVS: PR:
CVS: If this change addresses a PR in the problem report tracking
CVS: database, then enter the PR number(s) here.
CVS: Obtained from:
CVS: If this change has been taken from another system, such as NCSA,
CVS: then name the system in this line, otherwise delete it.
CVS: Submitted by:
CVS: If this code has been contributed to Apache by someone else; i.e.,
CVS: they sent us a patch or a new module, then include their name/email
CVS: address here. If this is your work then delete this line.
CVS: Reviewed by:
CVS: If we are doing pre-commit code reviews and someone else has
CVS: reviewed your changes, include their name(s) here.
CVS: If you have not had it reviewed then delete this line.
Revision ChangesPath
1.153 +12 -4
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java
Index: HttpMethodBase.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java,v
retrieving revision 1.152
retrieving revision 1.153
diff -u -r1.152 -r1.153
--- HttpMethodBase.java 13 Jun 2003 21:32:17 - 1.152
+++ HttpMethodBase.java 20 Jun 2003 13:30:02 - 1.153
@@ -880,6 +880,14 @@
*/
protected boolean shouldCloseConnection(HttpConnection conn) {
+// if we are not chunked and there is no content length the connection
+// cannot be reused
+if (responseHeaders.getFirstHeader(Transfer-Encoding) == null
+ getResponseContentLength() 0) {
+LOG.debug(Should close connection as content-length is missing.);
+return true;
+}
+
Header connectionHeader = null;
// In case being connected via a proxy server
if (!conn.isTransparent()) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestResponseHeaders.java
adrian 2003/06/20 06:33:09
Modified:httpclient/src/test/org/apache/commons/httpclient
TestResponseHeaders.java
Log:
Test cases for the fix to bug 20938.
PR: bug 20938
Reviewed by: Michael Becke and Oleg Kalnichevski
CVS: --
CVS: PR:
CVS: If this change addresses a PR in the problem report tracking
CVS: database, then enter the PR number(s) here.
CVS: Obtained from:
CVS: If this change has been taken from another system, such as NCSA,
CVS: then name the system in this line, otherwise delete it.
CVS: Submitted by:
CVS: If this code has been contributed to Apache by someone else; i.e.,
CVS: they sent us a patch or a new module, then include their name/email
CVS: address here. If this is your work then delete this line.
CVS: Reviewed by:
CVS: If we are doing pre-commit code reviews and someone else has
CVS: reviewed your changes, include their name(s) here.
CVS: If you have not had it reviewed then delete this line.
Revision ChangesPath
1.8 +67 -4
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestResponseHeaders.java
Index: TestResponseHeaders.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestResponseHeaders.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- TestResponseHeaders.java 10 Jun 2003 22:42:52 - 1.7
+++ TestResponseHeaders.java 20 Jun 2003 13:33:09 - 1.8
@@ -73,6 +73,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED]Davanum Srinivas/a
* @author a href=mailto:[EMAIL PROTECTED]Jeff Dever/a
+ * @author a href=mailto:[EMAIL PROTECTED]Adrian Sutton/a
* @version $Id$
*/
public class TestResponseHeaders extends TestCase {
@@ -153,6 +154,7 @@
HTTP/1.1 200 OK\r\n
+ proxy-connection: close\r\n
+ proxy-connection: close\r\n
++ Content-Length: 0\r\n
+ \r\n;
conn.addResponse(headers, );
@@ -169,6 +171,7 @@
HTTP/1.0 200 OK\r\n
+ proxy-connection: keep-alive\r\n
+ proxy-connection: keep-alive\r\n
++ Content-Length: 0\r\n
+ \r\n;
conn.addResponse(headers, );
@@ -202,6 +205,7 @@
HTTP/1.0 200 OK\r\n
+Connection: keep-alive\r\n
+Connection: keep-alive\r\n
++ Content-Length: 0\r\n
+\r\n;
conn.addResponse(headers, );
@@ -210,6 +214,65 @@
method.getResponseBodyAsString();
assertTrue(conn.isOpen());
+}
+
+public void testNoContentLength() throws Exception {
+// test with connection header
+SimpleHttpConnection conn = new SimpleHttpConnection();
+String headers =
+HTTP/1.1 200 OK\r\n
++ Connection: keep-alive\r\n
++ \r\n;
+
+conn.addResponse(headers, 12345);
+GetMethod method = new GetMethod(/);
+method.execute(new HttpState(), conn);
+method.getResponseBodyAsString();
+
+assertFalse(conn.isOpen());
+
+// test without connection header
+conn = new SimpleHttpConnection();
+headers = HTTP/1.1 200 OK\r\n\r\n;
+
+// test with connection header
+conn.addResponse(headers, 12345);
+method = new GetMethod(/);
+method.execute(new HttpState(), conn);
+method.getResponseBodyAsString();
+
+assertFalse(conn.isOpen());
+}
+
+public void testProxyNoContentLength() throws Exception {
+// test with proxy-connection header
+SimpleHttpConnection conn = new SimpleHttpConnection();
+String headers =
+HTTP/1.1 200 OK\r\n
++ proxy-connection: keep-alive\r\n
++ \r\n;
+
+conn.addResponse(headers, 12345);
+conn.setProxyHost(proxy);
+conn.setProxyPort(1);
+GetMethod method = new GetMethod(/);
+method.execute(new HttpState(), conn);
+method.getResponseBodyAsString();
+
+assertFalse(conn.isOpen());
+
+// test without proxy-connection header
+conn = new SimpleHttpConnection();
+headers = HTTP/1.1 200 OK\r\n\r\n;
+
+conn.addResponse(headers, 12345);
+conn.setProxyHost(proxy);
+conn.setProxyPort(1);
+method = new GetMethod(/);
+method.execute(new HttpState(), conn);
+method.getResponseBodyAsString();
+
+assertFalse(conn.isOpen());
}
public void testNullHeaders() throws Exception {
[jelly/jexl] any outstanding patches?
If anyone has any outstanding patches for jelly or jexl, can you please place them in bugzilla? I'll go through them all in the next week and apply ones that are appropriate. -pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/hivemind/src/test/hivemind/test HiveMindTestCase.java
hlship 2003/06/20 07:00:30
Modified:hivemind/src/java/org/apache/commons/hivemind/impl
BaseModule.java ConfigurationExtensionPoint.java
ServiceExtensionPoint.java
hivemind/src/test/hivemind/test/services TestServices.java
hivemind/xdocs descriptor.xml navigation.xml
hivemind project.xml maven.xml
hivemind/common links.xml
hivemind/src/xsl hivemind.xsl
hivemind/src/java/org/apache/commons/hivemind
HiveMindMessages.properties
hivemind/src/test/hivemind/test/config
TestConfiguration.java
hivemind/src/test/hivemind/test HiveMindTestCase.java
Added: hivemind/src/test/hivemind/test/services
RecursiveService.xml
hivemind/xdocs registry.xml
hivemind/src/test-data/sample org.example.boostrap.xml
org.example.toolbar.ui.xml
hivemind/src/test/hivemind/test/config
RecursiveConfiguration.xml
Removed: hivemind/src/test-data/sample sample-registry.xml
Log:
Add checks for recursive service and configuration builds.
Improve generation of registry documentation (to use chunked output).
Revision ChangesPath
1.4 +1 -3
jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/impl/BaseModule.java
Index: BaseModule.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/impl/BaseModule.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- BaseModule.java 4 Jun 2003 23:52:48 - 1.3
+++ BaseModule.java 20 Jun 2003 14:00:29 - 1.4
@@ -112,8 +112,6 @@
private Map _configurations;
-// TODO: checks for recursive service build!
-
public void addServiceExtensionPoint(IServiceExtensionPoint point)
{
if (_serviceExtensionPoints == null)
1.6 +24 -3
jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/impl/ConfigurationExtensionPoint.java
Index: ConfigurationExtensionPoint.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/impl/ConfigurationExtensionPoint.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ConfigurationExtensionPoint.java 10 Jun 2003 17:57:08 - 1.5
+++ ConfigurationExtensionPoint.java 20 Jun 2003 14:00:29 - 1.6
@@ -93,6 +93,7 @@
private Class _elementType;
private String _elementTypeName;
private boolean _cacheElements;
+private boolean _building;
protected void extendDescription(ToStringBuilder builder)
{
@@ -179,7 +180,27 @@
return _sharedConfigurationContributions;
}
-public List constructConfiguration()
+public synchronized List constructConfiguration()
+{
+if (_building)
+throw new ApplicationRuntimeException(
+HiveMind.format(
+ConfigurationExtensionPoint.recursive-configuration,
+getExtensionPointId()));
+
+try
+{
+_building = true;
+
+return constructConfigurationInner();
+}
+finally
+{
+_building = false;
+}
+}
+
+protected List constructConfigurationInner()
{
if (LOG.isDebugEnabled())
LOG.debug(Constructing configuration + getExtensionPointId());
@@ -300,7 +321,7 @@
LOG.error(message);
}
-
+
public boolean getCacheElements()
{
return _cacheElements;
1.6 +23 -2
jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/impl/ServiceExtensionPoint.java
Index: ServiceExtensionPoint.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/impl/ServiceExtensionPoint.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ServiceExtensionPoint.java9 Jun 2003 22:23:09 - 1.5
+++ ServiceExtensionPoint.java20 Jun 2003 14:00:29 - 1.6
@@ -89,6 +89,7 @@
private List _interceptorContributions;
private List _sortedInterceptorContributions;
private boolean _required;
+private boolean _building;
protected void extendDescription(ToStringBuilder builder)
{
@@ -210,7 +211,27 @@
return _sortedInterceptorContributions;
}
-public Object
Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)
Phil Steitz wrote: Mark R. Diggory wrote: David Graham wrote: I see no correlation between AOP and static methods, nor any correlation between static methods an increased code maintainability. There is nothing magic about static methods that make them more maintainable than non-statics. David http://www.eclipse.org/aspectj/ -Rob The discussion is growing somewhat repetative, OT and monotonic, unless anyone has a clearly differing view than whats been already voiced, I suggest we move on to more interesting development related topics, your probibly welcome to continue this discussion on the jakarta commons users/interest list. Cheers, I agree that this could go on and on and we should get back to work, but I think that David's main point -- that static methods limit flexibility and are not really necessary to support utility functionality -- is a good one and one which we should keep in mind. The limitation on overriding is a serious concern and that is why in an earlier post, I suggested that we never use static methods for complex algorithms. An argument could be made that it would have been better to implement the methods in StatUtils as instance methods and to provide a (singleton) instance factory for users. I think that this is a better general approach, but for the simple computational methods in StatUtils and MathUtils, convenience and efficiency outweigh the extensibility concern. Phil True, there is a balance that needs to be maintained between extensibility and efficiency/ease of use. David's comments about lack of extensibility in static methods is valuable. But, I certainly don't believe that static usage or instantiable objects are either right or wrong. They both have their place. I believe we based the design of the static utilities on the current Math design for consistency (not only in static aspects, but return value domain and behavior). I keep reminding myself, we are the developers, there is always room for refactoring in the future. If there becomes a clear hindrance with the use of static methods, then we can refactor them into a class that needs to be instantiated. This is not too difficult to accomplish. -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20813] - FileUpload does not take 'charset' parameter of the 'Content-Type' header into consideration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20813. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20813 FileUpload does not take 'charset' parameter of the 'Content-Type' header into consideration --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 15:12 --- Created an attachment (id=6914) Patch (take 1) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/hivemind/src/test/hivemind/test/external MapVariableSource.java VariableSourceOrder.xml TestExternalParser.java
hlship 2003/06/20 08:26:09
Modified:hivemind/src/test/hivemind/test/external
TestExternalParser.java
Added: hivemind/src/test/hivemind/test/external
MapVariableSource.java VariableSourceOrder.xml
Log:
Add tests to check that variable sources are consulted in the specified order.
Revision ChangesPath
1.6 +39 -1
jakarta-commons-sandbox/hivemind/src/test/hivemind/test/external/TestExternalParser.java
Index: TestExternalParser.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/hivemind/src/test/hivemind/test/external/TestExternalParser.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- TestExternalParser.java 11 Jun 2003 14:13:29 - 1.5
+++ TestExternalParser.java 20 Jun 2003 15:26:09 - 1.6
@@ -288,4 +288,42 @@
assertEquals(${town}, e2.getContent());
}
+
+ public void testVariableSourceOrder() throws Exception
+ {
+ RegistryBuilder b = new RegistryBuilder();
+ DescriptorParser dp = new DescriptorParser();
+
+ b.processModule(_resolver, dp.parse(getMasterModuleLocation()));
+ b.processModule(_resolver,
dp.parse(getLocation(VariableSourceOrder.xml)));
+
+ IRegistry r = b.constructRegistry();
+
+ List elements = r.getConfiguration(hivemind.test.external.Elements);
+ assertEquals(1, elements.size());
+
+ IElement e = (IElement) elements.get(0);
+
+ assertEquals(family, e.getElementName());
+
+ IAttribute a = (IAttribute) e.getAttributes().get(0);
+ assertEquals(husband, a.getName());
+ assertEquals(Homer Simpson, a.getValue());
+
+ List l2 = e.getElements();
+ IElement e2 = (IElement) l2.get(0);
+ assertEquals(Wife: Wilma Flintstone, e2.getContent());
+
+ e2 = (IElement) l2.get(1);
+ assertEquals(Barney Rubble, e2.getContent());
+
+ e2 = (IElement) l2.get(2);
+ assertEquals(Dino, e2.getContent());
+
+ e2 = (IElement) l2.get(3);
+ // No value for this variable.
+
+ assertEquals(${town}, e2.getContent());
+
+ }
}
1.1
jakarta-commons-sandbox/hivemind/src/test/hivemind/test/external/MapVariableSource.java
Index: MapVariableSource.java
===
package hivemind.test.external;
import java.util.Map;
import org.apache.commons.hivemind.IVariableSource;
/**
* Allows a Map as the basis of a variable source.
*
* @author Howard Lewis Ship
* @version $Id: MapVariableSource.java,v 1.1 2003/06/20 15:26:09 hlship Exp $
*/
public class MapVariableSource implements IVariableSource
{
private Map _map;
public String valueForVariable(String variableName)
{
return (String)_map.get(variableName);
}
public Map getMap()
{
return _map;
}
public void setMap(Map map)
{
_map = map;
}
}
1.1
jakarta-commons-sandbox/hivemind/src/test/hivemind/test/external/VariableSourceOrder.xml
Index: VariableSourceOrder.xml
===
?xml version=1.0 encoding=UTF-8?
!-- $Id: VariableSourceOrder.xml,v 1.1 2003/06/20 15:26:09 hlship Exp $ --
module
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:noNamespaceSchemaLocation=http://jakarta.apache.org/commons/hivemind/schema/HiveMind_1.0.xsd;
id=hivemind.test.external
version=1.0.0
contribute-configuration
configuration-id=org.apache.commons.hivemind.VariableSource
create-instance
class=org.apache.commons.hivemind.VariableSourceContribution
set property=order value=1000/
set-create property=source
class=hivemind.test.external.PropertiesVariableSource/
/create-instance
create-instance
class=org.apache.commons.hivemind.VariableSourceContribution
set property=order value=500/
set-create property=source
class=hivemind.test.external.MapVariableSource
set-create property=map class=java.util.HashMap
set property=husband value=Homer Simpson/
/set-create
/set-create
/create-instance
/contribute-configuration
configuration id=Elements element-type=org.apache.commons.hivemind.IElement
xml path=Variables.xml/
/configuration
/module
Re: [jelly/jexl] any outstanding patches?
On Fri, 20 Jun 2003, Peter Royal wrote: If anyone has any outstanding patches for jelly or jexl, can you please place them in bugzilla? I'll go through them all in the next week and apply ones that are appropriate. Jira? http://jira.codehaus.org/secure/BrowseProject.jspa?id=10012 -bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient HttpMethodBase.java
olegk 2003/06/20 09:30:59
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpMethodBase.java
Log:
Code optimization
Contributed by Oleg Kalnichevski
Reviewed by Mike Becke
Revision ChangesPath
1.154 +6 -29
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java
Index: HttpMethodBase.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java,v
retrieving revision 1.153
retrieving revision 1.154
diff -u -r1.153 -r1.154
--- HttpMethodBase.java 20 Jun 2003 13:30:02 - 1.153
+++ HttpMethodBase.java 20 Jun 2003 16:30:58 - 1.154
@@ -676,34 +676,11 @@
}
for (int i = headers.length - 1; i = 0; i++) {
Header header = headers[i];
-String lengthValue = null;
-// we're using this just in case the content length is duplicated
-// i.e. '57, 57'
try {
-HeaderElement[] lengthElements = header.getValues();
-
-if (lengthElements.length 1) {
-// looks like the content length header was duplicated. if so
-// they won't be key=value pairs so we just want to get
-// the name not the value (which should be null)
-// take the first value and ignore any others
-lengthValue = lengthElements[0].getName();
-} else {
-lengthValue = header.getValue();
-}
-} catch (HttpException e) {
+return Integer.parseInt(header.getValue());
+} catch (NumberFormatException e) {
if (LOG.isWarnEnabled()) {
LOG.warn(Invalid content-length value: + e.getMessage());
-}
-lengthValue = null;
-}
-if (lengthValue != null) {
-try {
-return Integer.parseInt(lengthValue);
-} catch (NumberFormatException e) {
-if (LOG.isWarnEnabled()) {
-LOG.warn(Invalid content-length value: + e.getMessage());
-}
}
}
// See if we can have better luck with another header, if present
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat UnivariateImpl.java)
I keep reminding myself, we are the developers, there is always room for refactoring in the future. If there becomes a clear hindrance with the use of static methods, then we can refactor them into a class that needs to be instantiated. This is not too difficult to accomplish. Not for us, maybe, but it could be a real pain for the users who have written code using the static methods directly. We also need to keep reminding ourselves that what we are developing is a library for others to use. Refactoring public interfaces post release is a slow and painful process. Given that MathUtils and StatUtils are going to be public, we need to be committed to supporting the static methods that they will expose. I am personally OK with this, as long as we limit the scope to relatively trivial computational methods. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient HttpMethodBase.java
olegk 2003/06/20 09:43:19 Modified:httpclient/src/java/org/apache/commons/httpclient HttpMethodBase.java Log: Bug fix #20942 (Request with DIGEST authentication fails when redirected) Contributed by Oleg Kalnichevski Reviewed by Mike Becke Revision ChangesPath 1.155 +7 -5 jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java Index: HttpMethodBase.java === RCS file: /home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java,v retrieving revision 1.154 retrieving revision 1.155 diff -u -r1.154 -r1.155 --- HttpMethodBase.java 20 Jun 2003 16:30:58 - 1.154 +++ HttpMethodBase.java 20 Jun 2003 16:43:18 - 1.155 @@ -1152,7 +1152,9 @@ } //invalidate the list of authentication attempts -this.realms.clear(); +this.realms.clear(); +//remove exisitng authentication headers +removeRequestHeader(HttpAuthenticator.WWW_AUTH_RESP); //update the current location with the redirect location. //avoiding use of URL.getPath() and URL.getQuery() to keep //jdk1.2 comliance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Limits on StatUtil content was( Re: [math] design patterns.... )
Phil Steitz wrote: I keep reminding myself, we are the developers, there is always room for refactoring in the future. If there becomes a clear hindrance with the use of static methods, then we can refactor them into a class that needs to be instantiated. This is not too difficult to accomplish. Not for us, maybe, but it could be a real pain for the users who have written code using the static methods directly. We also need to keep reminding ourselves that what we are developing is a library for others to use. Refactoring public interfaces post release is a slow and painful process. Given that MathUtils and StatUtils are going to be public, we need to be committed to supporting the static methods that they will expose. Now thats a very strong point, A cautious side note: Its very difficult to design a product for a hypothetical future user, I've been trying to do this for the last 3 years, its very very difficult, and I'm constantly pulling in the reigns, to stop overdevelopment that is based on bad assumptions about what this hypothetical user-base is going to want. The user is, infact, part of the Open Source development process. This is where philosphies like, Release early, Release often become benificial. The user input is really needed to help drive the development direction properly. I am personally OK with this, as long as we limit the scope to relatively trivial computational methods. Phil As well another excellent point, Where do we draw the line on the content of StatUtils? and what is a non-trivial computational method? If as an algorithm can be easily broken down into separate methods, it first seems a benefit to have those utility methods easily accessable for other alogrithms that may need them. We see this with mean, sum, sumq, etc in the statistics lib. However, optimized algorithms often combine the calculation of such utility methods to improve performance, sum and sumsq can be easily calcuated in one pass (or easily updated in a storageless case). In such cases is it a bad decision to promote the static usage of such methods, we see it happening in java.lang.Math? It is nice to have them as simple generic building blocks, but manyl optimal implementions could not directly benefit by using them. Math.pow is a standardized IEEE implementation, it is a generic and very stable solution but it is not the optimal performance solution in every case. Our StatUtils will probibly endup have the same such characteristics. Again, this doesn't suggest Static methods are bad, the same situation would arise if it were a regular abstract/base class. Its just the case that the methods that go into Utils have an appropriate definition of applicability that needs to be clearly defined. -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly/jexl] any outstanding patches?
On Friday, June 20, 2003, at 12:10 PM, bob mcwhirter wrote: On Fri, 20 Jun 2003, Peter Royal wrote: If anyone has any outstanding patches for jelly or jexl, can you please place them in bugzilla? I'll go through them all in the next week and apply ones that are appropriate. Jira? http://jira.codehaus.org/secure/BrowseProject.jspa?id=10012 ah, yes. jira :) -pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Limits on StatUtil content (was Re: [math] design patterns ...)
--- Mark R. Diggory [EMAIL PROTECTED] wrote: Phil Steitz wrote: I keep reminding myself, we are the developers, there is always room for refactoring in the future. If there becomes a clear hindrance with the use of static methods, then we can refactor them into a class that needs to be instantiated. This is not too difficult to accomplish. Not for us, maybe, but it could be a real pain for the users who have written code using the static methods directly. We also need to keep reminding ourselves that what we are developing is a library for others to use. Refactoring public interfaces post release is a slow and painful process. Given that MathUtils and StatUtils are going to be public, we need to be committed to supporting the static methods that they will expose. Now thats a very strong point, A cautious side note: Its very difficult to design a product for a hypothetical future user, I've been trying to do this for the last 3 years, its very very difficult, and I'm constantly pulling in the reigns, to stop overdevelopment that is based on bad assumptions about what this hypothetical user-base is going to want. The user is, infact, part of the Open Source development process. This is where philosphies like, Release early, Release often become benificial. The user input is really needed to help drive the development direction properly. I agree we need real user input to help guide the design, just so long as we don't let ourselves be completely constrained by what the initial small user base wants/likes (the way Unix make did when it had 10 users). I think if we warn alpha/beta users that public interfaces are subject to change, we may be OK. Al = Albert Davidson Chou Get answers to Mac questions at http://www.Mac-Mgrs.org/ . __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [committer] Peter Royal commons committer (specifically jelly)
+1 - robert On Thursday, June 19, 2003, at 08:21 AM, bob mcwhirter wrote: I'd like to recommend Peter Royal (proayl) as a commons committer. He's a core developer in Avalon land, and I've worked with on the jaxen (non-jakarta) project. Jelly needs a champion, so if Peter has patches, I'd pick path the produce privs, please. +1. -bob On Thu, 19 Jun 2003, Tim O'Brien wrote: Bob, I don't mean to be obstructionist, but to do this right, I'd recommend... ..Renaming the thread to [VOTE] [committer] Peter Royal commons committer. This is a commons-wide vote, many people filter on particular projects and might miss the vote. Tim On Wed, 18 Jun 2003, bob mcwhirter wrote: On Wed, 18 Jun 2003, Peter Royal wrote: I know there are users, but it anyone maintaining it? Anyone interested in applying outstanding patches and pushing for a release? I'm willing to help, I just have no commit rights :) I'm a committer, but not actively active. Post patches here, and I'll apply. Meanwhile, I'd like to propose giving proyal commits to commons-jelly. here's my +1. -bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Tim O'Brien Evanston, IL (847) 863-7045 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Bob McWhirter[EMAIL PROTECTED] The Werken Company http://werken.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly/jexl] any outstanding patches?
hi peter good to have you aboard the commons team. just FYI there's an ettiquette page on the wiki (http://nagoya.apache.org/ wiki/apachewiki.cgi?JakartaCommonsEtiquette) just in case some of our habits seem a little strange. please remember to add your name to the status file of the components you make commits to. this helps to keep track of who's responsible (and so has a binding vote) for each component. (i guess that i should create a page with this one so that i don't have to keep repeating myself to every new committer...) - robert On Friday, June 20, 2003, at 02:39 PM, Peter Royal wrote: If anyone has any outstanding patches for jelly or jexl, can you please place them in bugzilla? I'll go through them all in the next week and apply ones that are appropriate. -pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/docs el.html
luehe 2003/06/20 11:53:38 Modified:docs el.html Log: Updated with release info Revision ChangesPath 1.10 +20 -12jakarta-commons/docs/el.html Index: el.html === RCS file: /home/cvs/jakarta-commons/docs/el.html,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- el.html 29 May 2003 21:57:38 - 1.9 +++ el.html 20 Jun 2003 18:53:38 - 1.10 @@ -244,27 +244,35 @@ table border=0 cellspacing=0 cellpadding=2 width=100% trtd bgcolor=#525D76 font color=#ff face=arial,helvetica,sanserif - a name=DownloadstrongDownload/strong/a + a name=DocumentationstrongDocumentation/strong/a /font /td/tr trtd blockquote -table border=0 cellspacing=0 cellpadding=2 width=100% - trtd bgcolor=#828DA6 +pThe a href=http://jakarta.apache.org/commons/el/RELEASE-NOTES.txt; +Release Notes/a document the new features and bug fixes that have been +included in the latest release./p +pThe a href=http://jakarta.apache.org/commons/el/api/index.html; +JavaDoc API documents/a for the latest release are available online. +In particular, you should read the package overview of the codeorg.apache.commons.el/code package./p +/blockquote +/p + /td/tr + trtdbr//td/tr +/table +table border=0 cellspacing=0 cellpadding=2 width=100% + trtd bgcolor=#525D76 font color=#ff face=arial,helvetica,sanserif - a name=Nightly BuildsstrongNightly Builds/strong/a + a name=ReleasesstrongReleases/strong/a /font /td/tr trtd blockquote -p -The nightly builds for EL can be found -a href=http://cvs.apache.org/builds/jakarta-commons/nightly/commons-el/;here/a -/p -/blockquote - /td/tr - trtdbr//td/tr -/table +ul +liVersion 1.0 (from mirror) - 20 Jun 2003 + a href=http://jakarta.apache.org/site/binindex.cgi;binary/a + a href=http://jakarta.apache.org/site/sourceindex.cgi;source/a (latest)/li +/ul /blockquote /p /td/tr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20964] New: - [math] Remove mode, remove some methods from StatUtils
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20964. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20964 [math] Remove mode, remove some methods from StatUtils Summary: [math] Remove mode, remove some methods from StatUtils Product: Commons Version: Nightly Builds Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Sandbox AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The attached patch removes the following methods: 1. getMode() from StoreUnivariate, AbstractStoreUnivariate, and StatUtils. As defined in the javadoc, the mode has little meaning for continuously scaled data (which is what will be analyzed in the Univariate implementations). If users want frequency distributions, they can use Freq(uency). 2. Skewness, Kurtosis and Median computations from StatUtils. We do not need these internally (they are only supported in the Stored univariates) and they are much less commonly used than the other methods in StatUtils. The median is also redundant with getPercentiles in AbstractStoreUnivariate and it is not implemented (while the more general getPercentiles is). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20964] - [math] Remove mode, remove some methods from StatUtils
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20964. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20964 [math] Remove mode, remove some methods from StatUtils --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 19:03 --- Created an attachment (id=6918) patch to remove methods - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)
Phil Steitz wrote: The limitation on overriding is a serious concern and that is why in an earlier post, I suggested that we never use static methods for complex algorithms. An argument could be made that it would have been better to implement the methods in StatUtils as instance methods and to provide a (singleton) instance factory for users. Have a look at UnivariateRealSolverFactory and check whether you like my approach to cater for both simplicity and flexibility. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20964] - [math] Remove mode, remove some methods from StatUtils
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20964. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20964 [math] Remove mode, remove some methods from StatUtils --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 19:33 --- I am all for (1.) I feel the first part of (2) needs some more thought. I am using the StatUtils versions of Skewness and Kurtosis to provide for the storage based solution in UnivariateImpl. This was currently the ideal location for them as I am delegating to StatUtils for the other storage cases (mean, var, std) as well, so its a uniform strategy across all of Univariate. As they are moments just like mean and var, they can have resonably simple standalone implementations. I was also optimizing the StatUtil versions of these methods at this time. The second part of (2) I'm ok with. What do you think about moving percentile and sort functions into StatUtils? Are you also aware that there are sort utilities for arrays in java.uitl.Arrays? Also, it would be wise to approach such changes with consideration for whats happening in the rest of the system. Stripping skew and kurt without checking their dependencies in UnivariateImpl would end up breaking the build. you should have encountered compilation problems with UnivariateImpl after making the changes in this patch. This is where IDE's like Eclipse come in handy, you can do refactorings, deletions and see what breaks immediately in the IDE. -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Clazz] subclassing vs. configuration (Was: Extending Clazz)
Victor, --- [EMAIL PROTECTED] wrote: Dmitry: 2. The reason all those things are implemented as subclasses rather than configuration-based instances is precisely to avoid the need for configuration. In any complex environment you are working with lots of ClassLoaders, which are allocated by some container. A ClazzLoader is automatically allocated by Clazz for each ClassLoader as needed. Where would we put the hook for configuration? Victor: But the fifth step, adding the new ClazzLoader, _is_ a configuration anyway. Dmitry: It's done at the factory level: you register your custom ClazzLoader class (not instance) with a ClazzLoaderFactory. The factory will instantiate it as needed. Sorry, I do not understand it. You do not want configuration because you are not sure where to put the configuration hook. But where (in my client code) do I register the ClazzLoader class. Here I have the configuration hook. Right, but there is a big difference between registering a class with a factory and actually instantiating a ClazzLoader and configuring it. When you register the class with the factory, it just sits there dormant, with no overhead at all, until it is actually needed, which is when it is instantiated. Or is the problem based on registering a ClazzLoader class and not an instance? I don't see it as a problem - I see it as a solution. I have further looked into the code and the problem seems to be based on creating a ClazzLoader (zz) instance for each ClassLoader (ss). Is this necessary? Why not have another getClazzForName(String) method that takes a ClassLoader? getClazzForName(String, ClassLoader) Wouldn't that be much simpler? The reason you allocate a ClazzLoader(zz) for each ClassLoader (ss) is that you want to cache clazzes, rather than re-doing introspection every time somebody needs a clazz. Victor - Dmitri __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/configuration/xdocs overview.xml
epugh 2003/06/20 12:52:41 Modified:configuration/xdocs overview.xml Log: Adding note about translating config keys with . like test.short to test/short in web.xml Revision ChangesPath 1.4 +6 -0 jakarta-commons-sandbox/configuration/xdocs/overview.xml Index: overview.xml === RCS file: /home/cvs/jakarta-commons-sandbox/configuration/xdocs/overview.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- overview.xml 7 Jun 2003 06:40:41 - 1.3 +++ overview.xml 20 Jun 2003 19:52:41 - 1.4 @@ -154,6 +154,12 @@ ]] /source +p +Note! If you have a property called file.name with spaces in it, then it will be translated +as the key file/name. Therefore, you should NOT use spaces in the name of properties that +are loaded from JNDI! If you do want to use them, then make sure to convert in your web.xml the +. characters to / characters, like in the test.short example above. +/p /subsection /section - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly/jexl] any outstanding patches?
On Friday, June 20, 2003, at 02:50 PM, robert burrell donkin wrote: good to have you aboard the commons team. just FYI there's an ettiquette page on the wiki (http://nagoya.apache.org/ wiki/apachewiki.cgi?JakartaCommonsEtiquette) just in case some of our habits seem a little strange. please remember to add your name to the status file of the components you make commits to. this helps to keep track of who's responsible (and so has a binding vote) for each component. (i guess that i should create a page with this one so that i don't have to keep repeating myself to every new committer...) No problem, thanks for the welcome :) -pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20964] - [math] Remove mode, remove some methods from StatUtils
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20964. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20964 [math] Remove mode, remove some methods from StatUtils --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 20:35 --- I want to keep StatUtils as lean as possible, partly because the methods are static. Regarding the build, all tests run fine for me after the change. Unfortunately, the test cases for UnivariateImpl do not execute the paths that would have caused failure. One more reason to get the path coverage up. Also, I neglected to execute maven clean before test. My mistake. I see now that these methods are reused, so we have to keep them in StatUtils (unless we decide to drop skewness and kurtosis from UnivariateImpl). I will submit a revised patch keeping these things in; but I am getting a little squemish about so many static methods. My preference would be to remove skewness and kurtosis from UnivariateImpl and StatUtils as well. I do not want to put the percentile computations into StatUtils. Yes, you are correct, the pre-1.2 sort implementation that I embedded in abstractStoreUnivariate.getSortedValues should be replaced by the ArrayUtils sort. I will submit a separate patch for this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 20964] - [math] Remove mode, remove somemethods from StatUtils
[EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20964. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20964 [math] Remove mode, remove some methods from StatUtils --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 20:35 --- I want to keep StatUtils as lean as possible, partly because the methods are static. I do agree. Some of the rank stats that got in there were just because I was grabbing methods out of AbstractStore and modifying them for the static case. Regarding the build, all tests run fine for me after the change. Unfortunately, the test cases for UnivariateImpl do not execute the paths that would have caused failure. One more reason to get the path coverage up. Good point, I'll try to come up with a couple more UnivariateImpl cases that cover the store case. Also, I neglected to execute maven clean before test. My mistake. I see now that these methods are reused, so we have to keep them in StatUtils (unless we decide to drop skewness and kurtosis from UnivariateImpl). I will submit a revised patch keeping these things in; but I am getting a little squemish about so many static methods. My preference would be to remove skewness and kurtosis from UnivariateImpl and StatUtils as well. Ok, I'm always going to be a little touchy about Skew and Kurt, their kinda like my first born children. I want to clarify that there are perfectly stable UnivariateImpl implementations of skew and kurt in the storageless case, they do have a place there, and I have improved them to use the same strategy as the Wests algorithm for variance that Al worked on (they no longer require sum of ^3 and sum of ^4). This is thanks to Brents link on recursive calculation of moments (which is really what Wests algorithm is). We could possibly place the storage based implementations into UnivariateImpl, but then we're back to replicating the code again instead of delegating to a standard implementation. I do not want to put the percentile computations into StatUtils. Yes, you are correct, the pre-1.2 sort implementation that I embedded in abstractStoreUnivariate.getSortedValues should be replaced by the ArrayUtils sort. I will submit a separate patch for this. Ok -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat AbstractStoreUnivariate.java StatUtils.java
mdiggory2003/06/20 14:05:47
Modified:math/src/java/org/apache/commons/math/stat
AbstractStoreUnivariate.java StatUtils.java
Log:
PR: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20964
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
1.4 +0 -10
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/AbstractStoreUnivariate.java
Index: AbstractStoreUnivariate.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/AbstractStoreUnivariate.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- AbstractStoreUnivariate.java 11 Jun 2003 14:50:30 - 1.3
+++ AbstractStoreUnivariate.java 20 Jun 2003 21:05:47 - 1.4
@@ -62,16 +62,6 @@
*/
public abstract class AbstractStoreUnivariate implements StoreUnivariate {
-/**
- * Returns the most frequently occuring value
- * @see org.apache.commons.math.stat.StoreUnivariate#getMode()
- */
-public double getMode() {
-// Mode depends on a refactor Freq class
-String msg = getMode() is not yet implemented;
-throw new UnsupportedOperationException(msg);
-}
-
/**
* Returns the skewness of this collection of values
* @see org.apache.commons.math.stat.StoreUnivariate#getSkewness()
1.8 +1 -23
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/StatUtils.java
Index: StatUtils.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/StatUtils.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- StatUtils.java18 Jun 2003 12:42:24 - 1.7
+++ StatUtils.java20 Jun 2003 21:05:47 - 1.8
@@ -282,26 +282,4 @@
}
return min;
}
-
-/**
- * Returns the mode of the values that have been added. The mode is
- * the element which occurs with the most frequency
- * @return the mode
- */
-public static double mode() {
-// Mode depends on a refactor Freq class
-String msg = mode() is not yet implemented;
-throw new UnsupportedOperationException(msg);
-}
-
-/**
- * Returns the mode of the values that have been added. The mode is
- * the element which occurs with the most frequency
- * @return the mode
- */
-public static double median(double[] values) {
-// Mode depends on a refactor Freq class
-String msg = median() is not yet implemented;
-throw new UnsupportedOperationException(msg);
-}
-}
\ No newline at end of file
+}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration]Missing Jars for Build and Bug with ClassPropertiesConfiguration
Eric,
I have made the changes and provided a test case as you suggested.
The files I have attached contain the following:
maven.xml-Added copy target to copy the test.properties file to
testClasspath.properties at the root of the classpath.
project.xml-removed the TestClassProperties from being excluded from tests.
TestClassPropertiesConfiguration.java-Added new unit test to test loading
from the classpath in various path formats.
TestBasePropertiesConfiguration.java-Added a test to test properties that
reference another property using the ${property} notation. This was
unrelated to the original changes that I proposed.
test.properties-Added two properties for testing references to previous
properties.
If you put the above changes in place and run maven you can see that it
fails the tests. Place the following files in place and everything should
test OK.
ClassPropertiesConfiguration.java-Changes to first attempt to load the
properties file via the provided class. If that fails it attempts to load
from the classloader.
Let me know if you have any questions,
Brian Dunbar
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 19, 2003 9:14 PM
To: [EMAIL PROTECTED]
Subject: RE: [Configuration]Missing Jars for Build and Bug with
ClassPrope rtiesConfiguration
I just committed an update build.xml that worked fine. Plus a bunch of
other small fixes. You may want to grab that to work from.
Eric Pugh
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 19, 2003 6:06 PM
To: [EMAIL PROTECTED]
Subject: RE: [Configuration]Missing Jars for Build and Bug with
ClassPrope rtiesConfiguration
Well, I have never used that class, so I can definitly NOT venture an
opinion! Having said that, if you provide patches to fix the code, and good
unit tests to prove the old code works and the new code works, then I would
be happy to apply your fixes.
What would be great is to first submit a patch that PROVES that properties
at the root fails. Then, I can run a test, take your patches, and see that
the test case starts passing!
Eric Pugh
-Original Message-
From: Brian E. Dunbar [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 19, 2003 6:03 PM
To: Jakarta Commons Developers List
Subject: RE: [Configuration]Missing Jars for Build and Bug with
ClassPropertiesConfiguration
Eric,
I should have picked up on the fact that it is maven driven given the
maven.xml file.
Yes, this change would allow you to have properties file found on the
classpath either at the root of the classpath or at the package
subdirectory. The code and Javadoc currently claims to support both, but the
implementation of access them at the root appears to be broken (unless I am
missing something).
Brian
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 19, 2003 5:38 PM
To: [EMAIL PROTECTED]
Subject: RE: [Configuration]Missing Jars for Build and Bug with
ClassPropertiesConfiguration
Brian,
What kinds of errors are you getting. commons-configuration is built using
maven. One of maven's target's produces the build.xml file. We really need
a message in there, don't edit this, it is generated by maven!
I regenerated the buid.xml file using maven and was sucessful. If you need
an updated build.xml, I can email it to you directly. I'll try and commit
it to cvs this evening!
I am not sure about Item 2, this is streching my level of understanding.
Would this mean though that I could have properties files in both a class
sub directory and in the root?
eric
-Original Message-
From: Brian E. Dunbar [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 19, 2003 5:28 PM
To: [EMAIL PROTECTED]
Subject: [Configuration]Missing Jars for Build and Bug with
ClassPropertiesConfiguration
Item 1:
I was building commons-configuration from scratch and it was having problems
retrieving some of the jar files from ibiblio. I made fixes to the build.xml
file to add/modify some lines to get it to work. My fixed build.xml is
attached.
Item 2:
The ClassPropertiesConfiguration seems to only be able to load properties
files from within the package of the class passed into the constructor. I
have been unable to successfully load a properties file from the root of the
classpath by placing a / at the beginning of the name (as the source code
indicates one should do). The source code indicates that the Javadoc for
loading resources says that all URL's start with a /, but I am unable to
find that in the javadoc for ClassLoader and in testing I have been unable
to get ClassLoader to load a file that beings with a /.
If I am correct, I propose that ClassPropertiesConfiguration be changed as
described below. In my experience it is more likely that properties files
need to be loaded from the root of the classpath then from a specific
package within the classpath (but that is my experience).
Use the classloader of class that
Re: [math] Remove mode, remove some methods from StatUtils
--- Mark R. Diggory [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Also, I neglected to execute maven clean before test. My mistake. I see now that these methods are reused, so we have to keep them in StatUtils (unless we decide to drop skewness and kurtosis from UnivariateImpl). I will submit a revised patch keeping these things in; but I am getting a little squemish about so many static methods. My preference would be to remove skewness and kurtosis from UnivariateImpl and StatUtils as well. Ok, I'm always going to be a little touchy about Skew and Kurt, their kinda like my first born children. We really should look at whether the functionality we are providing is useful to our audience and base our decisions heavily on that. I understand your sentiment, but what it should boil down to is, Is this feature providing value? For instance, now that I have backed off on submitting a Ridders' method root finder, I no longer have an explicit use case for MathUtils.sign(), and it could be argued that this method should be removed. As for skewness and kurtosis, my opinion remains that they are little used in the real world (and are thus causing undue debate within the project and wasting time and energy). No one has commented on that remark, as far as I can remember. Al = Albert Davidson Chou Get answers to Mac questions at http://www.Mac-Mgrs.org/ . __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration]Missing Jars for Build and Bug with ClassPropertiesConfiguration
Some of the files appeared to have gotten stripped in transfer. Here are the
missing files.
Brian
-Original Message-
From: Brian E. Dunbar [mailto:[EMAIL PROTECTED]
Sent: Friday, June 20, 2003 5:14 PM
To: Jakarta Commons Developers List
Subject: RE: [Configuration]Missing Jars for Build and Bug with
ClassPropertiesConfiguration
Eric,
I have made the changes and provided a test case as you suggested.
The files I have attached contain the following:
maven.xml-Added copy target to copy the test.properties file to
testClasspath.properties at the root of the classpath.
project.xml-removed the TestClassProperties from being excluded from tests.
TestClassPropertiesConfiguration.java-Added new unit test to test loading
from the classpath in various path formats.
TestBasePropertiesConfiguration.java-Added a test to test properties that
reference another property using the ${property} notation. This was
unrelated to the original changes that I proposed.
test.properties-Added two properties for testing references to previous
properties.
If you put the above changes in place and run maven you can see that it
fails the tests. Place the following files in place and everything should
test OK.
ClassPropertiesConfiguration.java-Changes to first attempt to load the
properties file via the provided class. If that fails it attempts to load
from the classloader.
Let me know if you have any questions,
Brian Dunbar
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Remove mode, remove some methods from StatUtils
Al Chou wrote: Ok, I'm always going to be a little touchy about Skew and Kurt, their kinda like my first born children. We really should look at whether the functionality we are providing is useful to our audience and base our decisions heavily on that. I understand your sentiment, but what it should boil down to is, Is this feature providing value? For instance, now that I have backed off on submitting a Ridders' method root finder, I no longer have an explicit use case for MathUtils.sign(), and it could be argued that this method should be removed. [sigh] I feel the debate should be more about where to put things we have already worked hard to create. rather than to eliminate them to make a release. If you intend to implement Riddlers later after release rather than before, it would be wise to keep sign around. My time and efforts are focused into the features I want to see available in the statistics library (and the features I *enjoy* working on), others do the same and the library grows in functionality. Be very carefull about taking away the things that other developers on the project are working with great interest on. As for skewness and kurtosis, my opinion remains that they are little used in the real world (and are thus causing undue debate within the project and wasting time and energy). No one has commented on that remark, as far as I can remember. Al All I can say as a developer on this project is, I use them, I enjoy working on them, (they are moments as natural as mean and variance and they natural incusions into descriptive statistics). I've worked hard on their development, and I'd really like them to stay part of the package. -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] Commons EL 1.0 Released
The Commons EL team is pleased to announce the first official release of Commons EL from the Apache Software Foundation. Commons EL provides an interpreter for the Expression Language that is part of the JavaServer Pages (JSP) specification, version 2.0. For more details, see the Release Notes at http://www.apache.org/dist/jakarta/commons/el/RELEASE-NOTES.txt The binary distribution is available at http://jakarta.apache.org/site/binindex.cgi, and the source distribution at http://jakarta.apache.org/site/sourceindex.cgi Please remember to verify the signatures of the distribution bundles using the keys found at http://www.apache.org/dist/jakarta/commons/el/KEYS For more information on Commons EL, go to http://jakarta.apache.org/commons/el.html Jan Luehe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math ContinuedFraction.java
mdiggory2003/06/20 19:21:49
Modified:math/src/java/org/apache/commons/math/special Beta.java
Gamma.java
math/src/java/org/apache/commons/math/stat/distribution
ChiSquaredDistribution.java GammaDistribution.java
DistributionFactory.java GammaDistributionImpl.java
TDistributionImpl.java ExponentialDistribution.java
ExponentialDistributionImpl.java
AbstractContinuousDistribution.java
TDistribution.java FDistributionImpl.java
FDistribution.java
math/src/java/org/apache/commons/math ContinuedFraction.java
Log:
This is a multifile commit, it covers checkstyle errors in javadoc etc.
PR: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20936
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
1.5 +31 -24
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/special/Beta.java
Index: Beta.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/special/Beta.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Beta.java 18 Jun 2003 20:02:27 - 1.4
+++ Beta.java 21 Jun 2003 02:21:48 - 1.5
@@ -73,9 +73,7 @@
}
/**
- * p
* Returns the regularized beta function I(x, a, b).
- * /p
*
* @param x ???
* @param a ???
@@ -87,39 +85,40 @@
}
/**
- * p
* Returns the regularized beta function I(x, a, b).
- * /p
*
* @param x ???
* @param a ???
* @param b ???
+ * @param epsilon When the absolute value of the nth item in the
+ *series is less than epsilon the approximation ceases
+ *to calculate further elements in the series.
* @return the regularized beta function I(x, a, b)
*/
-public static double regularizedBeta(double x, double a, double b, double
epsilon) {
+public static double regularizedBeta(double x, double a, double b,
+double epsilon) {
+
return regularizedBeta(x, a, b, epsilon, Integer.MAX_VALUE);
}
/**
- * p
* Returns the regularized beta function I(x, a, b).
- * /p
*
* @param x ???
* @param a ???
* @param b ???
+ * @param maxIterations Maximum number of iterations to complete.
* @return the regularized beta function I(x, a, b)
*/
-public static double regularizedBeta(double x, double a, double b, int
maxIterations) {
+public static double regularizedBeta(double x, double a, double b,
+int maxIterations) {
+
return regularizedBeta(x, a, b, DEFAULT_EPSILON, maxIterations);
}
/**
- * p
* Returns the regularized beta function I(x, a, b).
- * /p
*
- * p
* The implementation of this method is based on:
* ul
* li
@@ -129,14 +128,19 @@
* a href=http://functions.wolfram.com/06.21.10.0001.01;
* Regularized Beta Function/a./li
* /ul
- * /p
*
* @param x ???
* @param a ???
* @param b ???
+ * @param epsilon When the absolute value of the nth item in the
+ *series is less than epsilon the approximation ceases
+ *to calculate further elements in the series.
+ * @param maxIterations Maximum number of iterations to complete.
* @return the regularized beta function I(x, a, b)
*/
-public static double regularizedBeta(double x, final double a, final double b,
double epsilon, int maxIterations) {
+public static double regularizedBeta(double x, final double a,
+final double b, double epsilon, int maxIterations) {
+
double ret;
if (Double.isNaN(x) || Double.isNaN(a) || Double.isNaN(b) || (x 0)
@@ -155,8 +159,9 @@
if (n % 2 == 0) { // even
m = (n - 2.0) / 2.0;
ret =
-- ((a + m) * (a + b + m) * x)
-/ ((a + (2 * m)) * (a + (2 * m) + 1.0));
+-((a + m) * (a + b + m) * x)
+/ ((a + (2 * m))
+* (a + (2 * m) + 1.0));
} else {
m = (n - 1.0) / 2.0;
ret =
@@ -180,17 +185,17 @@
}
return ret;
}
-
DO NOT REPLY [Bug 20936] - [math] javadoc and checkstyle changes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20936. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20936 [math] javadoc and checkstyle changes [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-06-21 02:25 --- tested and commited, this javadoc fix patch spanded many files, I reviewed all the changes though, looks good. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/mapper/src/share/org/apache/commons/mapper MapperFactoryEvent.java
dgraham 2003/06/20 19:36:48
Modified:mapper/src/share/org/apache/commons/mapper
MapperFactoryEvent.java
Log:
Forgot to set this.mapper to what's passed in constructor.
Revision ChangesPath
1.3 +1 -0
jakarta-commons-sandbox/mapper/src/share/org/apache/commons/mapper/MapperFactoryEvent.java
Index: MapperFactoryEvent.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/mapper/src/share/org/apache/commons/mapper/MapperFactoryEvent.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MapperFactoryEvent.java 21 Jun 2003 01:54:05 - 1.2
+++ MapperFactoryEvent.java 21 Jun 2003 02:36:47 - 1.3
@@ -90,6 +90,7 @@
*/
public MapperFactoryEvent(Object source, Mapper mapper) {
super(source);
+this.mapper = mapper;
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/mapper/src/test/org/apache/commons/mapper TestMapperFactoryListener.java MapperFactoryTest.java TestMapper.java
dgraham 2003/06/20 19:41:09
Added: mapper/src/test/org/apache/commons/mapper
TestMapperFactoryListener.java
MapperFactoryTest.java TestMapper.java
Log:
Added more test cases.
Revision ChangesPath
1.1
jakarta-commons-sandbox/mapper/src/test/org/apache/commons/mapper/TestMapperFactoryListener.java
Index: TestMapperFactoryListener.java
===
/*
* $Header$
* $Revision$
* $Date$
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Struts, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*/
package org.apache.commons.mapper;
import java.util.ArrayList;
import java.util.List;
/**
* A test implementation of the MapperFactoryListener interface.
*
* @author David Graham
*/
public class TestMapperFactoryListener implements MapperFactoryListener {
/**
* Count the number of times mapperCreated is called.
*/
public int mapperCreatedCount = 0;
/**
* Save the MapperFactoryEvents passed into mapperCreated here.
*/
public List mapperEventsPassed = new ArrayList();
public TestMapperFactoryListener() {
super();
}
public void mapperCreated(MapperFactoryEvent event) {
this.mapperCreatedCount++;
this.mapperEventsPassed.add(event);
}
}
1.1
jakarta-commons-sandbox/mapper/src/test/org/apache/commons/mapper/MapperFactoryTest.java
Index: MapperFactoryTest.java
===
/*
* $Header$
* $Revision$
* $Date$
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice,
cvs commit: jakarta-commons-sandbox/mapper/src/test/org/apache/commons/mapper TestMapperFactoryListener.java MapperFactoryTest.java TestMapper.java
dgraham 2003/06/20 19:41:44 Modified:mapper/src/test/org/apache/commons/mapper TestMapperFactoryListener.java MapperFactoryTest.java TestMapper.java Log: *** keyword substitution change *** Revision ChangesPath 1.2 +0 -0 jakarta-commons-sandbox/mapper/src/test/org/apache/commons/mapper/TestMapperFactoryListener.java Index: TestMapperFactoryListener.java === RCS file: /home/cvs/jakarta-commons-sandbox/mapper/src/test/org/apache/commons/mapper/TestMapperFactoryListener.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 1.2 +0 -0 jakarta-commons-sandbox/mapper/src/test/org/apache/commons/mapper/MapperFactoryTest.java Index: MapperFactoryTest.java === RCS file: /home/cvs/jakarta-commons-sandbox/mapper/src/test/org/apache/commons/mapper/MapperFactoryTest.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 1.2 +0 -0 jakarta-commons-sandbox/mapper/src/test/org/apache/commons/mapper/TestMapper.java Index: TestMapper.java === RCS file: /home/cvs/jakarta-commons-sandbox/mapper/src/test/org/apache/commons/mapper/TestMapper.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/mapper build.xml
dgraham 2003/06/20 19:42:48
Modified:mapper build.xml
Log:
Point tests to MapperFactoryTest as starting point.
Revision ChangesPath
1.3 +1 -1 jakarta-commons-sandbox/mapper/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/mapper/build.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- build.xml 10 Jun 2003 03:58:06 - 1.2
+++ build.xml 21 Jun 2003 02:42:48 - 1.3
@@ -226,7 +226,7 @@
echo message=Running tests .../
java classname=${test.runner} fork=yes
failonerror=${test.failonerror}
- arg value=org.apache.commons.mapper.util.ObjectFactoryTest/
+ arg value=org.apache.commons.mapper.MapperFactoryTest/
classpath refid=test.classpath/
/java
/target
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20964] - [math] Remove mode, remove some methods from StatUtils
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20964. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20964 [math] Remove mode, remove some methods from StatUtils [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-06-21 02:45 --- Everything here was commited now, I've also added a new test in UnivariateImplTest for mean, varaince, skew and kurt (the same one thats in StoreUnivariateImplTest). I'm closing it out. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/mapper/src/share/org/apache/commons/mapper/jdbc JdbcMapperFactory.java
dgraham 2003/06/20 19:44:31 Removed: mapper/src/share/org/apache/commons/mapper/jdbc JdbcMapperFactory.java Log: Point tests to MapperFactoryTest as starting point. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat UnivariateImpl.java
mdiggory2003/06/20 19:54:56 Modified:math/src/java/org/apache/commons/math/stat UnivariateImpl.java Log: Removed last of the Math.pow's Revision ChangesPath 1.13 +4 -4 jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/UnivariateImpl.java Index: UnivariateImpl.java === RCS file: /home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/UnivariateImpl.java,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- UnivariateImpl.java 21 Jun 2003 02:08:23 - 1.12 +++ UnivariateImpl.java 21 Jun 2003 02:54:55 - 1.13 @@ -306,7 +306,7 @@ /* if n = 1, initialize the sumLog, min, max, mean, variance and pre-variance */ sumLog = 0.0; sum = min = max = mean = value; -sumsq = Math.pow(value, 2); +sumsq = value * value; variance = m2 = 0.0; skewness = kurtosis = 0.0; m2 = m3 = m4 = 0.0; @@ -314,13 +314,13 @@ /* otherwise calc these values */ sumLog += Math.log(value); sum += value; -sumsq += Math.pow(value, 2); +sumsq += value * value; min = Math.min(min, value); max = Math.max(max, value); double dev = value - mean; double v = dev / ((double) n); -double v2 = Math.pow(v, 2); +double v2 = v * v; double n0 = (double) n; double n1 = (double) (n - 1); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Univariate / StoreUnivariate interface cleanup
I think its always wise now to consult before making interface changes. I'd like to make a couple cleanup changes in the Univariate and StoreUnivariate Interfaces: (1) I don't think we really need getProduct in the Univariate interface (unless we want it to be public and available to users like getSum and getSumSq, which is another questionable method). /** * Returns the product of the available values * @return The product or Double.NaN if no values have been added. */ abstract double getProduct(); As getProduct is no longer used for geomean, now sumLog is used and might be a more appropriate method to place in the interface. (2) getKurtosis and getSkewness are now fully implemented in UnivariateImpl, a while ago I added them to the Univariate interface, as such they are not needed to be defined in the StoreUnivariate interface (they are inherited). I'd like to remove them from there as they are repetative. (3) I'd like to move getKurtosisClass and the static constants up to Univariate, as getKurtosis is available there now. -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] TestStatistic
Phil, Should we move TestStatistic/Impl up into the stat package? -M. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14120] - [FileUpload] uploading files with non-ASCII filenames
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14120. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14120 [FileUpload] uploading files with non-ASCII filenames --- Additional Comments From [EMAIL PROTECTED] 2003-06-21 04:20 --- That's a question for the Struts team to decide. Asking it in a resolved bug report against FileUpload is not going to get your question much visibility. However, since I am also a Struts developer, I can at least partially answer your question. At this time, as far as I am aware, no enhancement request has been opened against Struts to add this capability. Until someone does that, such a change is unlikely to happen. Assuming you, or some other interested person, open such a request, my guess would be that it would be fixed in Struts 1.2, but that is only a guess. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/daemon/src/native/unix/native arguments.c arguments.h jsvc-unix.c
billbarker2003/06/20 21:23:55
Modified:daemon/src/native/unix/native arguments.c arguments.h
jsvc-unix.c
Log:
As discussed, adding a call to 'setsid' on platforms that support it, redirect stdin
to /dev/null, and make in configurable where to redirect stdout and stderr.
Revision ChangesPath
1.7 +16 -2
jakarta-commons-sandbox/daemon/src/native/unix/native/arguments.c
Index: arguments.c
===
RCS file:
/home/cvs/jakarta-commons-sandbox/daemon/src/native/unix/native/arguments.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- arguments.c 10 Jun 2003 15:42:11 - 1.6
+++ arguments.c 21 Jun 2003 04:23:55 - 1.7
@@ -93,6 +93,8 @@
args-opts=(char **)malloc(argc*sizeof(char *));
args-clas=NULL;/* No class predefined */
args-anum=0; /* Zero class specific arguments but make room*/
+args-outfile=/dev/null; /* Swallow by default */
+args-errfile=/dev/null; /* Swallow by default */
args-args=(char **)malloc(argc*sizeof(char *));
/* Set up the command name */
@@ -176,7 +178,19 @@
return(NULL);
}
-} else if (strstr(argv[x],-verbose)==argv[x]) {
+} else if(strcmp(argv[x],-outfile) == 0) {
+args-outfile=optional(argc, argv, x++);
+if(args-outfile == NULL) {
+log_error(Invalid Output File specified);
+return(NULL);
+}
+} else if(strcmp(argv[x],-errfile) == 0) {
+args-errfile=optional(argc, argv, x++);
+if(args-errfile == NULL) {
+log_error(Invalid Error File specified);
+return(NULL);
+}
+}else if (strstr(argv[x],-verbose)==argv[x]) {
args-opts[args-onum++]=strdup(argv[x]);
} else if (strcmp(argv[x],-D)==0) {
1.5 +5 -1
jakarta-commons-sandbox/daemon/src/native/unix/native/arguments.h
Index: arguments.h
===
RCS file:
/home/cvs/jakarta-commons-sandbox/daemon/src/native/unix/native/arguments.h,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- arguments.h 10 Jun 2003 15:42:11 - 1.4
+++ arguments.h 21 Jun 2003 04:23:55 - 1.5
@@ -99,6 +99,10 @@
bool remove;
/** Run as a service (win32) */
bool service;
+/** Destination for stdout */
+char *outfile;
+/** Destination for stderr */
+char *errfile;
} arg_data;
/**
1.6 +32 -1
jakarta-commons-sandbox/daemon/src/native/unix/native/jsvc-unix.c
Index: jsvc-unix.c
===
RCS file:
/home/cvs/jakarta-commons-sandbox/daemon/src/native/unix/native/jsvc-unix.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- jsvc-unix.c 10 Jun 2003 15:42:11 - 1.5
+++ jsvc-unix.c 21 Jun 2003 04:23:55 - 1.6
@@ -364,6 +364,32 @@
return(ret);
}
+/**
+ * Redirect stdin, stdout, stderr.
+ */
+static void set_output(char *outfile, char *errfile) {
+freopen(/dev/null, r, stdin);
+
+/* Handle malicious case here */
+if(strcmp(outfile, 2) == 0 strcmp(errfile,1) == 0) {
+ outfile=/dev/null;
+}
+if(strcmp(outfile, 2) != 0) {
+ freopen(outfile, w, stdout);
+}
+
+if(strcmp(errfile,1) != 0) {
+ freopen(errfile, w, stderr);
+} else {
+ close(2);
+ dup(1);
+}
+if(strcmp(outfile, 2) == 0) {
+ close(1);
+ dup(2);
+}
+}
+
int main(int argc, char *argv[]) {
arg_data *args=NULL;
home_data *data=NULL;
@@ -435,7 +461,12 @@
}
/* If we're in the parent process, we siply quit */
if (pid!=0) return(0);
+#ifndef NO_SETSID
+setsid();
+#endif
}
+
+set_output(args-outfile, args-errfile);
/* We have to fork: this process will become the controller and the other
will be the child */
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/daemon/src/native/unix/native Tomcat.sh
billbarker2003/06/20 21:25:49 Modified:daemon/src/native/unix/native Tomcat.sh Log: Have the sample Tomcat script use the new outfile and errfile options. Revision ChangesPath 1.4 +2 -0 jakarta-commons-sandbox/daemon/src/native/unix/native/Tomcat.sh Index: Tomcat.sh === RCS file: /home/cvs/jakarta-commons-sandbox/daemon/src/native/unix/native/Tomcat.sh,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- Tomcat.sh 15 Jan 2003 11:10:01 - 1.3 +++ Tomcat.sh 21 Jun 2003 04:25:49 - 1.4 @@ -34,6 +34,8 @@ -home $JAVA_HOME \ -Dcatalina.home=$CATALINA_HOME \ -Djava.io.tmpdir=$TMP_DIR \ +-outfile $CATALINA_HOME/logs/catalina.out \ +-errfile '1' \ $CATALINA_OPTS \ -cp $CLASSPATH \ org.apache.catalina.startup.BootstrapService - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] TestStatistic
Mark R. Diggory wrote: Phil, Should we move TestStatistic/Impl up into the stat package? -M. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I would say yes. I would also like to move on the overall package organization that I proposed last week. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/daemon/src/native/unix/support apsupport.m4
billbarker2003/06/20 21:27:46 Modified:daemon/src/native/unix/support apsupport.m4 Log: Tell configure that cygwin doesn't have a setsid function. AFAIK, the rest of the currently supported platforms do. Revision ChangesPath 1.5 +2 -2 jakarta-commons-sandbox/daemon/src/native/unix/support/apsupport.m4 Index: apsupport.m4 === RCS file: /home/cvs/jakarta-commons-sandbox/daemon/src/native/unix/support/apsupport.m4,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- apsupport.m4 19 Sep 2002 16:48:47 - 1.4 +++ apsupport.m4 21 Jun 2003 04:27:46 - 1.5 @@ -98,7 +98,7 @@ supported_os=linux ;; cygwin) -CFLAGS=$CFLAGS -DOS_CYGWIN -DDSO_DLFCN +CFLAGS=$CFLAGS -DOS_CYGWIN -DDSO_DLFCN -DNO_SETSID supported_os=win32 ;; sysv) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/daemon/src/native/unix/native help.c
billbarker2003/06/20 21:49:39 Modified:daemon/src/native/unix/native help.c Log: Add new options to the help. Revision ChangesPath 1.3 +9 -1 jakarta-commons-sandbox/daemon/src/native/unix/native/help.c Index: help.c === RCS file: /home/cvs/jakarta-commons-sandbox/daemon/src/native/unix/native/help.c,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- help.c10 Jun 2003 15:42:11 - 1.2 +++ help.c21 Jun 2003 04:49:39 - 1.3 @@ -98,6 +98,14 @@ printf(-verbose[:class|gc|jni]\n); printf(enable verbose output\n); +printf(-outfile /full/path/to/file\n); +printf(Location for output from stdout (defaults to /dev/null)\n); +printf(Use the value '2' to simulate '12'\n); + +printf(-errfile /full/path/to/file\n); +printf(Location for output from stderr (defaults to /dev/null)\n); +printf(Use the value '1' to simulate '21'\n); + printf(-Dname=value\n); printf(set a Java system property\n); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/daemon/src/native/unix/native help.c
billbarker2003/06/20 21:51:14 Modified:daemon/src/native/unix/native help.c Log: Fix typo. Revision ChangesPath 1.4 +3 -9 jakarta-commons-sandbox/daemon/src/native/unix/native/help.c Index: help.c === RCS file: /home/cvs/jakarta-commons-sandbox/daemon/src/native/unix/native/help.c,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- help.c21 Jun 2003 04:49:39 - 1.3 +++ help.c21 Jun 2003 04:51:14 - 1.4 @@ -94,17 +94,11 @@ printf(-check\n); printf(only check service (implies -nodetach)\n); - -printf(-verbose[:class|gc|jni]\n); -printf(enable verbose output\n); - -printf(-outfile /full/path/to/file\n); -printf(Location for output from stdout (defaults to /dev/null)\n); -printf(Use the value '2' to simulate '12'\n); +printf(Use the value '2' to simulate '12'\n); printf(-errfile /full/path/to/file\n); printf(Location for output from stderr (defaults to /dev/null)\n); -printf(Use the value '1' to simulate '21'\n); +printf(Use the value '1' to simulate '21'\n); printf(-Dname=value\n); printf(set a Java system property\n); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20813] - FileUpload does not take 'charset' parameter of the 'Content-Type' header into consideration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20813. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20813 FileUpload does not take 'charset' parameter of the 'Content-Type' header into consideration --- Additional Comments From [EMAIL PROTECTED] 2003-06-21 04:59 --- Oleg, I understand your position too, but please realise that FileUpload is at the Release Candidate stage now. I took a look at the patch you attached, and that is WAY too much change to be introducing into a Release Candidate. What I would like to do is to release FileUpload 1.0 Final as is, very soon, and then we can work on getting your (take 1?) patch in, and release that as a 1.1 in a short timeframe. Beyond that, I would certainly be interested in your contributions to improve FileUpload, and if there are likely to be significant API changes, then perhaps we can target that for a 2.0 release. Getting a FileUpload 1.0 Final release out the door very soon is really, really important, because there are so many other projects depending on it now, and waiting for such a release before they themselves can release. Those projects include Tomcat, Turbine, Tapestry and Struts, to name only the Jakarta projects I know about, and they have no earlier release of FileUpload to fall back on. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
not working with IIS for digest
Hey, I've got httpclient working fine in basic and ntlm mode with IIS, but digest always gives me a 500 error - can't authenticate the host in the given domain or whatever. Has anyone else had this problem? Also, how can I extract the authentication line so that I can store it and use it right away the next time I get the same request? Thanks a lot ! Colin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20938] - Missing Content-Length header causes a SocketException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938 Missing Content-Length header causes a SocketException --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 07:30 --- doh... Do we not have test cases for that? I guess that's something else to add. I'll take another shot at it tonight. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: not working with IIS for digest
Colin, DIGEST authentication works fine with Apache 2.0 (I just tested it) and *should* work with IIS. Please note that the server returns status code 500 which means internal server error, not an authentication error. In order to pinpoint the problem, we'll need a bit of help from your side. Please, first of all, refer to the following troubleshooting guide: http://jakarta.apache.org/commons/httpclient/troubleshooting.html If none of the measures described there helps, please get back to us with the wire log of the HTTP session that exhibits the problem Cheers Oleg -Original Message- From: Colin Bird [mailto:[EMAIL PROTECTED] Sent: Fri 6/20/2003 08:25 To: 'Commons HttpClient Project' Cc: Subject:not working with IIS for digest Hey, I've got httpclient working fine in basic and ntlm mode with IIS, but digest always gives me a 500 error - can't authenticate the host in the given domain or whatever. Has anyone else had this problem? Also, how can I extract the authentication line so that I can store it and use it right away the next time I get the same request? Thanks a lot ! Colin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20942] New: - Request with DIGEST authentication fails when redirected
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20942. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20942 Request with DIGEST authentication fails when redirected Summary: Request with DIGEST authentication fails when redirected Product: Commons Version: 2.0 Beta 2 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: HttpClient AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Request with DIGEST authentication fails when redirected due to invalid URI parameter. -- Client side log -- [DEBUG] HttpClient - -Java version: 1.2.2 [DEBUG] HttpClient - -Java vendor: Sun Microsystems Inc. [DEBUG] HttpClient - -Operating system name: Linux [DEBUG] HttpClient - -Operating system architecture: i386 [DEBUG] HttpClient - -Operating system version: 2.4.20-13.9-ok [DEBUG] HttpClient - -SUN 1.2: SUN (DSA key/parameter generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore) [DEBUG] HttpClient - -SunJSSE 1.0301: Sun JSSE provider(implements RSA Signatures, PKCS12, SunX509 key/trust factories, SSLv3, TLSv1) [DEBUG] HttpConnection - -Creating connection for localhost using protocol http:80 [DEBUG] HttpConnection - -HttpConnection.setSoTimeout(0) [DEBUG] HttpMethod - -Execute loop try 1 [DEBUG] wire - - GET /transfer HTTP/1.1[\r][\n] [DEBUG] HttpMethod - -Adding Host request header [DEBUG] wire - - User-Agent: Jakarta Commons-HttpClient/2.0beta1[\r][\n] [DEBUG] wire - - Host: localhost[\r][\n] [DEBUG] wire - - [\r][\n] [DEBUG] wire - - HTTP/1.1 401 Authorization Required[\r][\n] [DEBUG] wire - - Date: Fri, 20 Jun 2003 08:30:06 GMT[\r][\n] [DEBUG] wire - - Server: Apache/2.0.40 (Red Hat Linux)[\r][\n] [DEBUG] wire - - WWW-Authenticate: Digest realm=guest realm, nonce=ei+T7oPAAwA=53c8e6d609ff81a8dcbc370b51f8aadec565009a, algorithm=MD5, domain=/transfer, qop=auth[\r][\n] [DEBUG] wire - - Vary: accept-language[\r][\n] [DEBUG] wire - - Accept-Ranges: bytes[\r][\n] [DEBUG] wire - - Content-Length: 1285[\r][\n] [DEBUG] wire - - Content-Type: text/html; charset=ISO-8859-1[\r][\n] [DEBUG] HttpMethod - -Authorization required [DEBUG] HttpAuthenticator - -Using 'guest realm' authentication realm [DEBUG] HttpMethod - -HttpMethodBase.execute(): Server demanded authentication credentials, will try again. ... [DEBUG] HttpMethod - -Resorting to protocol version default close connection policy [DEBUG] HttpMethod - -Should NOT close connection, using HTTP/1.1. [DEBUG] HttpMethod - -Execute loop try 2 [DEBUG] wire - - GET /transfer HTTP/1.1[\r][\n] [DEBUG] HttpMethod - -Request to add Host header ignored: header already added [DEBUG] wire - - User-Agent: Jakarta Commons-HttpClient/2.0beta1[\r][\n] [DEBUG] wire - - Host: localhost[\r][\n] [DEBUG] wire - - Authorization: Digest username=guest, realm=guest realm, nonce=ei+T7oPAAwA=53c8e6d609ff81a8dcbc370b51f8aadec565009a, uri=/transfer, qop=auth, algorithm=MD5, nc=0001, cnonce=81d4b905a4e9def944beaed8daf79283, response=71394edcddf4bcee6237ea4bb50cfaa5[\r][\n] [DEBUG] wire - - [\r][\n] [DEBUG] wire - - HTTP/1.1 301 Moved Permanently[\r][\n] [DEBUG] wire - - Date: Fri, 20 Jun 2003 08:30:06 GMT[\r][\n] [DEBUG] wire - - Server: Apache/2.0.40 (Red Hat Linux)[\r][\n] [DEBUG] wire - - Location: http://localhost/transfer/[\r][\n]; [DEBUG] wire - - Content-Length: 302[\r][\n] [DEBUG] wire - - Content-Type: text/html; charset=iso-8859-1[\r][\n] [DEBUG] HttpMethod - -Redirect required [DEBUG] HttpMethod - -Redirect requested to location 'http://localhost/transfer/' [DEBUG] HttpMethod - -Redirecting from 'http://localhost:80/transfer' to 'http://localhost/transfer/ ... [DEBUG] HttpMethod - -Resorting to protocol version default close connection policy [DEBUG] HttpMethod - -Should NOT close connection, using HTTP/1.1. [DEBUG] HttpMethod - -Execute loop try 3 [DEBUG] wire - - GET /transfer/ HTTP/1.1[\r][\n] [DEBUG] HttpMethod - -Request to add Host header ignored: header already added [DEBUG] wire - - User-Agent: Jakarta Commons-HttpClient/2.0beta1[\r][\n] [DEBUG] wire - - Host: localhost[\r][\n] [DEBUG] wire - - Authorization: Digest username=guest, realm=guest realm, nonce=ei+T7oPAAwA=53c8e6d609ff81a8dcbc370b51f8aadec565009a, uri=/transfer, qop=auth, algorithm=MD5, nc=0001, cnonce=81d4b905a4e9def944beaed8daf79283, response=71394edcddf4bcee6237ea4bb50cfaa5[\r][\n] [DEBUG] wire - - [\r][\n] [DEBUG] wire - - HTTP/1.1 400 Bad Request[\r][\n] [DEBUG] wire - - Date: Fri, 20 Jun 2003 08:30:06 GMT[\r][\n] [DEBUG] wire - - Server: Apache/2.0.40 (Red Hat Linux)[\r][\n] [DEBUG] wire - - Vary: accept-language[\r][\n] [DEBUG] wire - - Accept-Ranges: bytes[\r][\n]
DO NOT REPLY [Bug 20942] - Request with DIGEST authentication fails when redirected
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20942. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20942 Request with DIGEST authentication fails when redirected [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|--- |2.0 Beta 2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20938] - Missing Content-Length header causes a SocketException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938 Missing Content-Length header causes a SocketException --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 09:13 --- Created an attachment (id=6909) Fix take 2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20938] - Missing Content-Length header causes a SocketException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938 Missing Content-Length header causes a SocketException --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 09:14 --- Patch take 2 features: 1. Works with chunked encoding. 2. A test case for chunked encoding. 3. Everything that was in take 1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20938] - Missing Content-Length header causes a SocketException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938 Missing Content-Length header causes a SocketException --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 09:25 --- Adrian, I do not like that darn 'isChunked' flag. Besides, you forget to reset it in HttpMethodBase#recycle. (I DO get convinced that the whole idea of recycling is evil after all). I suggest that you just check for presence of 'Transfer-Encoding' or 'Content-Length' header in response. That is it. Do not even parse them. We can assume that the headers will be correctly reacted upon elsewhere. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20938] - Missing Content-Length header causes a SocketException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938 Missing Content-Length header causes a SocketException --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 09:40 --- Created an attachment (id=6910) Take 3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20938] - Missing Content-Length header causes a SocketException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938
Missing Content-Length header causes a SocketException
--- Additional Comments From [EMAIL PROTECTED] 2003-06-20 10:03 ---
Adrian,
My rationale is that by the time decision needs to be made whether the
connection is to be closed, an invalid 'Transfer-Encoding' or 'Content-Length'
header would already have caused an exception. I would even go as far as saying
that the check would be sufficient
+ if (responseHeaders.getFirstHeader(Transfer-Encoding) == null
+ responseHeaders.getFirstHeader(Content-Length) == null) {
+ LOG.debug(Should close connection as content-length is missing.);
+ return true;
+ }
Oleg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20938] - Missing Content-Length header causes a SocketException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938 Missing Content-Length header causes a SocketException --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 10:17 --- Good point, my mind is now at ease. :) Any other issues you can see? I'd like to wait for Mike to take a look at the patch before committing it anyway since he'd been looking into the problem earlier. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20938] - Missing Content-Length header causes a SocketException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938 Missing Content-Length header causes a SocketException --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 10:22 --- Sure. Let Mike take a look. As far as I am concerned all the issues have been addressed. I would like to streamline HttpMethodBase#getResponseContentLength() method a bit, but I'll submit it as a separate incremental patch Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Test Coverage
Howdy all, We now have a license for clover to analyze our test cases and am now just starting to work through adding test cases to improve our code coverage. I've very quickly come to the realization that 100% code coverage may actually be a bad thing. I've gotten AuthChallengeParser to 100% coverage now so let me use it as an example: There are four test cases that I consider pedantic and 1 of those that I really don't like. The pedantic ones are: * test that AuthChallengeParser.extractScheme(null) throws an illegal argument exception instead of a null pointer exception. What difference does this really make? The only reason I can think of to keep the test is so that the implied interface for the method is kept the same (it never throws a NPE but throws an illegal argument exception instead). * Test that AuthChallengeParser.extractParams(null) throws an illegal argument exception not a NPE. Same as above really. * testParamsWithNoName(). Check that AuthChallengeParser.extractParams(Basic realm=\test\,=\invalid\); throws a MalformedChallengeException because there is no name part to the name/value pair. This is good if we're in strict mode but if not wouldn't it be better to be lenient and just ignore that param (with a logged warning)? The one I really don't like is: * Test that AuthChallengeParser.extractScheme( Basic realm=\realm\); throws a MalformedChallengeException because there's a leading space. Now in strict mode that's fine and within HttpClient the leading space is stripped before being passed in but it seems overly strict to me. Now, I don't mind what happens with any of these decisions to be honest as none affect the actual behaviour of HttpClient - they are very much edge cases. I would however like to set up a policy on the types of test cases I should create (do we want to avoid testing things like the pedantic things above) as well as the best way to keep track of questionable or overly pedantic test cases. Currently I'm just adding a // pedantic above any test case that seems pedantic and a todo comment over anything that I think may require a change to the code but isn't clearly a bug. I figure from time to time I can provide a list of issues that need to be considered as I work my way through the codebase. Personally, I'm hoping to achieve 100% test coverage firstly because I've discovered how dependent I am on having good test cases while working on HttpClient (most people don't have the detailed level of knowledge that Mike and Oleg do and thus aren't aware that a change will break some other section of code - NTLM is a regular victim of this). Also, aiming for 100% coverage makes a very clear-cut decision on when the job is done which make life easier as well and makes it much more noticeable when new test cases need to be added. Any thoughts? Adrian Sutton. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20938] - Missing Content-Length header causes a SocketException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938 Missing Content-Length header causes a SocketException --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 12:52 --- This patch does not work in the absence of keep-alive headers. I will attach a fix for this plus some more test cases in a moment. This patch just moves the content length test to the top of shouldCloseConnection(). Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20938] - Missing Content-Length header causes a SocketException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938 Missing Content-Length header causes a SocketException --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 12:52 --- Created an attachment (id=6912) patch 3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commas in Cookie Value
Oleg, I noticed that there didn't seem to be a way to plug in a custom CookieSpec. I was wondering how to do it. For now, I will wait for 2.1 or download the source and modify one of the CookieSpecs. Thanks, Ron Tower - Original Message - From: Oleg Kalnichevski [EMAIL PROTECTED] To: Commons HttpClient Project [EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 5:32 PM Subject: Re: Commas in Cookie Value Ron (I apologise for misspelling your name in my previous post), You can easily subclass any of the CookieSpec classes. The trouble is there's no way to plug a custom cookie spec into the existing implementation of HttpClient. At the moment you have to modify CookiePolicy class and recompile Httpclient in order to get it done. We are aware of the problem and will address it in 2.1 release. Oleg PS: Brett's patch may eventually make it into the official Httpclient source tree, but that is not going to happen too soon. Maybe in 3.0 On Wed, 2003-06-18 at 22:06, Ron Tower wrote: Brett, I didn't download the source, just the jar and the docs. Could I subclass from a CookieSpec and just replace the parse of Set-Cookie? I would prefer to not have to modify the source so I can easily replace it with upcoming versions without having to put my change back in. Is your fix going into the main source? Do you know when? But if there is no other way, I can download the source, and then I would appreciate your fix. Thanks, Ron Tower - Original Message - From: Brett Knights [EMAIL PROTECTED] To: Commons HttpClient Project [EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 3:06 PM Subject: Re: Commas in Cookie Value I have a fix for this but it uses the org.apache.oro regular expression parser. E-mail me off line if you want the code to hack your own copy of HttpClient - Original Message - From: Ron Tower [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 9:26 AM Subject: Commas in Cookie Value Hello All, Is there a problem when a comma appears in a cookie value? See 02109POS below. It has a comma in the value and is split into two cookies. IE at least parses this cookie as one cookie. Is there a workaround for this? My understanding is that a cookie value can have any character other than a semicolon, space, or tab. I got the following Set-Cookie headers: [DEBUG] wire - - Set-cookie: CDSContentDistributor=137169; expires=Tuesday, 17-Jun-03 20:52:01 GMT; path=/[\r][\n] [DEBUG] wire - - Set-cookie: 02109POS=www4210513143792642538,; domain=.fidelity.com; path=/; expires=Fri, 12-Sep-2003 00:00:00 GMT;[\r][\n] [DEBUG] wire - - Set-cookie: MC=clHza1XIKW50aXo3nr5LD3gDFYMSAiWYtqihBBHXpfPA37wNqncGBQAGBT7vfRk AP03; expires=Monday, 15-Sep-2003 20:42:01 GMT; domain=.fidelity.com; path=/[\r][\n] And HttpClient sent the following Cookies: [DEBUG] wire - - Cookie: $Version=0; CDSContentDistributor=137169; $Path=/[\r][\n] [DEBUG] wire - - Cookie: $Version=0; 02109POS=www4210513143792642538[\r][\n] [DEBUG] wire - - Cookie: $Version=0; =; $Domain=.fidelity.com; $Path=/[\r][\n] [DEBUG] wire - - Cookie: $Version=0; MC=clHza1XIKW50aXo3nr5LD3gDFYMSAiWYtqihBBHXpfPA37wNqncGBQAGBT7vfRk AP03; $Domain=.fidelity.com; $Path=/[\r][\n] Thanks, Ron Tower - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20938] - Missing Content-Length header causes a SocketException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938 Missing Content-Length header causes a SocketException --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 12:59 --- gah... You're right. Your changes make sense and looks good to me. Oleg, how does this affect your reorganisation of that method? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Coverage
Adrian Sutton wrote: Howdy all, We now have a license for clover to analyze our test cases and am now just starting to work through adding test cases to improve our code coverage. I've very quickly come to the realization that 100% code coverage may actually be a bad thing. I've gotten AuthChallengeParser to 100% coverage now so let me use it as an example: There are four test cases that I consider pedantic and 1 of those that I really don't like. The pedantic ones are: * test that AuthChallengeParser.extractScheme(null) throws an illegal argument exception instead of a null pointer exception. What difference does this really make? The only reason I can think of to keep the test is so that the implied interface for the method is kept the same (it never throws a NPE but throws an illegal argument exception instead). * Test that AuthChallengeParser.extractParams(null) throws an illegal argument exception not a NPE. Same as above really. * testParamsWithNoName(). Check that AuthChallengeParser.extractParams(Basic realm=\test\,=\invalid\); throws a MalformedChallengeException because there is no name part to the name/value pair. This is good if we're in strict mode but if not wouldn't it be better to be lenient and just ignore that param (with a logged warning)? I wouldn't call these tests pedantic. They verify the contract of the class. The contract is either defined explicitly by being documented, or implicitly defined by the current behaviour, which someone may depend on (some other class inside HttpClient, or an external API client). The one I really don't like is: * Test that AuthChallengeParser.extractScheme( Basic realm=\realm\); throws a MalformedChallengeException because there's a leading space. Now in strict mode that's fine and within HttpClient the leading space is stripped before being passed in but it seems overly strict to me. Again, if the contract of that method says that a leading white space -- or some other irregularity -- causes a specific exception to be thrown, it is good that there are test cases to verify the contract. Maybe it is not the test that you dislike, but rather the behaviour of the method? In that case the contract should be changed to say any leading or trailing white space will be trimmed or something like that. But that has nothing to do with the test being invalid IMHO. Now, I don't mind what happens with any of these decisions to be honest as none affect the actual behaviour of HttpClient - they are very much edge cases. I would however like to set up a policy on the types of test cases I should create (do we want to avoid testing things like the pedantic things above) as well as the best way to keep track of questionable or overly pedantic test cases. Currently I'm just adding a // pedantic above any test case that seems pedantic and a todo comment over anything that I think may require a change to the code but isn't clearly a bug. I figure from time to time I can provide a list of issues that need to be considered as I work my way through the codebase. Personally, I'm hoping to achieve 100% test coverage firstly because I've discovered how dependent I am on having good test cases while working on HttpClient (most people don't have the detailed level of knowledge that Mike and Oleg do and thus aren't aware that a change will break some other section of code - NTLM is a regular victim of this). Also, aiming for 100% coverage makes a very clear-cut decision on when the job is done which make life easier as well and makes it much more noticeable when new test cases need to be added. Any thoughts? Achieving 100% (or any other hard number) of code coverage is a lot of work, and almost never guarantees that the code is free of errors. Making some percentage of code coverage a hard requirement is usually missing the point. Of course, more coverage is usually good, but there's a point of diminishing return Anyway, while tests like the pedantic ones you outlined are probably not critical, I see no reason to throw them away if they're already present. They serve the very good purpose of testing error conditions and asserting the contract of the class under test. Just my two cents. -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20942] - Request with DIGEST authentication fails when redirected
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20942. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20942 Request with DIGEST authentication fails when redirected --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 13:06 --- Makes sense to me. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20938] - Missing Content-Length header causes a SocketException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938 Missing Content-Length header causes a SocketException --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 13:06 --- It does not affect it at all. I believe the patch is good to go now Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19373] - Performance Optimizations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19373 Performance Optimizations --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 13:08 --- Looks good to me. There's also a test case for duplicate content length but I'm not sure how valid it is. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19373] - Performance Optimizations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19373 Performance Optimizations --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 13:14 --- The test does not seem to be of any relevance anymore, but I would leave it be Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Coverage
Again, if the contract of that method says that a leading white space -- or some other irregularity -- causes a specific exception to be thrown, it is good that there are test cases to verify the contract. Maybe it is not the test that you dislike, but rather the behaviour of the method? In that case the contract should be changed to say any leading or trailing white space will be trimmed or something like that. But that has nothing to do with the test being invalid IMHO. Agreed, I don't like the behaviour of the class, but I also don't like adding a test which aims to guarantee that that behavior will not change. The implicit assumptions people make are not part of the contract of the method. The contract of the method is defined in the JavaDocs for the method (hence keeping JavaDocs up to date is so important), and for HttpClient also in the relevant RFCs and standards. It goes without saying that the behavior of HttpClient will change so we need tests that reliably show errors rather than tests which are constantly being changed because they're too strict - that just leads to tests failing tests being ignored. Achieving 100% (or any other hard number) of code coverage is a lot of work, and almost never guarantees that the code is free of errors. Making some percentage of code coverage a hard requirement is usually missing the point. Of course, more coverage is usually good, but there's a point of diminishing return Agreed, we need good test cases not just code coverage. The biggest advantage of having a set percentage coverage is that it (hopefully) sparks a test writing session when things fall below that level. Anyway, while tests like the pedantic ones you outlined are probably not critical, I see no reason to throw them away if they're already present. They serve the very good purpose of testing error conditions and asserting the contract of the class under test. Currently HttpClient has about 47% code coverage and there are almost none of these pedantic tests in our test suite. Much of the new test cases I add to improve code coverage will likely be these pedantic cases since we are generally pretty good at adding tests for major features. The question is then, is it worth adding these tests or is it likely to just cause so too many test failures in the future and diminish the effectiveness of our tests. Just my two cents. Thanks it's appreciated. :) -chris Regards, Adrian Sutton. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20938] - Missing Content-Length header causes a SocketException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938 Missing Content-Length header causes a SocketException [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 13:35 --- Patch committed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19373] - Performance Optimizations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19373 Performance Optimizations [EMAIL PROTECTED] changed: What|Removed |Added Version|2.0 Alpha 3 |2.0 Beta 1 --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 16:36 --- Patch (getResponseContentLength optimization) committed. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20942] - Request with DIGEST authentication fails when redirected
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20942. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20942 Request with DIGEST authentication fails when redirected [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-06-20 16:47 --- Committed. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commas in Cookie Value
Ron, You may not to have to wait long. As soon as 2.0 release is branched out, that is going to be one of the first things fixed. Release 2.0 branching can well happen by mid July Cheers Oleg On Fri, 2003-06-20 at 14:31, Ron Tower wrote: Oleg, I noticed that there didn't seem to be a way to plug in a custom CookieSpec. I was wondering how to do it. For now, I will wait for 2.1 or download the source and modify one of the CookieSpecs. Thanks, Ron Tower - Original Message - From: Oleg Kalnichevski [EMAIL PROTECTED] To: Commons HttpClient Project [EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 5:32 PM Subject: Re: Commas in Cookie Value Ron (I apologise for misspelling your name in my previous post), You can easily subclass any of the CookieSpec classes. The trouble is there's no way to plug a custom cookie spec into the existing implementation of HttpClient. At the moment you have to modify CookiePolicy class and recompile Httpclient in order to get it done. We are aware of the problem and will address it in 2.1 release. Oleg PS: Brett's patch may eventually make it into the official Httpclient source tree, but that is not going to happen too soon. Maybe in 3.0 On Wed, 2003-06-18 at 22:06, Ron Tower wrote: Brett, I didn't download the source, just the jar and the docs. Could I subclass from a CookieSpec and just replace the parse of Set-Cookie? I would prefer to not have to modify the source so I can easily replace it with upcoming versions without having to put my change back in. Is your fix going into the main source? Do you know when? But if there is no other way, I can download the source, and then I would appreciate your fix. Thanks, Ron Tower - Original Message - From: Brett Knights [EMAIL PROTECTED] To: Commons HttpClient Project [EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 3:06 PM Subject: Re: Commas in Cookie Value I have a fix for this but it uses the org.apache.oro regular expression parser. E-mail me off line if you want the code to hack your own copy of HttpClient - Original Message - From: Ron Tower [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 9:26 AM Subject: Commas in Cookie Value Hello All, Is there a problem when a comma appears in a cookie value? See 02109POS below. It has a comma in the value and is split into two cookies. IE at least parses this cookie as one cookie. Is there a workaround for this? My understanding is that a cookie value can have any character other than a semicolon, space, or tab. I got the following Set-Cookie headers: [DEBUG] wire - - Set-cookie: CDSContentDistributor=137169; expires=Tuesday, 17-Jun-03 20:52:01 GMT; path=/[\r][\n] [DEBUG] wire - - Set-cookie: 02109POS=www4210513143792642538,; domain=.fidelity.com; path=/; expires=Fri, 12-Sep-2003 00:00:00 GMT;[\r][\n] [DEBUG] wire - - Set-cookie: MC=clHza1XIKW50aXo3nr5LD3gDFYMSAiWYtqihBBHXpfPA37wNqncGBQAGBT7vfRk AP03; expires=Monday, 15-Sep-2003 20:42:01 GMT; domain=.fidelity.com; path=/[\r][\n] And HttpClient sent the following Cookies: [DEBUG] wire - - Cookie: $Version=0; CDSContentDistributor=137169; $Path=/[\r][\n] [DEBUG] wire - - Cookie: $Version=0; 02109POS=www4210513143792642538[\r][\n] [DEBUG] wire - - Cookie: $Version=0; =; $Domain=.fidelity.com; $Path=/[\r][\n] [DEBUG] wire - - Cookie: $Version=0; MC=clHza1XIKW50aXo3nr5LD3gDFYMSAiWYtqihBBHXpfPA37wNqncGBQAGBT7vfRk AP03; $Domain=.fidelity.com; $Path=/[\r][\n] Thanks, Ron Tower - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URI query escapes
I wish I'd done a bit more digging before my original post. It turns out the problem is that parameters were being encoded *twice*. We were encoding them once on our own, then the URI constructor was encoding them again. My Mountain View example was being encoded as Mountain%2520View. If we encode them only once (even with %20 rather than +) everything works. Good I'm glad that's working now. ... are we correctly handling query params by URI encoding them? Probably not. HTTP 4.01 http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1 says: application/x-www-form-urlencoded This is the default content type. Forms submitted with this content type must be encoded as follows: 1. Control names and values are escaped. Space characters are replaced by `+', and then reserved characters are escaped as described in [RFC1738] http://www.w3.org/TR/html4/references.html#ref-RFC1738, section 2.2: Non-alphanumeric characters are replaced by `%HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as CR LF pairs (i.e., `%0D%0A'). Section 4 says must means MUST in the rfc2119 sense, so I think we have to do URL encoding rather than URI encoding for the query parameters. A quick replacement of ' ' with '+' followed by the usual URI encoding might do it. Yes, but this is for application/x-www-form-urlencoded values. Currently we only assume this content type for post params (this was recently fixed). Standard query params are using the URI encoding. The confusing part is that it's possible to submit a form via a GET. In this case the params are passed in the query. In this case should application/x-www-form-urlencoded be used? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URI query escapes
Michael Becke wrote: Yes, but this is for application/x-www-form-urlencoded values. Currently we only assume this content type for post params (this was recently fixed). I think we have to assume it for get params too. In the HTTP 4.01 spec, 17.13.3.4 http://www.w3.org/TR/html4/interact/forms.html#h-17.13.3.4: If the method is get and the action is an HTTP URI, the user agent takes the value of action, appends a `?' to it, then appends the form data set, encoded using the application/x-www-form-urlencoded content type. The user agent then traverses the link to this URI. In this scenario, form data are restricted to ASCII codes. So urlencoded seems like the right default for get query parameters. -- Laura BTW, how do you all feel about newsgroup posts in HTML format? I left this one in HTML because of all the links, but I'll stop if any of you have news readers that can't deal with it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PATCH org.apache.commons.httpclient.methods.multipart.FilePart
Hey Mike, Adrian Oleg Got it. Thanks for the kick in the right direction. I wasn't seeing addPart. Please find attached the contrib file. Hope it helps someone else. I tried to make it as apacheish as possible if it needs any changes just let me know. Thanks to everyone working on httpclient. It's been a really nice find. I'm using to at work, but I've gotten more out of it at home. Eric -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 11:01 PM To: Commons HttpClient Project Subject: Re: PATCH org.apache.commons.httpclient.methods.multipart.FilePart Eric, You want to create the FilePart manually and then add it to the MultipartPostMethod. Something like: MultipartPostMethod mpm = new MultipartPostMethod( http://localhost:8080/something; ); FilePart part = new FilePart(name, file, contentType, charset); mpm.addPart(part); Mike On Thursday, June 19, 2003, at 10:23 PM, Eric M Devlin wrote: Hey Adrian, Ok, but what about what something below? MultipartPostMethod mpm = new MultipartPostMethod( http://localhost:8080; + /something ); mpm.addParameter( A,new File( /usr/dev/images/add.gif ) ); How do I set the content type for the file? It seems either the addParameter needs to return FilePart which would have to have setters provided or an overloaded version of addParameter which accepted the content type and charset. //MultipartPostMethod public void addParameter(String parameterName, File parameterFile, String contentType, String charset ) -- or -- //MultipartPostMethod public FilePart addParameter(String parameterName, File parameterFile ) //FilePart public void setContentType( String contentType ) public void setCharset( String charset ) I've got the code pulled into class but without a place to apply it's going to be pretty useless. ;- I think this is why I was putting the contentType determination in the FilePart class it self. Just let me know. Eric -Original Message- From: Adrian Sutton [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 11:10 PM To: Commons HttpClient Project Subject: Re: PATCH org.apache.commons.httpclient.methods.multipart.FilePart Hi Eric, This isn't really something that should be included directly into HttpClient as HttpClient isn't intended to care about the actual content it sends and receives but just takes care of the actual HTTP protocol side of things. Adding auto-mime type detection would mean we'd also have to provide a way to configure the default mime-types etc, in other words it opens a whole can of worms. However, this would be an excellent submission to the HttpClient contrib package, particularly if we refactor it so that instead of being a patch it's a complete class that extends FilePart to add the functionality, then it could easily be used without any changes to HttpClient. Would you be happy with that course of action? If so, would you like to adapt the patch into a standalone class yourself or would you like me to take a crack at it? I don't mind either way. Thanks a lot for the contribution, it will definitely be useful to a number of people. Regards, Adrian Sutton. On Thursday, June 19, 2003, at 12:46 PM, Eric M Devlin wrote: Hey, This is a patch which will determine the content type if null based on file extension. I used the file extension mapping from $TOMCAT_HOME/conf/web.xml. As a side note, I'm having trouble sending gif files. Any thoughts or a kick in the right direction would be helpful. Thanks and Hope It Helps Eric contentTypeByExtension.txt-- - -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PATCH org.apache.commons.httpclient.methods.multipart.FilePart
Hi Eric, Thanks for your effort, unfortunately attachments don't seem to come through on the list. Could you create a new bug in bugzilla for this and attach the file to that? Thanks, Adrian Sutton On Saturday, June 21, 2003, at 12:57 PM, Eric M Devlin wrote: Hey Mike, Adrian Oleg Got it. Thanks for the kick in the right direction. I wasn't seeing addPart. Please find attached the contrib file. Hope it helps someone else. I tried to make it as apacheish as possible if it needs any changes just let me know. Thanks to everyone working on httpclient. It's been a really nice find. I'm using to at work, but I've gotten more out of it at home. Eric -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 11:01 PM To: Commons HttpClient Project Subject: Re: PATCH org.apache.commons.httpclient.methods.multipart.FilePart Eric, You want to create the FilePart manually and then add it to the MultipartPostMethod. Something like: MultipartPostMethod mpm = new MultipartPostMethod( http://localhost:8080/something; ); FilePart part = new FilePart(name, file, contentType, charset); mpm.addPart(part); Mike On Thursday, June 19, 2003, at 10:23 PM, Eric M Devlin wrote: Hey Adrian, Ok, but what about what something below? MultipartPostMethod mpm = new MultipartPostMethod( http://localhost:8080; + /something ); mpm.addParameter( A,new File( /usr/dev/images/add.gif ) ); How do I set the content type for the file? It seems either the addParameter needs to return FilePart which would have to have setters provided or an overloaded version of addParameter which accepted the content type and charset. //MultipartPostMethod public void addParameter(String parameterName, File parameterFile, String contentType, String charset ) -- or -- //MultipartPostMethod public FilePart addParameter(String parameterName, File parameterFile ) //FilePart public void setContentType( String contentType ) public void setCharset( String charset ) I've got the code pulled into class but without a place to apply it's going to be pretty useless. ;- I think this is why I was putting the contentType determination in the FilePart class it self. Just let me know. Eric -Original Message- From: Adrian Sutton [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 11:10 PM To: Commons HttpClient Project Subject: Re: PATCH org.apache.commons.httpclient.methods.multipart.FilePart Hi Eric, This isn't really something that should be included directly into HttpClient as HttpClient isn't intended to care about the actual content it sends and receives but just takes care of the actual HTTP protocol side of things. Adding auto-mime type detection would mean we'd also have to provide a way to configure the default mime-types etc, in other words it opens a whole can of worms. However, this would be an excellent submission to the HttpClient contrib package, particularly if we refactor it so that instead of being a patch it's a complete class that extends FilePart to add the functionality, then it could easily be used without any changes to HttpClient. Would you be happy with that course of action? If so, would you like to adapt the patch into a standalone class yourself or would you like me to take a crack at it? I don't mind either way. Thanks a lot for the contribution, it will definitely be useful to a number of people. Regards, Adrian Sutton. On Thursday, June 19, 2003, at 12:46 PM, Eric M Devlin wrote: Hey, This is a patch which will determine the content type if null based on file extension. I used the file extension mapping from $TOMCAT_HOME/conf/web.xml. As a side note, I'm having trouble sending gif files. Any thoughts or a kick in the right direction would be helpful. Thanks and Hope It Helps Eric contentTypeByExtension.txt- - - -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
