cvs commit: jakarta-commons-sandbox/io/xdocs tasks.xml
bayard 2004/01/01 23:00:44 Modified:io/xdocs tasks.xml Log: updated task Revision ChangesPath 1.14 +1 -1 jakarta-commons-sandbox/io/xdocs/tasks.xml Index: tasks.xml === RCS file: /home/cvs/jakarta-commons-sandbox/io/xdocs/tasks.xml,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- tasks.xml 2 Jan 2004 06:25:33 - 1.13 +++ tasks.xml 2 Jan 2004 07:00:44 - 1.14 @@ -8,7 +8,7 @@ /p ul liFilenameUtils: This class is a big mess ATM. We need to clean it up./li -liIOUtilsTestCase: Move copy tests over to CopyUtilsTestCase or kill them. [Hen]/li +liIOUtilsTestCase: Handle unit tests that test an IOUtils method and a CopyUtils method at the same time. [Hen]/li liWrite TestCases for: ul liEndianUtils - InputStream/OutputStream methods/li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/codec/src/java/org/apache/commons/codec/digest DigestUtils.java
ggregory2004/01/01 23:01:48 Modified:codec/src/java/org/apache/commons/codec/net URLCodec.java codec/src/java/org/apache/commons/codec EncoderException.java StringEncoder.java Encoder.java StringDecoder.java DecoderException.java BinaryDecoder.java BinaryEncoder.java StringEncoderComparator.java Decoder.java codec/src/java/org/apache/commons/codec/language Metaphone.java SoundexUtils.java DoubleMetaphone.java RefinedSoundex.java Soundex.java codec/src/java/org/apache/commons/codec/binary Base64.java Hex.java codec/src/java/org/apache/commons/codec/digest DigestUtils.java Log: Fix license typo: Products derived from this software may not be called Apache, *Apache nor may Apache appear in their name [...] There is a double word in there. This LICENSE FILE is from the main Jakata Commons page. Revision ChangesPath 1.12 +4 -4 jakarta-commons/codec/src/java/org/apache/commons/codec/net/URLCodec.java Index: URLCodec.java === RCS file: /home/cvs/jakarta-commons/codec/src/java/org/apache/commons/codec/net/URLCodec.java,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- URLCodec.java 24 Nov 2003 00:11:56 - 1.11 +++ URLCodec.java 2 Jan 2004 07:01:47 - 1.12 @@ -3,7 +3,7 @@ * * The Apache Software License, Version 1.1 * - * Copyright (c) 2001-2003 The Apache Software Foundation. All rights + * Copyright (c) 2001-2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without @@ -30,8 +30,8 @@ *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, - *Apache nor may Apache appear in their name without prior + * 5. Products derived from this software may not be called Apache + *nor may Apache appear in their name without prior *written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED 1.8 +4 -4 jakarta-commons/codec/src/java/org/apache/commons/codec/EncoderException.java Index: EncoderException.java === RCS file: /home/cvs/jakarta-commons/codec/src/java/org/apache/commons/codec/EncoderException.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- EncoderException.java 5 Oct 2003 21:45:48 - 1.7 +++ EncoderException.java 2 Jan 2004 07:01:47 - 1.8 @@ -3,7 +3,7 @@ * * The Apache Software License, Version 1.1 * - * Copyright (c) 2001-2003 The Apache Software Foundation. All rights + * Copyright (c) 2001-2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without @@ -30,8 +30,8 @@ *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, - *Apache nor may Apache appear in their name without prior + * 5. Products derived from this software may not be called Apache + *nor may Apache appear in their name without prior *written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED 1.7 +4 -4 jakarta-commons/codec/src/java/org/apache/commons/codec/StringEncoder.java Index: StringEncoder.java === RCS file: /home/cvs/jakarta-commons/codec/src/java/org/apache/commons/codec/StringEncoder.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- StringEncoder.java5 Oct 2003 21:45:48 - 1.6 +++ StringEncoder.java2 Jan 2004 07:01:47 - 1.7 @@ -3,7 +3,7 @@ * * The Apache Software License, Version 1.1 * - * Copyright (c) 2001-2003 The Apache Software Foundation. All rights + * Copyright (c) 2001-2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without @@ -30,8 +30,8 @@ *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * - * 5. Products derived from this software
cvs commit: jakarta-commons/codec/src/test/org/apache/commons/codec/binary Base64Test.java HexTest.java
ggregory2004/01/01 23:05:37 Modified:codec/src/test/org/apache/commons/codec BinaryEncoderAbstractTest.java StringEncoderComparatorTest.java StringEncoderAbstractTest.java codec/src/test/org/apache/commons/codec/language SoundexTest.java RefinedSoundexTest.java MetaphoneTest.java AllTests.java DoubleMetaphoneTest.java codec/src/test/org/apache/commons/codec/net URLCodecTest.java codec/src/test/org/apache/commons/codec/digest DigestUtilsTest.java codec/src/test/org/apache/commons/codec/binary Base64Test.java HexTest.java Log: Fix license typo: Products derived from this software may not be called Apache, *Apache nor may Apache appear in their name [...] There is a double word in there. This LICENSE FILE is from the main Jakata Commons page. Revision ChangesPath 1.6 +4 -4 jakarta-commons/codec/src/test/org/apache/commons/codec/BinaryEncoderAbstractTest.java Index: BinaryEncoderAbstractTest.java === RCS file: /home/cvs/jakarta-commons/codec/src/test/org/apache/commons/codec/BinaryEncoderAbstractTest.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- BinaryEncoderAbstractTest.java5 Oct 2003 21:45:49 - 1.5 +++ BinaryEncoderAbstractTest.java2 Jan 2004 07:05:36 - 1.6 @@ -3,7 +3,7 @@ * * The Apache Software License, Version 1.1 * - * Copyright (c) 2001-2003 The Apache Software Foundation. All rights + * Copyright (c) 2001-2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without @@ -30,8 +30,8 @@ *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, - *Apache nor may Apache appear in their name without prior + * 5. Products derived from this software may not be called Apache + *nor may Apache appear in their name without prior *written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED 1.7 +4 -4 jakarta-commons/codec/src/test/org/apache/commons/codec/StringEncoderComparatorTest.java Index: StringEncoderComparatorTest.java === RCS file: /home/cvs/jakarta-commons/codec/src/test/org/apache/commons/codec/StringEncoderComparatorTest.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- StringEncoderComparatorTest.java 12 Oct 2003 01:35:17 - 1.6 +++ StringEncoderComparatorTest.java 2 Jan 2004 07:05:36 - 1.7 @@ -3,7 +3,7 @@ * * The Apache Software License, Version 1.1 * - * Copyright (c) 2001-2003 The Apache Software Foundation. All rights + * Copyright (c) 2001-2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without @@ -30,8 +30,8 @@ *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, - *Apache nor may Apache appear in their name without prior + * 5. Products derived from this software may not be called Apache + *nor may Apache appear in their name without prior *written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED 1.6 +4 -4 jakarta-commons/codec/src/test/org/apache/commons/codec/StringEncoderAbstractTest.java Index: StringEncoderAbstractTest.java === RCS file: /home/cvs/jakarta-commons/codec/src/test/org/apache/commons/codec/StringEncoderAbstractTest.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- StringEncoderAbstractTest.java5 Oct 2003 21:45:49 - 1.5 +++ StringEncoderAbstractTest.java2 Jan 2004 07:05:36 - 1.6 @@ -3,7 +3,7 @@ * * The Apache Software License, Version 1.1 * - * Copyright (c) 2001-2003 The Apache Software Foundation. All rights + * Copyright (c) 2001-2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without @@ -30,8 +30,8 @@ *from this software without prior written permission. For written *
cvs commit: jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input SwappedDataInputStreamTest.java
bayard 2004/01/01 23:31:18
Added: io/src/test/org/apache/commons/io/input
SwappedDataInputStreamTest.java
Log:
A beginning on a test for the SwappedDataInputStream, though it only handles the
basics
Revision ChangesPath
1.1
jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input/SwappedDataInputStreamTest.java
Index: SwappedDataInputStreamTest.java
===
/*
* $Header:
/home/cvs/jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input/SwappedDataInputStreamTest.java,v
1.1 2004/01/02 07:31:18 bayard Exp $
* $Revision: 1.1 $
* $Date: 2004/01/02 07:31:18 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2004 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, Commons, 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.io.input;
import java.io.ByteArrayInputStream;
import java.io.IOException;
import junit.framework.TestCase;
/**
* Test for the SwappedDataInputStream. This also
* effectively tests the underlying EndianUtils Stream methods.
*
* @author Henri Yandell (bayard at apache dot org)
* @version $Revision: 1.1 $ $Date: 2004/01/02 07:31:18 $
*/
public class SwappedDataInputStreamTest extends TestCase {
private SwappedDataInputStream sdis;
public SwappedDataInputStreamTest(String name) {
super(name);
}
public void setUp() {
// This does not seem to be the right fake setup.
// The EndianUtils Stream methods read an integer at a time,
// and not a byte.
byte[] bytes = new byte[] {
0x01,
0x02,
0x03,
0x04,
0x05,
0x06,
0x07,
0x08
};
ByteArrayInputStream bais = new ByteArrayInputStream( bytes );
this.sdis = new SwappedDataInputStream( bais );
}
public void tearDown() {
this.sdis = null;
}
public void testReadBoolean() throws IOException {
assertEquals( false, this.sdis.readBoolean() );
}
public void testReadByte() throws IOException {
assertEquals( 0x01, this.sdis.readByte() );
}
public void testReadChar() throws
cvs commit: jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input SwappedDataInputStreamTest.java
bayard 2004/01/01 23:37:00
Modified:io/src/test/org/apache/commons/io/input
SwappedDataInputStreamTest.java
Log:
removed wrong comment due to my misunderstanding of usage
Revision ChangesPath
1.2 +3 -6
jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input/SwappedDataInputStreamTest.java
Index: SwappedDataInputStreamTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input/SwappedDataInputStreamTest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SwappedDataInputStreamTest.java 2 Jan 2004 07:31:18 - 1.1
+++ SwappedDataInputStreamTest.java 2 Jan 2004 07:37:00 - 1.2
@@ -86,9 +86,6 @@
}
public void setUp() {
-// This does not seem to be the right fake setup.
-// The EndianUtils Stream methods read an integer at a time,
-// and not a byte.
byte[] bytes = new byte[] {
0x01,
0x02,
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/java/org/apache/commons/io EndianUtils.java
bayard 2004/01/01 23:43:34
Modified:io/src/java/org/apache/commons/io EndianUtils.java
Log:
removed unnecessary line
Revision ChangesPath
1.10 +3 -3
jakarta-commons-sandbox/io/src/java/org/apache/commons/io/EndianUtils.java
Index: EndianUtils.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/java/org/apache/commons/io/EndianUtils.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- EndianUtils.java 30 Dec 2003 06:52:49 - 1.9
+++ EndianUtils.java 2 Jan 2004 07:43:34 - 1.10
@@ -250,8 +250,8 @@
*/
public static long readSwappedLong( byte[] data, int offset )
{
-long ln = (long)( ( ( data[ offset + 0 ] 0xff ) 0 ) );
-long low = (long)( ( ( data[ offset + 0 ] 0xff ) 0 ) +
+long low = (long)(
+( ( data[ offset + 0 ] 0xff ) 0 ) +
( ( data[ offset + 1 ] 0xff ) 8 ) +
( ( data[ offset + 2 ] 0xff ) 16 ) +
( ( data[ offset + 3 ] 0xff ) 24 ) );
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input SwappedDataInputStreamTest.java
bayard 2004/01/01 23:52:57
Modified:io/src/test/org/apache/commons/io/input
SwappedDataInputStreamTest.java
Log:
tests readLong now
Revision ChangesPath
1.3 +5 -5
jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input/SwappedDataInputStreamTest.java
Index: SwappedDataInputStreamTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input/SwappedDataInputStreamTest.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SwappedDataInputStreamTest.java 2 Jan 2004 07:37:00 - 1.2
+++ SwappedDataInputStreamTest.java 2 Jan 2004 07:52:57 - 1.3
@@ -136,11 +136,11 @@
/*
public void testReadLine() throws IOException {
}
+*/
public void testReadLong() throws IOException {
assertEquals( 0x0807060504030201L, this.sdis.readLong() );
}
-*/
public void testReadShort() throws IOException {
assertEquals( (short) 0x0201, this.sdis.readShort() );
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/java/org/apache/commons/io EndianUtils.java
bayard 2004/01/01 23:53:46
Modified:io/src/java/org/apache/commons/io EndianUtils.java
Log:
Fixed what I think is a bug in readSwappedLong(InputStream) by rewriting the method
to use the readSwappedLong(byte[])
Revision ChangesPath
1.11 +4 -18
jakarta-commons-sandbox/io/src/java/org/apache/commons/io/EndianUtils.java
Index: EndianUtils.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/java/org/apache/commons/io/EndianUtils.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- EndianUtils.java 2 Jan 2004 07:43:34 - 1.10
+++ EndianUtils.java 2 Jan 2004 07:53:46 - 1.11
@@ -444,23 +444,9 @@
public static long readSwappedLong( InputStream input )
throws IOException
{
-int value1 = read( input );
-int value2 = read( input );
-int value3 = read( input );
-int value4 = read( input );
-int value5 = read( input );
-int value6 = read( input );
-int value7 = read( input );
-int value8 = read( input );
-
-return (long)( ( ( value1 0xff ) 0 ) +
-( ( value2 0xff ) 8 ) +
-( ( value3 0xff ) 16 ) +
-( ( value4 0xff ) 24 ) +
-( ( value5 0xff ) 32 ) +
-( ( value6 0xff ) 40 ) +
-( ( value7 0xff ) 48 ) +
-( ( value8 0xff ) 56 ) );
+byte[] bytes = new byte[8];
+input.read( bytes );
+return readSwappedLong( bytes, 0 );
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/xdocs tasks.xml
bayard 2004/01/01 23:54:03 Modified:io/xdocs tasks.xml Log: SwappedDataInputStream has half its tests now, so recording this Revision ChangesPath 1.15 +1 -1 jakarta-commons-sandbox/io/xdocs/tasks.xml Index: tasks.xml === RCS file: /home/cvs/jakarta-commons-sandbox/io/xdocs/tasks.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- tasks.xml 2 Jan 2004 07:00:44 - 1.14 +++ tasks.xml 2 Jan 2004 07:54:03 - 1.15 @@ -14,7 +14,7 @@ liEndianUtils - InputStream/OutputStream methods/li liLockableFileWriter/li liClassLoaderObjectInputStream/li - liSwappedDataInputStream/li + liSwappedDataInputStream - [half done]/li /ul though they may not affect an initial beta release. /li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[io] EndianUtils....
I think the:
public static long readSwappedLong( InputStream input )
throws IOException
{
int value1 = read( input );
int value2 = read( input );
int value3 = read( input );
int value4 = read( input );
int value5 = read( input );
int value6 = read( input );
int value7 = read( input );
int value8 = read( input );
return (long)( ( ( value1 0xff ) 0 ) +
( ( value2 0xff ) 8 ) +
( ( value3 0xff ) 16 ) +
( ( value4 0xff ) 24 ) +
( ( value5 0xff ) 32 ) +
( ( value6 0xff ) 40 ) +
( ( value7 0xff ) 48 ) +
( ( value8 0xff ) 56 ) );
}
code is wrong as it doesn't look like the other readSwappedLong for a
byte[]. I've rewritten it as:
byte[] bytes = new byte[8];
input.read( bytes );
return readSwappedLong( bytes, 0 );
Just in case anyone with a clue has an opinion on the fix.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input SwappedDataInputStreamTest.java
bayard 2004/01/01 23:59:13
Modified:io/src/test/org/apache/commons/io/input
SwappedDataInputStreamTest.java
Log:
double and float tests succeed now
Revision ChangesPath
1.4 +8 -10
jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input/SwappedDataInputStreamTest.java
Index: SwappedDataInputStreamTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input/SwappedDataInputStreamTest.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SwappedDataInputStreamTest.java 2 Jan 2004 07:52:57 - 1.3
+++ SwappedDataInputStreamTest.java 2 Jan 2004 07:59:13 - 1.4
@@ -116,15 +116,15 @@
assertEquals( (char) 0x0201, this.sdis.readChar() );
}
-/*
public void testReadDouble() throws IOException {
-assertEquals( (double) 0x0807060504030201L, this.sdis.readDouble(), 0 );
+assertEquals( Double.longBitsToDouble(0x0807060504030201L),
this.sdis.readDouble(), 0 );
}
public void testReadFloat() throws IOException {
-assertEquals( (float) 0x04030201F, this.sdis.readFloat(), 0 );
+assertEquals( Float.intBitsToFloat(0x04030201), this.sdis.readFloat(), 0 );
}
+/*
public void testReadFully() throws IOException {
}
*/
@@ -146,7 +146,7 @@
assertEquals( (short) 0x0201, this.sdis.readShort() );
}
-/*
+/*
public void testReadUnsignedByte() throws IOException {
}
@@ -164,9 +164,7 @@
/*
public void testSkipBytes() throws IOException {
-assertEquals( (float) 0x04030201, this.sdis.skipBytes() );
}
-
*/
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input SwappedDataInputStreamTest.java
bayard 2004/01/02 00:04:09
Modified:io/src/test/org/apache/commons/io/input
SwappedDataInputStreamTest.java
Log:
skipBytes test added
Revision ChangesPath
1.5 +7 -7
jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input/SwappedDataInputStreamTest.java
Index: SwappedDataInputStreamTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input/SwappedDataInputStreamTest.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- SwappedDataInputStreamTest.java 2 Jan 2004 07:59:13 - 1.4
+++ SwappedDataInputStreamTest.java 2 Jan 2004 08:04:09 - 1.5
@@ -133,7 +133,7 @@
assertEquals( (int) 0x04030201, this.sdis.readInt() );
}
-/*
+/*
public void testReadLine() throws IOException {
}
*/
@@ -162,9 +162,9 @@
}
}
-/*
public void testSkipBytes() throws IOException {
+this.sdis.skipBytes(4);
+assertEquals( (int)0x08070605, this.sdis.readInt() );
}
-*/
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input SwappedDataInputStreamTest.java
bayard 2004/01/02 00:06:57
Modified:io/src/test/org/apache/commons/io/input
SwappedDataInputStreamTest.java
Log:
readLine 'test' for UnsupportedException added
Revision ChangesPath
1.6 +9 -6
jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input/SwappedDataInputStreamTest.java
Index: SwappedDataInputStreamTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/test/org/apache/commons/io/input/SwappedDataInputStreamTest.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- SwappedDataInputStreamTest.java 2 Jan 2004 08:04:09 - 1.5
+++ SwappedDataInputStreamTest.java 2 Jan 2004 08:06:57 - 1.6
@@ -133,10 +133,13 @@
assertEquals( (int) 0x04030201, this.sdis.readInt() );
}
-/*
public void testReadLine() throws IOException {
+try {
+String unexpected = this.sdis.readLine();
+fail(readLine should be unsupported. );
+} catch(UnsupportedOperationException uoe) {
+}
}
-*/
public void testReadLong() throws IOException {
assertEquals( 0x0807060504030201L, this.sdis.readLong() );
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] CaseInsensitiveHashMap
I have written the 3 lines necessary to implement a CaseInsensitiveHashMap by extending HashedMap. Before committing, I have a couple of questions / consensus points. 1. I made no attempt to handle or mask nulls -- puts with null keys will throw NPEs. 2. I made no attempt at allowing the locale to be set or otherwise changing the default behavior of toLower() in convert(). 3. I need the secret recipe for making the canonical serialized object file so that I don't have to dummy out the compatability tests (or not :) Is this documented somewhere? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] CaseInsensitiveHashMap
from:Phil Steitz [EMAIL PROTECTED] 1. I made no attempt to handle or mask nulls -- puts with null keys will throw NPEs. This seems harsh. I would prefer to support nulls if possible. 2. I made no attempt at allowing the locale to be set or otherwise changing the default behavior of toLower() in convert(). I'm wondering how your implementation works. I was expecting the isEqualKey() method to be overridden, rather than converting the key on add. (Note that the same code also has to go in a MapEntry) 3. I need the secret recipe for making the canonical serialized object file so that I don't have to dummy out the compatability tests (or not :) Is this documented somewhere? Its commented out in the bottom of some of the tests. (HashedMap?) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections][lang] 2004
We've certainly done total updates in the past. After all, chaning the license constitutes changing the contents ;-) Also, I was going to apply the same dates to all files. (1999-2004 for collections). This is because there is no accuracy to the start dates on files. The licenses just get copied from the nearest file to hand. The other reason to do it en masse is that it'll get forgotten otherwise. Stephen I assume we'd replace -2003 with -2004. So not a problem, then ([^-])2003 with \12003-2004 perhaps to add those on. And 2001, 2003, etc. The problem is that I am not sure that blast updating when there is no change to the protected content is correct. I am not a lawyer, but my understanding is that the last date in the copyright notice should be the year when the content was last changed. I am -0 to doing a blast update. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] BinaryHeap and PriorityQueue
from:Phil Steitz [EMAIL PROTECTED] I was also looking at the heap impl and wondering if the compare method could check for ascendingOrder, then removing the need for near duplicate methods (one for minHeap, one for maxHeap) elsewhere. Would this be a good change? That would simplify the code, but might cost something in overall performance (since compare is hot). Could be that's why the original author(s) set it up the way it is? Should be trivial. Might be worth playing with. Its hassle vs absolute performance. Always tricky in collections. Another solution would be to just have the constructor reverse the comparator for maxHeaps (using ComparatorUtils.reversedComparator). There the cost would be stack operations for each compare (calling through to the reversed comparator). The comparator is returned by a method in PriorityBuffer, so this might cause problems. (Of course the null comparator could similarly be represented by a ComparableComparator at the cost of an object creation) Another (small?) consideration is backward compatability for anyone who has subclassed BinaryHeap (assuming we are not going to deprecate), since all of the percolateXxx methods are protected, not private. No backwards compatability issues - BinaryHeap is final, PriorityBuffer is new :-) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] CaseInsensitiveHashMap
--- Phil Steitz [EMAIL PROTECTED] wrote: I have written the 3 lines necessary to implement a CaseInsensitiveHashMap by extending HashedMap. Before committing, I have a couple of questions / consensus points. 1. I made no attempt to handle or mask nulls -- puts with null keys will throw NPEs. HashMap supports nulls, why can't this class? David 2. I made no attempt at allowing the locale to be set or otherwise changing the default behavior of toLower() in convert(). 3. I need the secret recipe for making the canonical serialized object file so that I don't have to dummy out the compatability tests (or not :) Is this documented somewhere? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24959] - Possible enhancements to DigestUtil
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=24959. 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=24959 Possible enhancements to DigestUtil --- Additional Comments From [EMAIL PROTECTED] 2004-01-02 16:14 --- The URL is broken. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[site] Out of date: http://jakarta.apache.org/commons/components .html
Hello, The page http://jakarta.apache.org/commons/components.html is out of date WRT lang, httpclient and maybe others. If every project has a project.xml, maybe the page could be auto-generated when project is rev'ed? Gary
cvs commit: jakarta-commons/codec/xdocs navigation.xml
ggregory2004/01/02 08:38:14 Modified:codec/xdocs navigation.xml Log: project name was digester, not codec. Revision ChangesPath 1.6 +1 -1 jakarta-commons/codec/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/jakarta-commons/codec/xdocs/navigation.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- navigation.xml4 Oct 2003 16:31:30 - 1.5 +++ navigation.xml2 Jan 2004 16:38:14 - 1.6 @@ -4,7 +4,7 @@ !ENTITY commons-nav SYSTEM ../../incl_nav.xml ] -project name=Digester +project name=Codec titleCodec/title organizationLogo href=/images/jakarta-logo-blue.gif - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] CaseInsensitiveHashMap
[EMAIL PROTECTED] wrote: from:Phil Steitz [EMAIL PROTECTED] 1. I made no attempt to handle or mask nulls -- puts with null keys will throw NPEs. This seems harsh. I would prefer to support nulls if possible. OK. No problem. 2. I made no attempt at allowing the locale to be set or otherwise changing the default behavior of toLower() in convert(). I'm wondering how your implementation works. I was expecting the isEqualKey() method to be overridden, rather than converting the key on add. (Note that the same code also has to go in a MapEntry) Could be I was being too lazy. Since toLower() is idempotent (calling it repeatedly has same effect as calling it just once) it works to just override convert(), since in AbstractHashedMap, get, put, remove, containsKey, all start by converting the key (nice!). All I did was to extend HashedMap and override convert to return key.toString().toLowerCase(). The effect is that you actually store all lower case strings as keys (or null, once I fix this). The behavior should be the same as the impl that David Graham posted with PR #24537 (unless I am missing something -- quite possible). 3. I need the secret recipe for making the canonical serialized object file so that I don't have to dummy out the compatability tests (or not :) Is this documented somewhere? Its commented out in the bottom of some of the tests. (HashedMap?) Ah...I was wondering what that cruft was about ;) Thanks. Phil Stephen - 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 25862] New: - ResultSetDynaClass lowerCase broken
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=25862. 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=25862 ResultSetDynaClass lowerCase broken Summary: ResultSetDynaClass lowerCase broken Product: Commons Version: Nightly Builds Platform: Other OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Bean Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Apparently there ResultSetDynaClass presents a regression with respect to ver. 1.6.1. The lowerCase property doesn't work (or works as if it was always assigned to true). Looks like the lowerCase instance variable is defined both in JDBCDynaClass and in ResultSetDynaClass. Regardless of what you set in ResultSetDynaClass the introspect method always uses the variable in JDBCDynaClass which defaults to true. Regards, Fabio. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Out of date: http://jakarta.apache.org/commons/components .html
--- Gary Gregory [EMAIL PROTECTED] wrote: Hello, The page http://jakarta.apache.org/commons/components.html is out of date WRT lang, httpclient and maybe others. If every project has a project.xml, maybe the page could be auto-generated when project is rev'ed? I'd like to see that page removed because it's yet another step in the already time consuming release process. It's easy to forget to update it which leads to the current situation. I don't see what value it adds to the site with the components already listed in the left nav. David Gary __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Out of date: http://jakarta.apache.org/commons/components .html
I've been playing with something that might be able to replace it, based on project.xml's: http://www.apache.org/~bayard/pergamum/j-c/html-j-c-new/community_jakarta-commons.html Basically a multiproject website that is driven from the top down. Maven probably has something similar, I was playing with ideas, XSL and CSS and Commons project.xml's were the easiest database for me to get my hands on to play with. Just an idea. Hen On Fri, 2 Jan 2004, David Graham wrote: --- Gary Gregory [EMAIL PROTECTED] wrote: Hello, The page http://jakarta.apache.org/commons/components.html is out of date WRT lang, httpclient and maybe others. If every project has a project.xml, maybe the page could be auto-generated when project is rev'ed? I'd like to see that page removed because it's yet another step in the already time consuming release process. It's easy to forget to update it which leads to the current situation. I don't see what value it adds to the site with the components already listed in the left nav. David Gary __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.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: [site] Out of date: http://jakarta.apache.org/commons/components .html
David Graham wrote: --- Gary Gregory [EMAIL PROTECTED] wrote: Hello, The page http://jakarta.apache.org/commons/components.html is out of date WRT lang, httpclient and maybe others. If every project has a project.xml, maybe the page could be auto-generated when project is rev'ed? I'd like to see that page removed because it's yet another step in the already time consuming release process. It's easy to forget to update it which leads to the current situation. I don't see what value it adds to the site with the components already listed in the left nav. I agree, especially since in many/most cases the download links point to the generic binary download page. I am +1 for removing this page. We should do this or fix the links in any case. HTTPClient, Net, and Lang are all out of date and Configuration is missing from the page. Configuration also needs to be moved on the left nav from the sandbox to the Commons proper. Phil David Gary __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.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]
Contributor list doesn't include sandbox?
Is there a reason why http://jakarta.apache.org/commons/contributors.html does not include people who are working on Jakarta Commons Sandbox components, but not Commons proper? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Author tags redux
Geir Magnusson Jr wrote: On Dec 28, 2003, at 10:39 PM, Phil Steitz wrote: The subject of @author tags has been discussed on and off here and elsewhere with no apparent consensus. In a recent post to general@, Ted Husted pointed to this post http://tinyurl.com/yrlhu by Greg Stein to community at apache.org, which raises some disturbing legal and community issues around the use of @author tags. I am convinced by his arguments that we should eliminate @author tags uniformly once we clean up the web site and get the process of updating and publishing contributor lists routinized (read: complete the mavenization of the j-c web site). I'm not sure I buy the legal argument, as our CVS logs are public also, and it's easy to figure out who did what in a piece of questionable code. So you haven't really don't anything by removing the author tag - the author is still easily discoverable. As I understand Greg's argument (see paragraph that starts with From a legal standpoint) when your name is *in* the code with a tag that identifies you as the/an author, it is more likely that you may be named in a suit and it may be harder for the ASF to protect you. Commit logs are certainly discoverable, but commits are at the direction of the PMC which provides you (or the committer) with some legal cover, or so the theory goes. I think author tags are good as some/many/all people are proud to have their name on things that they work hard on and contribute. I'll be the first to admit the sense of pride that I felt when contributing something for the first time, and seeing my name on it. That is a valid point, but may be a little at odds with the equally valid point below. The valid point (IMO) I've heard in favor of removing them is that not having them can help the sense of group ownership and community. if I had to decide, as long as there is no additional liability in having the tag in the code, I'd be for letting people/components/etc choose to do what they feel is right. I agree that the decision should be at least at the component level. I guess we *could* allow contributors to decide, but that could result in some funny/misleading tags. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Out of date: http://jakarta.apache.org/commons/components .html
On Fri, 2 Jan 2004, David Graham wrote: --- Gary Gregory [EMAIL PROTECTED] wrote: Hello, The page http://jakarta.apache.org/commons/components.html is out of date WRT lang, httpclient and maybe others. If every project has a project.xml, maybe the page could be auto-generated when project is rev'ed? I'd like to see that page removed because it's yet another step in the already time consuming release process. It's easy to forget to update it which leads to the current situation. I don't see what value it adds to the site with the components already listed in the left nav. I am against removing the page completely. The value in this page is in its brief summary of what, exactly, is in Commons. A newcomer to the site would otherwise have to click through to each component individually in order to figure out what is what. I can see that the release information could easily get out of date, so I'd be OK with removing that from the page. However, I'd still like to keep the grouping of released, pre-released, etc. because that is also useful information for newcomers (and quick-stop visitors). -- Martin Cooper David Gary __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.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: Contributor list doesn't include sandbox?
On Fri, 2 Jan 2004, Noel J. Bergman wrote: Is there a reason why http://jakarta.apache.org/commons/contributors.html does not include people who are working on Jakarta Commons Sandbox components, but not Commons proper? Probably because those people don't have commit access to update the page themselves. However, I see no reason not to include them - they should only need to ask. -- Martin Cooper --- Noel - 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: [net] Branching
In message [EMAIL PROTECTED], Jeffrey D. Brekke writes: Daniel, I agree with all your ideas, but it seems to me you can branch from any tagged point in the revision history so I'm not sure what the idea is behind deleting/renaming the tags. All I was getting at was what to name the tag. My understanding was that a tag needs to be created as a branch. I should have used a concrete example. I was asking which of: cvs rtag -b -r NET_1_0_0 NET_1_1_0_MAINTENANCE jakarta-commons/net or cvs rtag -b -r NET_1_0_0 NET_FOO jakarta-commons/net cvs rtag -d NET_1_0_0 jakarta-commons/net cvs rtag -b -r NET_FOO NET_1_0_0 jakarta-commons/net cvs rtag -d NET_FOO we wanted to go with (NET_1_1_0_MAINTENANCE is just for example purposes; any other name indicating it's a branch will do). As Noel said, this stuff is easier with Subversion. Given that, as per Steve's message, we can make 1.1 compatibilty changes on HEAD, release and tag, and branch from that point in the future when/if there are bug fixes required? +1. That's easier and avoids the issue altogether. I guess we'd make NET_1_1_1 a branch tag in that case. I've got JDK 1.1.8v1 lying around on my development server if you want me to hunt for and correct any other 1.1 incompatibilities. Otherwise, if Steve's game, he could do it pretty quickly and get on with his work. I won't be back home until tomorrow afternoon and my currently erratic email polling combined with my being subscribed to the mailing list digest means I won't be able to act on anything until tomorrow afternoon. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Out of date: http://jakarta.apache.org/commons/components .html
--- Martin Cooper [EMAIL PROTECTED] wrote: On Fri, 2 Jan 2004, David Graham wrote: --- Gary Gregory [EMAIL PROTECTED] wrote: Hello, The page http://jakarta.apache.org/commons/components.html is out of date WRT lang, httpclient and maybe others. If every project has a project.xml, maybe the page could be auto-generated when project is rev'ed? I'd like to see that page removed because it's yet another step in the already time consuming release process. It's easy to forget to update it which leads to the current situation. I don't see what value it adds to the site with the components already listed in the left nav. I am against removing the page completely. The value in this page is in its brief summary of what, exactly, is in Commons. A newcomer to the site would otherwise have to click through to each component individually in order to figure out what is what. I can see that the release information could easily get out of date, so I'd be OK with removing that from the page. However, I'd still like to keep the grouping of released, pre-released, etc. because that is also useful information for newcomers (and quick-stop visitors). Sounds good to me. This way we won't have to update this page each time we cut a release. David -- Martin Cooper David Gary __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.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] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] Let's get rid of org.apache.commons.net.ftp.ftp2
Since all this code has by now been moved onto the main stem (ie, org.apache.commons.net.ftp and org.apache.commons.net.ftp.parser), there is no valid reason for keeping this package and its subpackages around anymore, and it only creates maintenance issues. Is there a recommended way to go about this? It was doubtful to me that anyone had ever used these packages, but I now see that I was wrong. Someone went and implemented an AIXFTPEntryParser in the ftp2.parser package (and not on the main stem). So I would be in favor of moving this class onto the main stem and deprecating everything in ftp2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Branching
On Fri, 2 Jan 2004, Daniel F. Savarese wrote: In message [EMAIL PROTECTED], Jeffrey D. Brekke writes: Daniel, I agree with all your ideas, but it seems to me you can branch from any tagged point in the revision history so I'm not sure what the idea is behind deleting/renaming the tags. All I was getting at was what to name the tag. My understanding was that a tag needs to be created as a branch. I should have used Sorry for jumping in here without having been following the thread (and without having the older messages to refer to any more). However, I wanted to point out that there are two distinct types of tags in CVS. Branches affect future commits, and are harder to change your mind about after the fact. Labels are just that - a label at a particular point in time - and can pretty much be moved around at will after the fact. If you already knew that, sorry for bothering you. ;-) -- Martin Cooper a concrete example. I was asking which of: cvs rtag -b -r NET_1_0_0 NET_1_1_0_MAINTENANCE jakarta-commons/net or cvs rtag -b -r NET_1_0_0 NET_FOO jakarta-commons/net cvs rtag -d NET_1_0_0 jakarta-commons/net cvs rtag -b -r NET_FOO NET_1_0_0 jakarta-commons/net cvs rtag -d NET_FOO we wanted to go with (NET_1_1_0_MAINTENANCE is just for example purposes; any other name indicating it's a branch will do). As Noel said, this stuff is easier with Subversion. Given that, as per Steve's message, we can make 1.1 compatibilty changes on HEAD, release and tag, and branch from that point in the future when/if there are bug fixes required? +1. That's easier and avoids the issue altogether. I guess we'd make NET_1_1_1 a branch tag in that case. I've got JDK 1.1.8v1 lying around on my development server if you want me to hunt for and correct any other 1.1 incompatibilities. Otherwise, if Steve's game, he could do it pretty quickly and get on with his work. I won't be back home until tomorrow afternoon and my currently erratic email polling combined with my being subscribed to the mailing list digest means I won't be able to act on anything until tomorrow afternoon. daniel - 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: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
In message [EMAIL PROTECTED], steve cohen writes: Seems to me the HashMap --- Hashtable change could be made against HEAD. It's only NECESSARY for 1.1 compatibility but it poses no great problem for a 1.2 compatible version; it isn't as if this would impact some functionality deep in the core of the product. So after this is done, a NET_1_1_1 tag could be created and that could be the final of this branch. +1; same as Jeffrey suggested. On the other hand, if there are other 1.1 incompatibilities we may want to fix those too, and then this might get a little problematical. Hey, Jeffrey, do you know if there's an easy way to make Maven do a JDK 1.1 compile? Or would it be easier to just tinker with the generated ant script? +1 to fixing all 1.1 incompatibilities before branching. I skipped ahead in the thread and see Jeffrey already answered how to run compile for 1.1 with Maven. On the subject of the pluggable parser factory, I'm not sure I see the need, but it's easy enough to do it that way, so I will make the change. Am I If there really isn't a need, don't do it. I just thought users may need to be able to customize the method used to determine which parser is returned. I thought it would become an issue when you started writing code that created parsers using the static factory method. correct in assuming that in your plan there would be a default implementation, with other factories being selectable instead on the basis of a property? I figured an automatic detector would accept a parser factory as an argument in either a constructor or detection method. The default constructor or default no-argument method would use a default implementation (whatever you were writing for the static method). That users could provide their own factories for systems we haven't anticipated. Probably they'd just subclass the default implementation, override the factory method, provide their own detection code for the systems they care about that we don't handle, and delegate to the superclass method anything else. Alternatively, there may be situations where they want to implement something from scratch, in which case they would just implement the interface. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AIXFTPEntryParser
In looking over the source to AIXFTPEntryParser, I see the following comment, apparently from the author, ([EMAIL PROTECTED]): * This class is based on UnixFTPEntryParser with some small changes, namely * the day and month fields being transposed. I seriously must wonder if this is a distinction between AIX and Unix or whether instead what we are looking at is not a locale-specific variation in how dates are rendered. Might there be unix ftp systems in European locales that show the dates as dd-MM- and AIX systems in the US that use MM-dd-? If that is the case, then the naming of these classes is problematical. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
In message [EMAIL PROTECTED], steve cohen writes: This code was calling a method in ORO that returned a Collection, also not JDK1.1 compatible. Since the older ORO method that returned a Vector had been deprecated, I looked at what it was doing, which was simply splitting a string on a comma. This was an overkill use of ORO, easily replicated with a StringTokenizer. Oh yeah, it's way better to use StringTokenizer when you're splitting on just a constant string rather than an actual regular expression. However, if there's anything that doesn't work in 1.1 because of ORO, I can get off of my ass and finally do the multi-version compilation support we'd talked about on oro-dev. We wanted to use conditional compilation to simultaneously support J2ME, J2SE 1.2, and J2SE 1.4. J2ME support effectively makes it JDK 1.1 compatible, so we could also throw in a JDK 1.1 target. The changes are minor; the equivalent of a few ifdefs. But it keeps J2ME folks from having to make the changes themselves and will take care of any Commons Net users who complain about Net breaking on JDK 1.1 because of ORO. At any rate, if the ORO dependency is the only thing preventing 1.1 compatibility I can take care of that over the next week. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Tag NET_1_1_1 created
In message [EMAIL PROTECTED], steve cohen writes: On Thursday 01 January 2004 04:17 pm, Jeffrey D. Brekke wrote: Should we roll out a release of this version? +1. We clearly have lazy consensus, but we need a formal vote cc'ed to the PMC list for all to be kosher. I guess so. It should be billed as the last JDK-1.1-compatible version. Yep, but should we indicate a willingness to backport bug fixes when requested for say the next 6 months? I am more interested in the next version - the one that will have the parser factory. When that is out, I will be able to take it to the ant folks as part of the fix to solve their inability to connect to non-unix ftp servers. Now that you've tagged the code keep on working on the new stuff while you've got the time. Jeffrey or I can handle the release management for 1.1.1 so you can seize your window of opportunity to code. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ready for promotion? Was: [io] release plans?
In message [EMAIL PROTECTED], Hen ri Yandell writes: What do people think about calling a vote for promotion out of the sandbox now? +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [uid] Name?
Good one, got me! gg -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Friday, January 02, 2004 13:04 To: Jakarta Commons Developers List Subject: RE: [uid] Name? On Fri, 2 Jan 2004, Gary Gregory wrote: I like [id] or [identifier], with a preference for [id] as I see it as a well known abbreviation, and do not see what id could be confused with. http://www.yourdictionary.com/ahd/i/i0017200.html ;-) ;-) -- Martin Cooper The u in uid seems too specific, but, I am not opposed to it either ;-) Gary -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Friday, January 02, 2004 11:49 To: Jakarta Commons Developers List Subject: [uid] Name? I would like to push out the website, but before I do, I wanted to allow people one more chance to weigh in on the name. Gary has suggested [id] and I suppose [identifiers] would also be reasonable. I personally like [uid] fine. Since we are not (yet ;) using Subversion, changing is a mild PITA, but I am happy to do it if others like [id] or [identifiers] better. So...any strong opinions? - 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/net/src/test/org/apache/commons/net/ftp/parser DefaultFTPFileEntryParserFactoryTest.java
scohen 2004/01/02 14:16:41 Modified:net/src/java/org/apache/commons/net/ftp FTPClient.java Added: net/src/java/org/apache/commons/net/ftp/parser DefaultFTPFileEntryParserFactory.java FTPFileEntryParserFactory.java ParserInitializationException.java net/src/test/org/apache/commons/net/ftp/parser DefaultFTPFileEntryParserFactoryTest.java Log: Implementation of a Parser Factory for creating FTPFileEntryParser entries. Revision ChangesPath 1.18 +142 -0 jakarta-commons/net/src/java/org/apache/commons/net/ftp/FTPClient.java Index: FTPClient.java === RCS file: /home/cvs/jakarta-commons/net/src/java/org/apache/commons/net/ftp/FTPClient.java,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- FTPClient.java2 Jan 2004 03:39:04 - 1.17 +++ FTPClient.java2 Jan 2004 22:16:41 - 1.18 @@ -69,6 +69,8 @@ import org.apache.commons.net.io.ToNetASCIIOutputStream; import org.apache.commons.net.io.Util; import org.apache.commons.net.MalformedServerReplyException; +import org.apache.commons.net.ftp.parser.FTPFileEntryParserFactory; +import org.apache.commons.net.ftp.parser.ParserInitializationException; /*** * FTPClient encapsulates all the functionality necessary to store and @@ -2212,6 +2214,146 @@ return getReplyString(); return null; } +/** + * Using the supplied key, and the pluggable parser factory defined by + * the system property codeftp.entry.parser.factory/code obtain a list + * of file information for the current working directory or for just a + * single file. + * p + * Under the DefaultFTPFileEntryParserFactory, which is used unless a + * different factory has been specified in the system properties, the key + * can be either a recognized System type for which a parser has been + * defined, or the fully qualified class name of a class that implements + * org.apache.commons.net.ftp.FTPFileEntryParser. + * p + * This information is obtained through the LIST command. The contents of + * the returned array is determined by thecode FTPFileEntryParser /code + * used. + * p + * Since the server may or may not expand glob expressions, using them + * is not recommended and may well cause this method to fail. + * p + * + * @param parserKey This is a handle which the parser factory used + * must be able to resolve into a class implementing + * FTPFileEntryParser. + * + * In the DefaultFTPFileEntryParserFactory, this + * may either be a specific key identifying a server type, + * which is used to identify a parser type, + * or the fully qualified class name of the parser. See + * DefaultFTPFileEntryParserFactory.createFileEntryParser + * for full details. + * @param pathname The file or directory to list. + * + * @return The list of file information contained in the given path in + * the format determined by the parser represented by the + * code parserKey /code parameter. + * @exception FTPConnectionClosedException + * If the FTP server prematurely closes the connection + * as a result of the client being idle or some other + * reason causing the server to send FTP reply code 421. + * This exception may be caught either as an IOException + * or independently as itself. + * @exception IOException + * If an I/O error occurs while either sending a + * command to the server or receiving a reply + * from the server. + * @exception ParserInitializationException + * Thrown if the parserKey parameter cannot be + * resolved by the selected parser factory. + * In the DefaultFTPEntryParserFactory, this will + * happen when parserKey is neither + * the fully qualified class name of a class + * implementing the interface + * org.apache.commons.net.ftp.FTPFileEntryParser + * nor a string containing one of the recognized keys + * mapping to such a parser or if class loader + * security issues prevent its being loaded. + * @see
Re: [site] Out of date: http://jakarta.apache.org/commons/components .html
I lied. I'm not really talking about a multiproject website as Maven's multiproject is single-inheritence based and my ideas are more multi-mixin based. For example, how can I have Commons-Lang in 3 multiproject websites? Maven's default website is something I'm already using, [http://www.osjava.org/genjava/] but it doesn't really work well for the community site I was driving for. Hen On Sat, 3 Jan 2004 [EMAIL PROTECTED] wrote: Maven does indeed have the facility to generate a multiproject web site. See the multiproject plugin for more detail. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Henri Yandell [EMAIL PROTECTED] wrote on 03/01/2004 04:37:46 AM: I've been playing with something that might be able to replace it, based on project.xml's: http://www.apache.org/~bayard/pergamum/j-c/html-j-c-new/community_jakarta-commons.html Basically a multiproject website that is driven from the top down. Maven probably has something similar, I was playing with ideas, XSL and CSS and Commons project.xml's were the easiest database for me to get my hands on to play with. Just an idea. Hen On Fri, 2 Jan 2004, David Graham wrote: --- Gary Gregory [EMAIL PROTECTED] wrote: Hello, The page http://jakarta.apache.org/commons/components.html is out of date WRT lang, httpclient and maybe others. If every project has a project.xml, maybe the page could be auto-generated when project is rev'ed? I'd like to see that page removed because it's yet another step in the already time consuming release process. It's easy to forget to update it which leads to the current situation. I don't see what value it adds to the site with the components already listed in the left nav. David Gary __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.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] - 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]
[net] checked in parser factory implementation
I have now committed the changes needed to have a factory object for creating FTPFileEntryParser objects to be created. This will enable a better interface with Ant and also enable an autodetect scheme to be written. This code was checked in to the HEAD branch, that is post the NET_1_1_1 branch I created yesterday. I don't know what else is expected for a 1.2 release. I have the following issues which I alluded to in messages earlier today: 1) I think org.apache.commons.net.ftp.ftp2.* should be deprecated. 2) It would be nice to have the issues associated with AIXFTPFileEntryParser which I mentioned in an earlier message resolved. I am moderately in a hurry to get this released so that I can begin work on getting this release into Ant to solve our problems there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving up to JVM 1.4+
David Graham [EMAIL PROTECTED] wrote on 31/12/2003 07:41:31 AM: --- Noel J. Bergman [EMAIL PROTECTED] wrote: This has come up in regards to using some of java.nio in Commons/Net also. I say we leave the last release as 1.1 compatible and move on to using 1.4+ for new versions. Personally, I use JVM 1.4+, myself. However, everytime we do a survey on server-user, we get emphatic feedback from our users to preserve support for JVM 1.3.1. Before dropping support for pre-1.4 systems, perhaps it would be a good idea to raise the question on the user list? There will always be users that will complain when changing Java versions. The only semi-valid reason I've heard to not upgrade to 1.4 is that product X requires 1.3 and product X is expensive. The real reason not to upgrade to 1.4 etc is that you cut down your user base. e.g. developers using WebSphere 4.x can't use your software. IMO, if the component needs 1.4 then you should move to 1.4. The previous 1.3 compatible version of the component will still work after the change. Product X shouldn't stand in the way of innovation :-). -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Branching
In message [EMAIL PROTECTED], Martin Cooper writes: On Fri, 2 Jan 2004, Daniel F. Savarese wrote: All I was getting at was what to name the tag. My understanding was that a tag needs to be created as a branch. I should have used ... to point out that there are two distinct types of tags in CVS. Branches affect future commits, and are harder to change your mind about after the In the context of the discussion, I should have said either that the tag (meaning the tag we were talking about) or that a branch tag (meaning any branch tag) needs to be created as a branch (meaning using -b). Without my saying that, it does sound like I'm saying the wrong thing. Anyway, there's no harm (and probably some help, given my lack of clarity) in your clarifying it and I may still be wrong about the roundabout way of changing a label to a branch being the only way to use an existing CVS non-branch tag as a branch tag. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] CaseInsensitiveHashMap
From: Phil Steitz [EMAIL PROTECTED] 2. I made no attempt at allowing the locale to be set or otherwise changing the default behavior of toLower() in convert(). I'm wondering how your implementation works. I was expecting the isEqualKey() method to be overridden, rather than converting the key on add. (Note that the same code also has to go in a MapEntry) Could be I was being too lazy. Since toLower() is idempotent (calling it repeatedly has same effect as calling it just once) it works to just override convert(), since in AbstractHashedMap, get, put, remove, containsKey, all start by converting the key (nice!). All I did was to extend HashedMap and override convert to return key.toString().toLowerCase(). The effect is that you actually store all lower case strings as keys (or null, once I fix this). The behavior should be the same as the impl that David Graham posted with PR #24537 (unless I am missing something -- quite possible). This impl will work, but I would prefer to see the case of the key maintained, just the comparison to be case insensitive. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Out of date: http://jakarta.apache.org/commons/components .html
I can see that the release information could easily get out of date, so I'd be OK with removing that from the page. However, I'd still like to keep the grouping of released, pre-released, etc. because that is also useful information for newcomers (and quick-stop visitors). Sounds good to me. This way we won't have to update this page each time we cut a release. +1, keep page, no release links - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Let's get rid of org.apache.commons.net.ftp.ftp2
In message [EMAIL PROTECTED], steve cohen writes: Is there a recommended way to go about this? It was doubtful to me that anyone had ever used these packages, but I now see that I was wrong. Someone went and implemented an AIXFTPEntryParser in the ftp2.parser package (and not on the main stem). So I would be in favor of moving this class onto the main stem and deprecating everything in ftp2. Definitely +1 on this, but it's already been done. You must have an old checkout that you're doing cvs updates on. It's a good thing too since you wouldn't have caught the AIXFTPEntryParser sitting there. We ought to look at the log entries and see if it was subsumed by the functionality in one of the other parsers. In any case, everything in ftp2/ and ftp/parser/ is in the Attic/ in the CVS repository, so when you do a fresh checkout, the directories will be empty. My .cvsrc adds -P to checkout and update (doesn't checkout empty directories), so I didn't know what you were talking about at first. Okay, scratch what I just said. I see, you're talking about what's in the proposal directory. Yeah, definitely get rid of proposal/ftp2. The way to do it is to delete the files and do cvs removes. After looking at the log entry for AIXFTPEntryParser, I see I added it: revision 1.1 date: 2003/01/28 18:53:04; author: dfs; state: Exp; Added AIX listing parser from Brett Smith brett at bml.uk.com. That was in the 1.0 release, before the proposal was moved into the ftp package. The files in src/java/org/apache/commons/net/ftp/parser were added later and first appear in the 1.1 release candidate. So AIXFTPEntryParser didn't get copied from the proposal directory for some reason. I'm not in the best position to do the detective work on this right now, but can look at it tomorrow night if you don't have time to figure out if AIXFTPEntryParser functionality is already provided by another entry parser or if we just missed it when migrating the entry parsers. I suppose the proposal directory is another possibility I hadn't considered for doing work on a java.nio version of the code. In these [net] threads, I think we've pretty much made the case for switching to Subversion sooner rather than later. Subversion is close to a 1.0 release and I believe they've stopped modifying the database schema, so the question will become whether all of Jakarta Commons should move to Subversion at once or piecemeal and when. But that's a subject for a different thread. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [uid] Name?
As per Gary, [id] or [identifier], with a preference for [id] Stephen I like [id] or [identifier], with a preference for [id] as I see it as a well known abbreviation, and do not see what id could be confused with. The u in uid seems too specific, but, I am not opposed to it either ;-) Gary -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Friday, January 02, 2004 11:49 To: Jakarta Commons Developers List Subject: [uid] Name? I would like to push out the website, but before I do, I wanted to allow people one more chance to weigh in on the name. Gary has suggested [id] and I suppose [identifiers] would also be reasonable. I personally like [uid] fine. Since we are not (yet ;) using Subversion, changing is a mild PITA, but I am happy to do it if others like [id] or [identifiers] better. So...any strong opinions? - 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: AIXFTPEntryParser
In message [EMAIL PROTECTED], steve cohen writes: In looking over the source to AIXFTPEntryParser, I see the following comment, apparently from the author, ([EMAIL PROTECTED]): It sounds like you're already doing the detective work, so I'll leave it to you. I seriously must wonder if this is a distinction between AIX and Unix or whether instead what we are looking at is not a locale-specific variation in how dates are rendered. Might there be unix ftp systems in European locales that show the dates as dd-MM- and AIX systems in the US that use MM-dd-? If that is the case, then the naming of these classes is problematical. It sounds like these variations can all be handled by one class. The locale stuff should be configurable and in the short term, the special case of dd-MM- vis a vis MM-dd- can be handled by a modified regular expression and an if statement or two. If that's the only difference between AIXFTPEntryParser and UnixFTPEntryParser, then it's my fault for having added the code submission instead of incorporating the functionality into UnixFTPEntryParser. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [uid] Name?
Martin Cooper wrote: On Fri, 2 Jan 2004, Gary Gregory wrote: I like [id] or [identifier], with a preference for [id] as I see it as a well known abbreviation, and do not see what id could be confused with. http://www.yourdictionary.com/ahd/i/i0017200.html ;-) ;-) -- Martin Cooper LOL I guess that would make commons-ego a natural companion product :-) Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [uid] Name?
Noel J. Bergman wrote: Are the identifiers ever not unique? Sometimes not guaranteed. The serial identifiers can be set up to wrap, for example. Phil --- Noel - 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: [site] Out of date: http://jakarta.apache.org/commons/compon ents .html
+1, keep page, no release links but links to the project page. -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Friday, January 02, 2004 15:07 To: Jakarta Commons Developers List Subject: Re: [site] Out of date: http://jakarta.apache.org/commons/components .html I can see that the release information could easily get out of date, so I'd be OK with removing that from the page. However, I'd still like to keep the grouping of released, pre-released, etc. because that is also useful information for newcomers (and quick-stop visitors). Sounds good to me. This way we won't have to update this page each time we cut a release. +1, keep page, no release links - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Version 3.0 - The final stretch
A snapshot has been tagged and created - http://www.apache.org/~scolebourne I have requested a Maven upload (I hope, JIRA seemed rather unresponsive). There are lots of upload requests waiting though. I am planning on deleting the deprecated for 3.0 code on Sunday, unless someone objects. Stephen From: Stephen Colebourne [EMAIL PROTECTED] I am planning on releasing a snapshot tomorrow to maven. Once that is up, the primitives and observable code will be deleted. Then a beta release of some kind seems appropriate. Anyone who wants to start reviewing [collections] can start now! Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Out of date: http://jakarta.apache.org/commons/components .html
Stephen Colebourne wrote: I can see that the release information could easily get out of date, so I'd be OK with removing that from the page. However, I'd still like to keep the grouping of released, pre-released, etc. because that is also useful information for newcomers (and quick-stop visitors). Sounds good to me. This way we won't have to update this page each time we cut a release. +1, keep page, no release links - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Agreed. If there are no objections, I will fix this (and the [configuration] move) this weekend. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AIXFTPEntryParser
I haven't done the detective work of actually comparing the files yet. I just read the comment and it didn't sit right with me. On Friday 02 January 2004 05:09 pm, Daniel F. Savarese wrote: In message [EMAIL PROTECTED], steve cohen writes: In looking over the source to AIXFTPEntryParser, I see the following comment, apparently from the author, ([EMAIL PROTECTED]): It sounds like you're already doing the detective work, so I'll leave it to you. I seriously must wonder if this is a distinction between AIX and Unix or whether instead what we are looking at is not a locale-specific variation in how dates are rendered. Might there be unix ftp systems in European locales that show the dates as dd-MM- and AIX systems in the US that use MM-dd-? If that is the case, then the naming of these classes is problematical. It sounds like these variations can all be handled by one class. The locale stuff should be configurable and in the short term, the special case of dd-MM- vis a vis MM-dd- can be handled by a modified regular expression and an if statement or two. If that's the only difference between AIXFTPEntryParser and UnixFTPEntryParser, then it's my fault for having added the code submission instead of incorporating the functionality into UnixFTPEntryParser. daniel - 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: [net] Let's get rid of org.apache.commons.net.ftp.ftp2
Doh! You're right - almost. I did a fresh checkout, but the place where I saw the ftp2 stuff was the old place (which I'd renamed to get out of the way). On the fresh checkout I did, there was an ftp2 directory but it was empty. Is that another reason to get away from CVS - that it's too hard to get rid of directories? On Friday 02 January 2004 05:03 pm, Daniel F. Savarese wrote: Definitely +1 on this, but it's already been done. You must have an old checkout that you're doing cvs updates on. It's a good thing too since you wouldn't have caught the AIXFTPEntryParser sitting there. We ought to look at the log entries and see if it was subsumed by the functionality in one of the other parsers. - 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: [uid] Name?
Phil Steitz wrote: Noel J. Bergman wrote: Are the identifiers ever not unique? Sometimes not guaranteed. The serial identifiers can be set up to wrap, for example. My view is that if you consider UID to be a misnomer, rename it. Otherwise keep it. The term uid has an immediate meaning to most programmers that see it. They could make the mistake of thinking it means UserID, but that would be quickly corrected looking at it. I don't know if identifier will have the same immediate meaning. If/when we deploy an ontology-based portal, it could be interesting. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Out of date: http://jakarta.apache.org/commons/components .html
On Fri, 2 Jan 2004, Phil Steitz wrote: Stephen Colebourne wrote: +1, keep page, no release links Agreed. If there are no objections, I will fix this (and the [configuration] move) this weekend. Phil None from me. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] CaseInsensitiveHashMap
Stephen Colebourne wrote: From: Phil Steitz [EMAIL PROTECTED] 2. I made no attempt at allowing the locale to be set or otherwise changing the default behavior of toLower() in convert(). I'm wondering how your implementation works. I was expecting the isEqualKey() method to be overridden, rather than converting the key on add. (Note that the same code also has to go in a MapEntry) Could be I was being too lazy. Since toLower() is idempotent (calling it repeatedly has same effect as calling it just once) it works to just override convert(), since in AbstractHashedMap, get, put, remove, containsKey, all start by converting the key (nice!). All I did was to extend HashedMap and override convert to return key.toString().toLowerCase(). The effect is that you actually store all lower case strings as keys (or null, once I fix this). The behavior should be the same as the impl that David Graham posted with PR #24537 (unless I am missing something -- quite possible). This impl will work, but I would prefer to see the case of the key maintained, just the comparison to be case insensitive. Why exactly? Would you expect equals to distinguish CaseInsensitiveHashMaps that differ only on key case? Phil Stephen - 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] Version 3.0 - The final stretch
I'm deploying them now -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Stephen Colebourne [EMAIL PROTECTED] wrote on 03/01/2004 11:20:26 AM: A snapshot has been tagged and created - http://www.apache.org/~scolebourne I have requested a Maven upload (I hope, JIRA seemed rather unresponsive). There are lots of upload requests waiting though. I am planning on deleting the deprecated for 3.0 code on Sunday, unless someone objects. Stephen From: Stephen Colebourne [EMAIL PROTECTED] I am planning on releasing a snapshot tomorrow to maven. Once that is up, the primitives and observable code will be deleted. Then a beta release of some kind seems appropriate. Anyone who wants to start reviewing [collections] can start now! Stephen - 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/collections/src/java/org/apache/commons/collections/map AbstractHashedMap.java
psteitz 2004/01/02 21:15:00
Modified:collections/src/java/org/apache/commons/collections/map
AbstractHashedMap.java
Log:
javadoc.
Revision ChangesPath
1.6 +5 -5
jakarta-commons/collections/src/java/org/apache/commons/collections/map/AbstractHashedMap.java
Index: AbstractHashedMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/map/AbstractHashedMap.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- AbstractHashedMap.java2 Jan 2004 01:36:52 - 1.5
+++ AbstractHashedMap.java3 Jan 2004 05:15:00 - 1.6
@@ -170,7 +170,7 @@
* @param initialCapacity the initial capacity
* @param loadFactor the load factor
* @throws IllegalArgumentException if the initial capacity is less than one
- * @throws IllegalArgumentException if the load factor is less than zero
+ * @throws IllegalArgumentException if the load factor is less than or equal to
zero
*/
protected AbstractHashedMap(int initialCapacity, float loadFactor) {
super();
@@ -383,8 +383,8 @@
* The reverse conversion can be changed, if required, by overriding the
* getKey() method in the hash entry.
*
- * @param key the key to get a hash code for
- * @return the hash code
+ * @param key the key convert
+ * @return the converted key
*/
protected Object convertKey(Object key) {
return (key == null ? NULL : key);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/daemon/src/native/unix/native jsvc-unix.c
- Original Message -
From: jean-frederic clere [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, January 02, 2004 1:04 AM
Subject: Re: cvs commit: jakarta-commons/daemon/src/native/unix/native
jsvc-unix.c
Thanks. Happy new year.
Do you want to release daemon soon?
We probably should. There are still 4 bugs outstanding for Daemon:
23365) Probably a 'wontfix', or possibly a 'later'. I don't have strong
opinions on this one.
24936) I'll probably patch this one over the weekend (it's the last
procrun bug)
23723) I don't have access to Mac OS/X, so I can't really comment.
23368) You seem to be working on this one, so I haven't really looked at
it, but it's an Enh.
The only other question is whether or not Yoav wants to continue as the RM
(he's done a great job so far, so he has my +1 if he wants the job :).
Cheers
Jean-Frederic
[EMAIL PROTECTED] wrote:
billbarker2003/12/30 21:03:26
Modified:daemon/src/native/unix/native jsvc-unix.c
Log:
Fix problems with signal handling on Solaris (possibly others).
Fix for Bug #24247
Reported By: Peter Poloha [EMAIL PROTECTED]
Revision ChangesPath
1.8 +4 -4
jakarta-commons/daemon/src/native/unix/native/jsvc-unix.c
Index: jsvc-unix.c
===
RCS file:
/home/cvs/jakarta-commons/daemon/src/native/unix/native/jsvc-unix.c,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- jsvc-unix.c 27 Sep 2003 16:49:13 - 1.7
+++ jsvc-unix.c 31 Dec 2003 05:03:25 - 1.8
@@ -271,10 +271,10 @@
/*
* Return the address of the current signal handler and set the new
one.
*/
-static void * signal_set(int sig, void * handler) {
+static void * signal_set(int sig, void * newHandler) {
void *hand;
-hand=signal(sig,handler);
+hand=signal(sig,newHandler);
#ifdef SIG_ERR
if (hand==SIG_ERR)
hand=NULL;
@@ -350,7 +350,7 @@
/* Install signal handlers */
handler_hup=signal_set(SIGHUP,handler);
handler_trm=signal_set(SIGTERM,handler);
-handler_trm=signal_set(SIGINT,handler);
+handler_int=signal_set(SIGINT,handler);
controlled = getpid();
log_debug(Waiting for a signal to be delivered);
while (!stopping) sleep(60); /* pause() not threadsafe */
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Chris Meyer/MutualOMA is out of the office.
I will be out of the office starting 01/01/2004 and will not return until 01/05/2004. I will respond to your message when I return. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cookie question - Sorry : Retrying
Hi Jacques,
HttpClient automatically processes cookie in the response and adds any
new cookies to the associated HttpState. Take a look at
HttpClient.getState() and HttpState.getCookies(). There is also some
more info on cookie parsing at
http://jakarta.apache.org/commons/httpclient/cookies.html. You can
also get the raw cookie headers from a response by calling
HttpMethod.getResponseHeader(Set-Cookie) on the executed method.
Mike
On Dec 22, 2003, at 10:27 AM, aruba bulk wrote:
Hi there (pls ignore my previous post)
I'm using HttpClient to write a Cactus unit test. I'd
like to simulate a browser, sending a cookie to the
server with a request. So the cookie originates at the
client side :
HttpClient client = new HttpClient();
HttpMethod method = new getMethod(url);
String cookieValue = testValue;
String cookieName = testname;
Cookie cookie = new Cookie(localhost, cookieName,
cookieValue);
cookie.setPath(/);
HttpState httpState=new HttpState();
httpState.addCookie(cookie);
client.setState(httpState);
// Execute the method.
int statusCode = -1;
try {
statusCode = client.executeMethod(method);
} catch (HttpRecoverableException e) {}
catch (IOException e) {}
// Read the response body.
byte[] responseBody = method.getResponseBody();
My question is this : I need to check whether the
server has set any additional cookies in the response.
How do i do this ?
Any help greatly appreciated.
Regards
Jacques
=
All one's life is music, if one touches the notes rightly, and in
time.
- John Ruskin
-
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: [HttpClient] Refactor get/setRequestHeader(Content-Type,..)
Hi Gary, I agree, constants like Content-Type along with quite a few others are duplicated throughout the HttpClient code. Mostly this is because no-one has spent the time to clean them up. As Eric mentioned convenience methods have not been added to HttpMethod for compatibility reasons. Also, since there are so many commonly used headers we have not wanted to muddy up the HttpMethod interface with more methods. My preference would be to add header utility methods to another static class, HeaderUtil or something of the like. This class could have a bunch of constants for the various commonly used header names, as well as methods for more complicated header elements like Content-Type (e.g. HeaderUtil.createContentTypeHeader(text/html, UTF-8)). As always patches are quite welcome. Mike On Dec 23, 2003, at 3:43 PM, Gary Gregory wrote: Hello HttpClient, For our code which uses HttpClient, I find myself defining constants and methods in our code for things like Content-Type header handling. I am surprised not to find such a constant in HttpClient in a public place. (It is defined in multipart.Part as protected). I also see a lot of getRequestHeader(Content-Type) and setRequestHeader(Content-Type, ...). This is seem like a good opportunity for a refactoring, in this case to getContentType() and setContentType(String). Is there any reasons these methods do not exist? I am a committer on [lang] and [codec] (also dabbling in [vsf]) and can help out directly or via patches if the group is interested in moving in this direction. Thanks for reading, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: authentication ...
Hi Isabelle,
Happy New Year!
This is a known problem with HttpClient. Bug #15297
http://issues.apache.org/bugzilla/show_bug.cgi?id=15297. The plan is
to add a configuration option for specifying the order in which auth
challenges are processed. You should be able to work around this by
using preemptive authentication, see
HttpState.setAuthenticationPreemptive().
Mike
On Dec 31, 2003, at 10:42 AM, Blanc, Isabelle wrote:
Hi everybody :)
and first of all, I wish you all an happy new year :))
and now is my question/remark (i don't know if it's better to post it
here, or in the user mailing list, or as a comment in bugzilla, but I
don't want to cross post, so for now I post it only here - let me know
if I should cross post or add a comment in bugzilla) :
- the proxy I had to go though was using NTLM, and I checkouted the
HTTPCLIENT_2_0_BRANCH tag sources from cvs.
- then the sysadmin decided to open a door for me in the proxy that
would use only basic authentication. So i though that replacing the
NTCredentials with UsernamePasswordCredentials would be enough - and
it wasn't. The code was still returning a 407 - which is weird with
basic auth.
- I finally found out where the error was (and now it works fine -
only for me tho), but I can't decide if it's because of the proxy
(that returns a wrong answer) or because of commons/httpclient code
:
* the proxy returns these challenges, in this order : ntlm - basic -
kerberos - negotiate
* in HttpAuthenticator.selectAuthScheme, after having built the
challengemap, you go like :
...
challenge = (String) challengemap.get(ntlm);
if (challenge != null) {
return new NTLMScheme(challenge);
}
challenge = (String) challengemap.get(digest);
if (challenge != null) {
return new DigestScheme(challenge);
}
challenge = (String) challengemap.get(basic);
if (challenge != null) {
return new BasicScheme(challenge);
}
...
I only commented out the 4 lines about NTLM (i know it's quick dirty
but .. i had to make it work before 2004 ;] !)
Anyway, does it mean that the proxy should NOT return any ntlm
challenge if it expects a basic auth, even if it's for one single
realm (all other realms (domains for ntlm) use NTLM auth) ?
Or does it mean there's something here in the code that needs to be
twisted (like, the only challenge that actually has a value is the
basic one : if i print the challenge map i get
ntlm--NTLM
basic--Basic realm=hidden-sorry
kerberos--Kerberos
negotiate--Negotiate
) ??
that was my 2 cents
hope you'll all have a nice nice new year's eve tonight :o) !
Isa
-
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: cookie question - Sorry : Retrying
Hi Jacques
Here is code snippet, That might help you
public static void initializeClient(HttpServletRequest request) {
if (httpClient == null)
httpClient = new HttpClient();
httpClient.setConnectionTimeout(3000);
HttpState state = httpClient.getState();
state.setCookiePolicy(CookiePolicy.COMPATIBILITY);
Cookie[] cookies = request.getCookies();//This method call gives all the cookies in
response to the browser request..
}
Thanks
Venkat Burri
-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Fri 1/2/2004 8:56 AM
To: Commons HttpClient Project
Cc:
Subject: Re: cookie question - Sorry : Retrying
Hi Jacques,
HttpClient automatically processes cookie in the response and adds any
new cookies to the associated HttpState. Take a look at
HttpClient.getState() and HttpState.getCookies(). There is also some
more info on cookie parsing at
http://jakarta.apache.org/commons/httpclient/cookies.html. You can
also get the raw cookie headers from a response by calling
HttpMethod.getResponseHeader(Set-Cookie) on the executed method.
Mike
On Dec 22, 2003, at 10:27 AM, aruba bulk wrote:
Hi there (pls ignore my previous post)
I'm using HttpClient to write a Cactus unit test. I'd
like to simulate a browser, sending a cookie to the
server with a request. So the cookie originates at the
client side :
HttpClient client = new HttpClient();
HttpMethod method = new getMethod(url);
String cookieValue = testValue;
String cookieName = testname;
Cookie cookie = new Cookie(localhost, cookieName,
cookieValue);
cookie.setPath(/);
HttpState httpState=new HttpState();
httpState.addCookie(cookie);
client.setState(httpState);
// Execute the method.
int statusCode = -1;
try {
statusCode = client.executeMethod(method);
} catch (HttpRecoverableException e) {}
catch (IOException e) {}
// Read the response body.
byte[] responseBody = method.getResponseBody();
My question is this : I need to check whether the
server has set any additional cookies in the response.
How do i do this ?
Any help greatly appreciated.
Regards
Jacques
=
All one's life is music, if one touches the notes rightly, and in
time.
- John Ruskin
-
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: authentication ...
on the same note of authentication.. I know this question sounds dumb (when I read back the contents) but is there a way to send the authentication digest/credentials with the first request so that the request does not get challenged? __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SSL implementation not available only in HttpClient
Hi -- I'm brand new to the list, but not to mailing lists in general, and I've done about three business days worth of research before resorting to this e-mail. I can get out to an external https site (on unusual port 444) using the standard Sun client implementation, i.e.: URL url = new URL(https://www.fake-site.com:444/;); HttpsConnection conn = url.openConnection(); ...but when I use HttpClient like this (where httpContent = an XML data block): HttpClient client = new HttpClient(); post = new PostMethod(https://www.fake-site.com:444/;); post.setRequestBody(httpContent); client.executeMethod(post); ...I get the following exception: java.net.SocketException: SSL implementation not available Now, in my research I know that this exception can be thrown for a variety of reasons, such as a missing/defunct trust.store, missing Provider specification, missing handler, missing JARs, but these are not occurring here. I have proved that I have set up the proper Sun JSSE environment, because, as I mentioned above, the standard url.openConnection() works flawlessly. Due to several bugs in the Sun client implementation that are fixed in HttpClient (such as better Proxy authentication support, etc.) and my environment's dependency on JDK 1.3, I'd really like to get HttpClient to work. Additionally, when I run the HttpClient code above with javax.net.debug=all set, I see that the SSL implementation _IS GETTING INITIALIZED_ before the SSL implementation not available is reported. This makes no sense to me -- if the implementation gets initialized, how can it not be available? Lastly, anyone with WebSphere experience, this problem only occurs in the WAS 4.04 runtime environment, but works without issue in the WSAD development environment. Anyone have any ideas? I'm desperate and appreciate any help. -- Justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DateParser pluggability
I have had to supply an extra format String as follows:
/** The patterns used for parsing dates */
private static final String[] DATE_PATTERNS = {
PATTERN_RFC1123,
PATTERN_RFC1036,
PATTERN_ASCTIME,
EEE, dd-MMM- HH:mm:ss z,
EEE, dd-MMM- HH-mm-ss z,
EEE, dd MMM yy HH:mm:ss z,
EEE dd-MMM- HH:mm:ss z,
EEE dd MMM HH:mm:ss z,
EEE dd-MMM- HH-mm-ss z,
EEE dd-MMM-yy HH:mm:ss z,
EEE dd MMM yy HH:mm:ss z,
EEE,dd-MMM-yy HH:mm:ss z,
EEE,dd-MMM- HH:mm:ss z,
EEE, dd-MM- HH:mm:ss z,
// Extra for non-compliant site
dd-MMM- HH:mm:ss zzz
};
to the DateParser class and produce my own build, as the DateParser does not
seem to provide pluggability for non-compliant sites. Can anyone tell me when
this situation may change so I no longer have to produce a one-man code fork?
C Johnson
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DateParser pluggability
Hello,
Date parser formats can be configured in the post 2.0 HttpClient code.
This code, in CVS HEAD, is still pre-alpha but everything should still
be working. You can add a format using something like the following:
HttpParams params = DefaultHttpParams.getDefaultParams();
HashSet patterns = new HashSet((Collection)
params.getParameter(DateParser.KEY_DATE_PATTERNS));
patterns.add(SOME_PATTERN);
params.setParameter(DateParser.KEY_DATE_PATTERNS, patterns);
Mike
On Dec 31, 2003, at 10:57 AM, protean wrote:
I have had to supply an extra format String as follows:
/** The patterns used for parsing dates */
private static final String[] DATE_PATTERNS = {
PATTERN_RFC1123,
PATTERN_RFC1036,
PATTERN_ASCTIME,
EEE, dd-MMM- HH:mm:ss z,
EEE, dd-MMM- HH-mm-ss z,
EEE, dd MMM yy HH:mm:ss z,
EEE dd-MMM- HH:mm:ss z,
EEE dd MMM HH:mm:ss z,
EEE dd-MMM- HH-mm-ss z,
EEE dd-MMM-yy HH:mm:ss z,
EEE dd MMM yy HH:mm:ss z,
EEE,dd-MMM-yy HH:mm:ss z,
EEE,dd-MMM- HH:mm:ss z,
EEE, dd-MM- HH:mm:ss z,
// Extra for non-compliant site
dd-MMM- HH:mm:ss zzz
};
to the DateParser class and produce my own build, as the DateParser
does not
seem to provide pluggability for non-compliant sites. Can anyone tell
me when
this situation may change so I no longer have to produce a one-man
code fork?
C Johnson
-
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: preemptive authentication ...
Hi Sid, HttpClient only supports using Basic authentication preemptively. This is because both NTLM, and Digest require values sent by the server as part of the Authorization request to create the authorization response. Mike On Jan 2, 2004, at 4:15 PM, Sid Subr wrote: on the same note of preemptive authentication.. I know this question sounds dumb (when I read back the contents) but is there a way to send the authentication digest/credentials with the first request so that the request does not get challenged? after reading preemptive authentication for httpclient in the authentication doc.. it seems this preemptiveness is only possible with basic authentication.. is this true? Sid __ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 - 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: SSL implementation not available only in HttpClient
Hi Justin, The problem is related to the fact that IBM includes their own version of JSSE in WAS. I believe others have had this problem, but I am not sure what their solution was. I found the following at http://www.websphere-world.com/modules.php?name=Newsnew_topic=38: Anonymous writes Hi folks, The big thing you have to remember is that IBM has their own version of JSSE. Make sure you have the C:/Program Files/IBM/Application Developer/plugins/com.ibm.etools.server.jdk/jre/lib/ext/ibm/jsse.jar in your classpath if you're using WSAD and in your code: Instead of using: System.setProperty(java.protocol.handler.pkgs,com.sun.net.ssl.intern al.www.protocol); java.security.Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider()); Use this: System.setProperty( java.protocol.handler.pkgs,com.ibm.net.ssl.internal.www.protocol); java.security.Security.addProvider(new com.ibm.jsse.JSSEProvider()); Everything else is exactly the same. Note: fyi. IBM does not officially support the use of IBM's JSSE provider in your application code (WAS3.5 and 4.0). It is bundled to support its own internal functions. Nevertheless, it works fine. There is also some discussion of this at sun http://forum.java.sun.com/thread.jsp? thread=288147forum=2message=1279111. I also suggest taking a look at google groups using the following query jsse group:ibm.software.websphere.application-server.*. It seems many people have trouble getting JSSE working correctly in WAS 4.0, but there are also few answers. Mike On Jan 2, 2004, at 2:58 PM, J Yunke wrote: Hi -- I'm brand new to the list, but not to mailing lists in general, and I've done about three business days worth of research before resorting to this e-mail. I can get out to an external https site (on unusual port 444) using the standard Sun client implementation, i.e.: URL url = new URL(https://www.fake-site.com:444/;); HttpsConnection conn = url.openConnection(); ...but when I use HttpClient like this (where httpContent = an XML data block): HttpClient client = new HttpClient(); post = new PostMethod(https://www.fake-site.com:444/;); post.setRequestBody(httpContent); client.executeMethod(post); ...I get the following exception: java.net.SocketException: SSL implementation not available Now, in my research I know that this exception can be thrown for a variety of reasons, such as a missing/defunct trust.store, missing Provider specification, missing handler, missing JARs, but these are not occurring here. I have proved that I have set up the proper Sun JSSE environment, because, as I mentioned above, the standard url.openConnection() works flawlessly. Due to several bugs in the Sun client implementation that are fixed in HttpClient (such as better Proxy authentication support, etc.) and my environment's dependency on JDK 1.3, I'd really like to get HttpClient to work. Additionally, when I run the HttpClient code above with javax.net.debug=all set, I see that the SSL implementation _IS GETTING INITIALIZED_ before the SSL implementation not available is reported. This makes no sense to me -- if the implementation gets initialized, how can it not be available? Lastly, anyone with WebSphere experience, this problem only occurs in the WAS 4.04 runtime environment, but works without issue in the WSAD development environment. Anyone have any ideas? I'm desperate and appreciate any help. -- Justin - 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]
