[Jakarta Commons Wiki] Updated: TitleIndex
Date: 2004-07-14T23:03:22 Editor: DirkVerbeeck [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: TitleIndex URL: http://wiki.apache.org/jakarta-commons/TitleIndex 1084953518 Change Log: -- @@ -8,146 +8,3 @@ [[TitleIndex]] - - -Can anybody translate this?: - -- -http://www.gotooa.com OA #21150;#20844;#33258;#21160;#21270; #32593;#19978;#21150;#20844; -http://www.sinoart.com.cn -http://www.googlepromotion.com -http://www.gogoogle.net -http://www.dongdao.net #35774;#35745;#24179;#38754;#35774;#35745;#24191;#21578;#35774;#35745; -http://www.dongdao.net/main04.htm CI#35774;#35745; VI#35774;#35745; #26631;#24535;#35774;#35745; -http://www.dongdao.net/main04-02.htm #21253;#35013;#35774;#35745; -http://www.bjzufang.com #31199;#25151;#20813;#36153;#31199;#25151; -http://www.bjkhp.com #21830;#26631;#19987;#21033;#19987;#21033;#20195;#29702; -http://www.bjkhp.com/operation.asp #21830;#26631;#20195;#29702; -http://www.passion.org.cn gmat -http://www.passion.org.cn gmat#32771;#35797; -http://www.passion.org.cn gmat#22521;#35757; -http://www.sxcoal.com/en/index.asp coal -http://www.bj-sd.com #26426;#31080; -http://www.bbell.com #23567;#28789;#36890; -http://www.gaokao.net.cn #39640;#32771; -http://www.disinfect.cn/cpjs01.htm #20108;#27687;#21270;#27695; -http://www.monarch.com.cn #28070;#28369;#27833; -http://www.bjhsdx.com #26465;#30721;#25171;#21360;#26426; -http://www.pm.tsinghua.edu.cn #39033;#30446;#31649;#29702; -http://211.157.35.153/index.asp #39033;#30446;#31649;#29702; -http://www.168flower.com #40092;#33457; -http://www.168flower.com #40092;#33457;#24215; -http://www.168flower.com #40092;#33457;#36895;#36882; -http://www.8848flower.com china flower -http://www.8848flower.com china flowers -http://www.jinyibei.com.cn #21333;#29255;#26426; -http://www.glory-vision.com/d_lib/htdocs/index.asp #25237;#24433;#26426; -http://www.glory-vision.com #25237;#24433;#26426; -http://www.glory-vision.com/d_lib/htdocs/touyingji.htm #25237;#24433;#26426; -http://www.cstarcom.com gps -http://www.cstarcom.com #21355;#26143;#23450;#20301; -http://www.sinoart.com.cn/oa.htm OA -http://myoa.freewebpage.org OA -http://www.kangxin.com #19987;#21033;#30693;#35782;#20135;#26435;#21830;#26631; -http://www.tmrr.com #21830;#26631;#21830;#26631;#27880;#20876; -http://www.glory-vision.com #25237;#24433;#26426;#31561;#31163;#23376;#26174;#31034;#22120; -http://www.jinyibei.com.cn #21333;#29255;#26426; -http://www.jinyibei.com.cn/chanpin/bcq/vlp-58A.htm #32534;#31243;#22120; -http://www.jinyibei.com.cn/chaxun/arm.htm ARM -http://www.cambridge-group.org acca#32771;#35797; acca#22521;#35757; -http://www.bjacca.com acca#32771;#35797;acca#22521;#35757; -http://www.fashuo300.com #32771;#30740;#27861;#24459;#30805;#22763;#27861;#30805; -http://www.approachina.com #31649;#29702;#21672;#35810; #31649;#29702;#21672;#35810;#20844;#21496; -http://www.creavic.com.cn/ois/usersites/chengwei/index.jsp #31649;#29702;#21672;#35810;#31649;#29702;#39038;#38382; -http://www.jzhrb.com.cn #32654;#23481;#20943;#32933; -http://www.51zhengxing.net #32654;#23481;#25972;#24418;#25972;#23481; -http://www.51zhengxing.net/2-zxjf.htm #20943;#32933;#30246;#36523; -http://www.51zhengxing.net/2-zxxm.htm #38534;#33016;#20016;#33016; -http://www.melucky.com #38376;#31105; #20572;#36710;#22330;#19968;#21345;#36890; -http://www.ychzn.com/DKmjjianjie.htm #38376;#31105; -http://www.ychzn.com/suo_elem.htm #30005;#23376;#38145; -http://www.peak-e.com/cpyxt/mj.asp #38376;#31105; -http://www.peak-e.com/cpyxt/yktxt.asp #19968;#21345;#36890; -http://www.peak-e.com/cpyxt/tcc.asp #20572;#36710;#22330; -http://www.tonzh.com smt#22238;#27969;#28938; -http://www.creativetoys.com.cn #29609;#20855; -http://www.creativewatch.cn #25163;#34920; -http://www.cnsec.cn/product/firewall/NS-5GT.htm netscreen -http://www.cnsec.cn/product/1firewall.htm #38450;#28779;#22681; -http://www.cnsec.cn/product/1fortinet.htm #38450;#27602;#22681; -http://www.drs.infosec.org.cn #25968;#25454;#24674;#22797;#25968;#25454;#20462;#22797; -http://www.drs.infosec.org.cn/area.html -http://www.chindata.com #25968;#25454;#24674;#22797; -http://www.protech.net.cn #36127;#36733;#22343;#34913; -http://www.protech.net.cn RADWARE ALTEON -http://www.zgpt.cn/pro1.htm #21457;#30005;#26426;#21457;#30005;#26426;#32452; -http://www.zgpt.cn/showroom.htm #26612;#27833;#21457;#30005;#26426; -http://www.zt148.com #24459;#24072;#24459;#24072;#20107;#21153;#25152;#27861;#24459;#21672;#35810; -http://www.148-law.com #24459;#24072;#27861;#24459;#39038;#38382;#27861;#24459;#21672;#35810; -http://www.148-law.com/housing/service.htm #24459;#24072;#20107;#21153;#25152; -http://www.huihualin.com/sclyj.htm #27700;#22788;#29702; -http://www.rotek.com.cn/1024-768.htm #27700;#22788;#29702; -http://www.bjerwai.com/modules/peixun/english.htm #33521;#35821;
[io] FileUtils.touch() on Windows
I just ran the IO tests on JDK1.4.1 on Windows, and the FileUtils.touch() test failed. There was 1 failure: 1) testTouch(org.apache.commons.io.FileUtilsTestCase)junit.framework.AssertionF ailedError: Set lastModified to 0. expected:0 but was:1089878988000 at org.apache.commons.io.FileUtilsTestCase.testTouch(FileUtilsTestCase.java:464 ) This uses file.setLastModified(long) Has anyone else seen issues with file.setLastModified(long) on Windows Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BETWIXT] Array of bytes anyone?
Inger, Matthew [EMAIL PROTECTED] writes:
If you're going to put something like binary, I would encourage
you to put an encoding style there:
foo
bar encoding=base64.../bar
/foo
This would give people other methods of encoding in the future. As
for the mapping, I think something like:
That's a nice idea. I'm a little unsure about introducing a fixed
dependency on commons codec, though.
But we could make the encoding attribute optional and pass it
through to the Converter which might use it to select an encoding.
Robert, what do you think?
Regards
Henning
element name=foo
element name=bar
property=bar
binary=true
encoding=base64 /
/element
/element
In this way, it would become abundtantly clear exactly what is going on
from the mapping. These properties could potentially be ignored if you
weren't dealing with a type which could be converted to binary (byte[],
String)
-Original Message-
From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 13, 2004 11:51 AM
To: [EMAIL PROTECTED]
Subject: [BETWIXT] Array of bytes anyone?
Hi,
for a project, I need Betwixt to convert a special sort of beans into
XML. Beans, which contain a byte [] property (They come from Hibernate
which maps BINARY and TEXT onto these types, which is fine).
Regular Betwixt builds something like
foo
byte0/byte
byte1/byte
byte2/byte
byte3/byte
/foo
for propery foo, which is not exactly the most efficient way to
express this array of bytes. Especially if it has about 5 MBytes
size. ;-)
I was wondering whether I could get this done with regular betwixt but
the isPrimitive() in XMLIntrospectorHelp always bite me. In the end I
came up with the attached patch, which works fine for me (it might not
be ideal, because the resulting XML contains the raw sew^Wbinary data
if you write the bean out.
For my application I extend the DefaultObjectStringConverter to do
base64 encoding on the fly and end up with nice looking XML like this:
foo attr1=1 attr2=2 attr3=3
binary
xCHPdC7mAlirPoYY8dZr1fACaXAqpW83BKOz//yCMWUkzgtkvkMhD0MwQpclKdsOhHB1PbaRzbxA
5KmsIprAxtG5Vkm2ze5jRUPY+og3Rqq5ccj19BL6joB0PKQmnJRlU0bw9ZGJntrIVH4g9Lq1E4Sx
bquW8iIOBGvsE3kYaW0bbf1mdPT2ubNnW2+fbm17wnhQxw9Ertbz1M69Mdp649/TZ//64WVw6Gg5
aLwq2161CMeKB0glbtMXxpNGASDG4G42q16YDtOIbJwRF429GLfpc+OJAI7UkHhGvx+cDcHYbTUC
YoSnsRNN+jn9AfcogqRDz/SfejeSC8FY0WQzggCCM8LT2BdjNs3T9fNEgCzWMyXRTRSCofdVFiD2
L1cSbZxSgQBJRU5ErkJggg==
/binary
/foo
which is exactly what I need.
I was wondering if it would be more clever to allow the user to
explicitly set the primitiveType property of the element descriptor
from the .betwixt file. I found no way to do so, though and I already
had this patch which works for me.
Anyway, here is the patch, discussions welcome. ;-) This is against
CVS HEAD. I would volunteer to write an Unit test for it if has a
chance to get applied.
Regards
Henning
--- cut ---
Index:
src/java/org/apache/commons/betwixt/digester/XMLIntrospectorHelper.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/digest
er/XMLIntrospectorHelper.java,v
retrieving revision 1.31
diff -u -r1.31 XMLIntrospectorHelper.java
--- src/java/org/apache/commons/betwixt/digester/XMLIntrospectorHelper.java
4 Jul 2004 16:40:49 - 1.31
+++ src/java/org/apache/commons/betwixt/digester/XMLIntrospectorHelper.java
13 Jul 2004 15:39:37 -
@@ -583,6 +583,8 @@
} else if ( type.equals( Object.class ) ) {
return false;
+} else if (type.equals ( byte [].class) ) {
+return true;
}
return type.getName().startsWith( java.lang. )
|| Number.class.isAssignableFrom( type )
Index:
src/java/org/apache/commons/betwixt/strategy/DefaultObjectStringConverter.ja
va
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/strate
gy/DefaultObjectStringConverter.java,v
retrieving revision 1.10
diff -u -r1.10 DefaultObjectStringConverter.java
---
src/java/org/apache/commons/betwixt/strategy/DefaultObjectStringConverter.ja
va 4 Jul 2004 16:57:05 - 1.10
+++
src/java/org/apache/commons/betwixt/strategy/DefaultObjectStringConverter.ja
va 13 Jul 2004 15:39:37 -
@@ -66,7 +66,8 @@
if ( object instanceof java.util.Date isUtilDate( type ) ) {
return formatter.format( (java.util.Date) object );
-
+} else if ( object instanceof byte[]) {
+return new String((byte []) object);
} else {
// use ConvertUtils implementation
return super.objectToString( object, type, flavour, context
);
@@ -98,6 +99,8 @@
// but never mind
return
cvs commit: jakarta-commons/io/src/java/org/apache/commons/io FileUtils.java
scolebourne2004/07/15 01:21:14
Modified:io/src/test/org/apache/commons/io FileUtilsTestCase.java
io/src/java/org/apache/commons/io FileUtils.java
Log:
FileUtils.read/write byte array methods
Revision ChangesPath
1.21 +43 -3
jakarta-commons/io/src/test/org/apache/commons/io/FileUtilsTestCase.java
Index: FileUtilsTestCase.java
===
RCS file:
/home/cvs/jakarta-commons/io/src/test/org/apache/commons/io/FileUtilsTestCase.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- FileUtilsTestCase.java3 Jul 2004 11:24:49 - 1.20
+++ FileUtilsTestCase.java15 Jul 2004 08:21:14 - 1.21
@@ -22,12 +22,12 @@
import java.io.OutputStream;
import java.net.URL;
-import org.apache.commons.io.testtools.FileBasedTestCase;
-
import junit.framework.Test;
import junit.framework.TestSuite;
import junit.textui.TestRunner;
+import org.apache.commons.io.testtools.FileBasedTestCase;
+
/**
* This is used to test FileUtils for correctness.
*
@@ -465,6 +465,46 @@
FileUtils.touch(file) ;
assertEquals(FileUtils.touch() didn't empty the file., 1, file.length());
assertFalse(FileUtils.touch() changed lastModified., 0 ==
file.lastModified()) ;
+}
+
+public void testReadFileToString() throws Exception {
+File file = new File(getTestDirectory(), read.obj);
+FileOutputStream out = new FileOutputStream(file);
+byte[] text = Hello /u1234.getBytes(UTF8);
+out.write(text);
+out.close();
+
+String data = FileUtils.readFileToString(file, UTF8);
+assertEquals(Hello /u1234, data);
+}
+
+public void testReadFileToByteArray() throws Exception {
+File file = new File(getTestDirectory(), read.txt);
+FileOutputStream out = new FileOutputStream(file);
+out.write(11);
+out.write(21);
+out.write(31);
+out.close();
+
+byte[] data = FileUtils.readFileToByteArray(file);
+assertEquals(3, data.length);
+assertEquals(11, data[0]);
+assertEquals(21, data[1]);
+assertEquals(31, data[2]);
+}
+
+public void testWriteStringToFile() throws Exception {
+File file = new File(getTestDirectory(), write.txt);
+FileUtils.writeStringToFile(file, Hello /u1234, UTF8);
+byte[] text = Hello /u1234.getBytes(UTF8);
+assertEqualContent(text, file);
+}
+
+public void testWriteByteArrayToFile() throws Exception {
+File file = new File(getTestDirectory(), write.obj);
+byte[] data = new byte[] {11, 21, 31};
+FileUtils.writeByteArrayToFile(file, data);
+assertEqualContent(data, file);
}
}
1.34 +48 -12jakarta-commons/io/src/java/org/apache/commons/io/FileUtils.java
Index: FileUtils.java
===
RCS file:
/home/cvs/jakarta-commons/io/src/java/org/apache/commons/io/FileUtils.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- FileUtils.java3 Jul 2004 11:20:45 - 1.33
+++ FileUtils.java15 Jul 2004 08:21:14 - 1.34
@@ -121,7 +121,7 @@
* @throws IOException If an I/O problem occurs
*/
public static void touch(File file) throws IOException {
-OutputStream out = new java.io.FileOutputStream(file, true);
+OutputStream out = new FileOutputStream(file, true);
IOUtils.closeQuietly(out);
file.setLastModified(System.currentTimeMillis());
}
@@ -271,8 +271,8 @@
InputStream input1 = null;
InputStream input2 = null;
try {
-input1 = new java.io.FileInputStream(file1);
-input2 = new java.io.FileInputStream(file2);
+input1 = new FileInputStream(file1);
+input2 = new FileInputStream(file2);
return IOUtils.contentEquals(input1, input2);
} finally {
@@ -574,16 +574,15 @@
* in inconsistent results.
* /p
*
- * @param file the file to read.
- * @param encoding the encoding to use
+ * @param file the file to read
+ * @param encoding the encoding to use
* @return The file contents or null if read failed.
* @throws IOException in case of an I/O error
- * @throws UnsupportedEncodingException if the encoding is not supported
- * by the VM
+ * @throws UnsupportedEncodingException if the encoding is not supported by the
VM
*/
public static String readFileToString(
File file, String encoding) throws IOException {
-InputStream in = new
[GUMP@brutus]: jakarta-commons/commons-primitives failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project commons-primitives has an issue affecting its community integration. This issue affects 7 projects, and has been outstanding for 13 runs. Project State : 'Failed', Reason 'Build Failed' The following are affected: - bootstrap-ojb : ObjectRelationalBridge - commons-jelly-tags-ojb : A variety of tags for working with the ObjectBridge persiste... - commons-primitives : Provides a collection of types and utilities optimized for w... - commons-sql : Basic Services Architecture - db-ojb : ObjectRelationalBridge - jakarta-turbine-stratum-full : Turbine Components - test-ojb : ObjectRelationalBridge Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons/commons-primitives/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Sole jar [commons-primitives-20040715.jar] identifier set to project name -INFO- Enable verbose output, due to 13 previous error(s). -INFO- Failed with reason build failed -INFO- Enable debug output, due to build failure. The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons/commons-primitives/gump_work/build_jakarta-commons_commons-primitives.html Work Name: build_jakarta-commons_commons-primitives (Type: Build) State: Failed Elapsed: 11 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -verbose -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dcomponent.version=20040715 dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/primitives] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/primitives/target/classes:/usr/local/gump/public/workspace/jakarta-commons/primitives/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-testframework-20040715.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar- [java] 38) testListListIteratorPreviousRemove(TestFloatListList.testListListIteratorPreviousRemove) junit.framework.AssertionFailedError: expected same:1.0 was not:1.0 [java] at org.apache.commons.collections.list.AbstractTestList.testListListIteratorPreviousRemove(AbstractTestList.java:811) [java] at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] 39) testListListIteratorPreviousRemove(TestListFloatList.testListListIteratorPreviousRemove) junit.framework.AssertionFailedError: expected same:1.0 was not:1.0 [java] at org.apache.commons.collections.list.AbstractTestList.testListListIteratorPreviousRemove(AbstractTestList.java:811) [java] at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] 40) testListListIteratorPreviousRemove(TestListFloatList.bulkTestSubList.testListListIteratorPreviousRemove) junit.framework.AssertionFailedError: expected same:4.0 was not:4.0 [java] at org.apache.commons.collections.list.AbstractTestList.testListListIteratorPreviousRemove(AbstractTestList.java:811) [java] at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] 41) testListListIteratorPreviousRemove(TestDoubleListList.testListListIteratorPreviousRemove) junit.framework.AssertionFailedError: expected same:1.0 was not:1.0 [java] at org.apache.commons.collections.list.AbstractTestList.testListListIteratorPreviousRemove(AbstractTestList.java:811) [java] at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] 42) testListListIteratorPreviousRemove(TestListDoubleList.testListListIteratorPreviousRemove
Re: [io] FileUtils.touch() on Windows
No, it works fine here on WinXP under JDK 1.4.2_05. But I've just realized that the the last change to touch() broke JDK 1.3 compatibility. I'm looking at it now. On 15.07.2004 10:13:02 Stephen Colebourne wrote: I just ran the IO tests on JDK1.4.1 on Windows, and the FileUtils.touch() test failed. There was 1 failure: 1) testTouch(org.apache.commons.io.FileUtilsTestCase)junit.framework.AssertionF ailedError: Set lastModified to 0. expected:0 but was:1089878988000 at org.apache.commons.io.FileUtilsTestCase.testTouch(FileUtilsTestCase.java:464 ) This uses file.setLastModified(long) Has anyone else seen issues with file.setLastModified(long) on Windows Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/io/src/java/org/apache/commons/io FileUtils.java
jeremias2004/07/15 02:16:17
Modified:io/src/java/org/apache/commons/io FileUtils.java
Log:
Bugfix for listFiles for directories where the current user has no rights.
Reestablish JDK 1.3 compatibility for touch().
Revision ChangesPath
1.35 +11 -7 jakarta-commons/io/src/java/org/apache/commons/io/FileUtils.java
Index: FileUtils.java
===
RCS file:
/home/cvs/jakarta-commons/io/src/java/org/apache/commons/io/FileUtils.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- FileUtils.java15 Jul 2004 08:21:14 - 1.34
+++ FileUtils.java15 Jul 2004 09:16:17 - 1.35
@@ -121,19 +121,23 @@
* @throws IOException If an I/O problem occurs
*/
public static void touch(File file) throws IOException {
-OutputStream out = new FileOutputStream(file, true);
-IOUtils.closeQuietly(out);
+if (!file.exists()) {
+OutputStream out = new FileOutputStream(file);
+IOUtils.closeQuietly(out);
+}
file.setLastModified(System.currentTimeMillis());
}
private static void innerListFiles(Collection files, File directory,
IOFileFilter filter) {
File[] found = directory.listFiles((FileFilter)filter);
-for (int i = 0; i found.length; i++) {
-if (found[i].isDirectory()) {
-innerListFiles(files, found[i], filter);
-} else {
-files.add(found[i]);
+if (found != null) {
+for (int i = 0; i found.length; i++) {
+if (found[i].isDirectory()) {
+innerListFiles(files, found[i], filter);
+} else {
+files.add(found[i]);
+}
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: jakarta-commons-sandbox/commons-resources failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project commons-resources has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 4 runs. Project State : 'Failed', Reason 'Build Failed' The following are affected: - commons-resources : Commons resources Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-resources/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Sole jar [commons-resources-20040715.jar] identifier set to project name -INFO- Enable verbose output, due to 4 previous error(s). -INFO- Failed with reason build failed -INFO- Enable debug output, due to build failure. The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-resources/gump_work/build_jakarta-commons-sandbox_commons-resources.html Work Name: build_jakarta-commons-sandbox_commons-resources (Type: Build) State: Failed Elapsed: 7 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -verbose -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-resources-20040715 dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/target/classes:/usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20040715.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/hibernate-2.1/hibernate2.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/hibernate-2.1/lib/cglib-full-2.0.1.jar:/usr/local/gump/public/workspace/hsqldb/lib/hsqldb.jar:/usr/local/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar- [junit] Jul 15, 2004 2:33:41 AM net.sf.hibernate.cfg.Configuration configure [junit] INFO: configuring from resource: /hibernate.cfg.xml [junit] Jul 15, 2004 2:33:41 AM net.sf.hibernate.cfg.Configuration getConfigurationInputStream [junit] INFO: Configuration resource: /hibernate.cfg.xml [junit] - --- [junit] Testcase: testInherit took 0.166 sec [junit] Caused an ERROR [junit] org/xml/sax/ext/Locator2 [junit] java.lang.NoClassDefFoundError: org/xml/sax/ext/Locator2 [junit] at org.dom4j.io.SAXContentHandler.getEncoding(SAXContentHandler.java:749) [junit] at org.dom4j.io.SAXContentHandler.createDocument(SAXContentHandler.java:731) [junit] at org.dom4j.io.SAXContentHandler.getDocument(SAXContentHandler.java:168) [junit] at org.dom4j.io.SAXContentHandler.startDTD(SAXContentHandler.java:333) [junit] at org.apache.crimson.parser.Parser2.maybeDoctypeDecl(Parser2.java:1311) [junit] at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:656) [junit] at org.apache.crimson.parser.Parser2.parse(Parser2.java:337) [junit] at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448) [junit] at org.dom4j.io.SAXReader.read(SAXReader.java:336) [junit] at net.sf.hibernate.cfg.Configuration.doConfigure(Configuration.java:930) [junit] at net.sf.hibernate.cfg.Configuration.configure(Configuration.java:874) [junit
Re: [io] FileUtils.touch() on Windows
Just installed JDK 1.4.1_07 on my WinXP box. I can't reproduce your problem. On 15.07.2004 10:13:02 Stephen Colebourne wrote: I just ran the IO tests on JDK1.4.1 on Windows, and the FileUtils.touch() test failed. There was 1 failure: 1) testTouch(org.apache.commons.io.FileUtilsTestCase)junit.framework.AssertionF ailedError: Set lastModified to 0. expected:0 but was:1089878988000 at org.apache.commons.io.FileUtilsTestCase.testTouch(FileUtilsTestCase.java:464 ) This uses file.setLastModified(long) Has anyone else seen issues with file.setLastModified(long) on Windows Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/io/src/test/org/apache/commons/io FileUtilsTestCase.java
jeremias2004/07/15 02:49:53
Modified:io/src/test/org/apache/commons/io FileUtilsTestCase.java
Log:
Testing prerequisites for touch() test, making it safer.
Revision ChangesPath
1.22 +5 -1
jakarta-commons/io/src/test/org/apache/commons/io/FileUtilsTestCase.java
Index: FileUtilsTestCase.java
===
RCS file:
/home/cvs/jakarta-commons/io/src/test/org/apache/commons/io/FileUtilsTestCase.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- FileUtilsTestCase.java15 Jul 2004 08:21:14 - 1.21
+++ FileUtilsTestCase.java15 Jul 2004 09:49:53 - 1.22
@@ -453,6 +453,10 @@
public void testTouch() throws IOException {
File file = new File(getTestDirectory(), touch.txt) ;
+if (file.exists()) {
+file.delete();
+}
+assertTrue(Prerequisite failed, test file exists, !file.exists());
FileUtils.touch(file);
assertTrue(FileUtils.touch() created file., file.exists());
FileOutputStream out = new FileOutputStream(file) ;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: jelly-tags/commons-jelly-tags-jsl failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 6 runs. Project State : 'Failed', Reason 'Build Failed' The following are affected: - commons-jelly-tags-jsl : The Jelly Stylesheet Library (JSL) Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-jsl/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Sole jar [commons-jelly-tags-jsl-20040715.jar] identifier set to project name -INFO- Enable verbose output, due to 6 previous error(s). -INFO- Failed with reason build failed -INFO- Enable debug output, due to build failure. The following work was performed: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-jsl/gump_work/build_jelly-tags_commons-jelly-tags-jsl.html Work Name: build_jelly-tags_commons-jelly-tags-jsl (Type: Build) State: Failed Elapsed: 7 secs Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -verbose -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-jsl-20040715 jar [Working Directory: /usr/local/gump/public/workspace/jelly-tags/jsl] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/jelly-tags/jsl/target/classes:/usr/local/gump/public/workspace/jelly-tags/jsl/target/test-classes:/usr/local/gump/public/workspace/jakarta-commons/jelly/target/commons-jelly-20040715.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20040715.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20040715.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/packages/dom4j-1.4/dom4j-full.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-20040715.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtmlXni.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtml.jar:/usr/local/gump/public/workspace/jelly-tags/xml/target/commons-jelly-tags-xml-20040715.jar:/usr/local/gump/public/workspace/jelly-tags/junit/target/commons-jelly-tags-junit-20040715.jar:/usr/local/gump/public/workspace/jelly-tags/ant/target/commons-jelly-tags-ant-20040715.jar:/usr/local/gump/public/workspace/commons-grant/target/commons-grant-20040715.jar:/usr/local/gump/public/workspace/jelly-tags/log/target/commons-jelly-tags-log-20040715.jar- [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:102) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:89) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:51) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:71) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:148) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:51) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:73) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:65) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:57) [junit] at org.apache.commons.jelly.tags.jsl.StylesheetTag.doTag(StylesheetTag.java:124) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:233) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:89) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit
[GUMP@brutus]: jelly-tags/commons-jelly-tags-define failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project commons-jelly-tags-define has an issue affecting its community integration. This issue affects 3 projects, and has been outstanding for 6 runs. Project State : 'Failed', Reason 'Build Failed' The following are affected: - commons-jelly-tags-define : This is a Jelly taglib for defining new tags and tag librari... - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-define/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Sole jar [commons-jelly-tags-define-20040715.jar] identifier set to project name -INFO- Enable verbose output, due to 6 previous error(s). -INFO- Failed with reason build failed -INFO- Enable debug output, due to build failure. The following work was performed: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-define/gump_work/build_jelly-tags_commons-jelly-tags-define.html Work Name: build_jelly-tags_commons-jelly-tags-define (Type: Build) State: Failed Elapsed: 6 secs Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -verbose -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-define-20040715 jar [Working Directory: /usr/local/gump/public/workspace/jelly-tags/define] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/jelly-tags/define/target/classes:/usr/local/gump/public/workspace/jelly-tags/define/target/test-classes:/usr/local/gump/public/workspace/jakarta-commons/jelly/target/commons-jelly-20040715.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20040715.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20040715.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/packages/dom4j-1.4/dom4j-full.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-20040715.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtmlXni.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtml.jar:/usr/local/gump/public/workspace/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-20040715.jar:/usr/local/gump/public/workspace/jelly-tags/junit/target/commons-jelly-tags-junit-20040715.jar:/usr/local/gump/public/workspace/jelly-tags/log/target/commons-jelly-tags-log-20040715.jar:/usr/local/gump/public/workspace/jelly-tags/xml/target/commons-jelly-tags-xml-20040715.jar- [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:236) [junit] at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:233) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:89) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] Caused by: java.lang.NullPointerException [junit] at org.apache.commons.jelly.tags.define.SuperTag.doTag(SuperTag.java:44) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:233) [junit] ... 20 more [junit] Root cause [junit] java.lang.NullPointerException [junit] at org.apache.commons.jelly.tags.define.SuperTag.doTag(SuperTag.java:44) [junit
DO NOT REPLY [Bug 30119] New: - Attributes Compiler ignores Sub-Packages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30119. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30119 Attributes Compiler ignores Sub-Packages Summary: Attributes Compiler ignores Sub-Packages Product: Commons Version: Nightly Builds Platform: Other OS/Version: Other Status: NEW Severity: Blocker Priority: Other Component: attributes AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] when i use the ant task to generate the metadata-classes everything is ok, if i place java-files only in the default package. the attributes compiler is not able to detect attribute definitions in java-files below the default package. taskdef resource=org/apache/commons/attributes/anttasks.properties / target name=attributes attribute-compiler destdir=temp/ fileset dir=src includes=*.java / /attribute-compiler /target - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30119] - Attributes Compiler ignores Sub-Packages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30119. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30119 Attributes Compiler ignores Sub-Packages [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [workflow] new contributor
Hi, I'd also like to help with applying patches, promoting, etc. I'll at least watch this threads for now ;) Yoav Shapira Millennium Research Informatics -Original Message- From: Mike Colbert [mailto:[EMAIL PROTECTED] Sent: Thursday, July 15, 2004 12:26 AM To: Jakarta Commons Developers List Subject: Re: [workflow] new contributor Mike Colbert wrote: Would like to start looking into the possibilities of a more powerful process modeling/scripting mechanism. Something that can express more complex behavior, e.g. conditional transitions, composite activities, error handling, data-passing, etc. Mike Colbert Actually, after looking through the core package documentation, looks quite expressive already. Will have to play around with some more complicated scenarios. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] FileUtils.touch() on Windows
I'm using Win98. It could be that. Basically calling the method seems to set the last modified time to now. Stephen - Original Message - From: Jeremias Maerki [EMAIL PROTECTED] Just installed JDK 1.4.1_07 on my WinXP box. I can't reproduce your problem. On 15.07.2004 10:13:02 Stephen Colebourne wrote: I just ran the IO tests on JDK1.4.1 on Windows, and the FileUtils.touch() test failed. There was 1 failure: 1) testTouch(org.apache.commons.io.FileUtilsTestCase)junit.framework.AssertionF ailedError: Set lastModified to 0. expected:0 but was:1089878988000 at org.apache.commons.io.FileUtilsTestCase.testTouch(FileUtilsTestCase.java:464 ) This uses file.setLastModified(long) Has anyone else seen issues with file.setLastModified(long) on Windows Jeremias Maerki - 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: cvs commit: jakarta-commons-sandbox/workflow build.xml
Hello Craig, Which maven release do you use?? I thought that we fixed this bug!! It seems that you committed some absolute paths! Arnaud + property name=defaulttargetdir value=/home/craigmcc/Apache/jakarta-commons- sandbox/workflow/target + /property + property name=libdir value=/home/craigmcc/Apache/jakarta-commons- sandbox/workflow/target/lib + /property + property name=classesdir value=/home/craigmcc/Apache/jakarta-commons- sandbox/workflow/target/classes + /property + property name=testclassesdir value=/home/craigmcc/Apache/jakarta-commons- sandbox/workflow/target/test-classes + /property + property name=testclassesdir value=/home/craigmcc/Apache/jakarta-commons- sandbox/workflow/target/test-classes + /property + property name=testreportdir value=/home/craigmcc/Apache/jakarta-commons- sandbox/workflow/target/test-reports - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] FileUtils.touch() on Windows
Dumb ol'Win98. It's probably best then to check the os.name and/or os.version system properties to disable the assertion in the testcase. I guess the touch() method should work under Win98, right? On 15.07.2004 21:37:53 Stephen Colebourne wrote: I'm using Win98. It could be that. Basically calling the method seems to set the last modified time to now. - Original Message - From: Jeremias Maerki [EMAIL PROTECTED] Just installed JDK 1.4.1_07 on my WinXP box. I can't reproduce your problem. On 15.07.2004 10:13:02 Stephen Colebourne wrote: I just ran the IO tests on JDK1.4.1 on Windows, and the FileUtils.touch() test failed. There was 1 failure: 1) testTouch(org.apache.commons.io.FileUtilsTestCase)junit.framework.AssertionF ailedError: Set lastModified to 0. expected:0 but was:1089878988000 at org.apache.commons.io.FileUtilsTestCase.testTouch(FileUtilsTestCase.java:464 ) This uses file.setLastModified(long) Has anyone else seen issues with file.setLastModified(long) on Windows Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons-sandbox/workflow build.xml
Arnaud Heritier wrote: Hello Craig, Which maven release do you use?? I thought that we fixed this bug!! It seems that you committed some absolute paths! Arnaud I used the 1.0 final release :-(. Reproducible test case -- go to jakarta-commons-sandbox/workflow and run maven ant. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30131] New: - Getting Logger to give trace Information!
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30131. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30131 Getting Logger to give trace Information! Summary: Getting Logger to give trace Information! Product: Commons Version: 1.2 Final Platform: Other OS/Version: OS/400 Status: NEW Severity: Normal Priority: Other Component: Logging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have looked at the User Manual and can not get the logging to be sent to display when I run my class! I set my system properties as follows! Is there anything more I need to do to get the trace information displaying! System.setProperty (org.apache.commons.logging.simplelog.log.org.apache.commons.httpclient, debu g); System.setProperty (org.apache.commons.logging.Log, org.apache.commons.logging.impl.SimpleLog); System.setProperty (org.apache.commons.logging.simplelog.showdatetime, true); System.setProperty (org.apache.commons.logging.simplelog.log.httpclient.wire, trace); System.setProperty (org.apache.commons.logging.simplelog.log.org.apache.commons.httpclient, trac e); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons-sandbox/workflow build.xml
Ok, Craig I hoped that you used an old release ;-) I will try to found what is happening! Arnaud -Message d'origine- De : Craig McClanahan [mailto:[EMAIL PROTECTED] Envoyé : jeudi 15 juillet 2004 22:41 À : Jakarta Commons Developers List Objet : Re: cvs commit: jakarta-commons-sandbox/workflow build.xml Arnaud Heritier wrote: Hello Craig, Which maven release do you use?? I thought that we fixed this bug!! It seems that you committed some absolute paths! Arnaud I used the 1.0 final release :-(. Reproducible test case -- go to jakarta-commons-sandbox/workflow and run maven ant. Craig - 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 30133] New: - Locale related TestCases fail
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30133.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=30133
Locale related TestCases fail
Summary: Locale related TestCases fail
Product: Commons
Version: 1.2 Final
Platform: All
OS/Version: All
Status: NEW
Severity: Major
Priority: Other
Component: JXPath
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
The TestCases below fail in jxpath 1.2 RC1. Note that the locale on the JXPathContext
is correctly set to
Locale.US, but the tests find the default locale (of my computer) de_DE!
Testcase:
testFormatNumberFunction(org.apache.commons.jxpath.ri.compiler.CoreFunctionTest):
FAILED
Evaluating format-number(123456789, '#.0') expected:123456789.0
but
was:123456789
junit.framework.AssertionFailedError: Evaluating format-number(123456789,
'#.0')
expected:123456789.0 but was:123456789
at
org.apache.commons.jxpath.JXPathTestCase.assertXPathValue(JXPathTestCase.java:52)
at
org.apache.commons.jxpath.ri.compiler.CoreFunctionTest.testFormatNumberFunction(CoreFunctionTes
t.java:153)
Testcase: testAttributeLang(org.apache.commons.jxpath.ri.model.beans.BeanModelTest):
FAILED
Evaluating @xml:lang expected:en-US but was:de-DE
junit.framework.AssertionFailedError: Evaluating @xml:lang expected:en-US but
was:de-DE
at
org.apache.commons.jxpath.JXPathTestCase.assertXPathValue(JXPathTestCase.java:52)
at
org.apache.commons.jxpath.ri.model.BeanModelTestCase.testAttributeLang(BeanModelTestCase.java:
605)
Testcase: testLang(org.apache.commons.jxpath.ri.model.dom.DOMModelTest):Caused
an ERROR
No value for xpath: //product/price:sale[lang('en')]/saleEnds
org.apache.commons.jxpath.JXPathException: No value for xpath:
//product/price:sale[lang('en')]/
saleEnds
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getValue(JXPathContextReferenceImpl.java:
344)
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getValue(JXPathContextReferenceImpl.java:
280)
at
org.apache.commons.jxpath.JXPathTestCase.assertXPathValue(JXPathTestCase.java:51)
at
org.apache.commons.jxpath.ri.model.XMLModelTestCase.testLang(XMLModelTestCase.java:698)
Testcase:
testAttributeLang(org.apache.commons.jxpath.ri.model.dynabeans.DynaBeanModelTest):
FAILED
Evaluating @xml:lang expected:en-US but was:de-DE
junit.framework.AssertionFailedError: Evaluating @xml:lang expected:en-US but
was:de-DE
at
org.apache.commons.jxpath.JXPathTestCase.assertXPathValue(JXPathTestCase.java:52)
at
org.apache.commons.jxpath.ri.model.BeanModelTestCase.testAttributeLang(BeanModelTestCase.java:
604)
Testcase: testLang(org.apache.commons.jxpath.ri.model.jdom.JDOMModelTest): Caused
an ERROR
No value for xpath: //product/price:sale[lang('en')]/saleEnds
org.apache.commons.jxpath.JXPathException: No value for xpath:
//product/price:sale[lang('en')]/
saleEnds
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getValue(JXPathContextReferenceImpl.java:
344)
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getValue(JXPathContextReferenceImpl.java:
280)
at
org.apache.commons.jxpath.JXPathTestCase.assertXPathValue(JXPathTestCase.java:51)
at
org.apache.commons.jxpath.ri.model.XMLModelTestCase.testLang(XMLModelTestCase.java:698)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/builder SqlBuilder.java HsqlDbBuilder.java
tomdz 2004/07/15 14:45:56
Modified:sql/src/java/org/apache/commons/sql/builder SqlBuilder.java
HsqlDbBuilder.java
Log:
Moved foreignkey generation at the end of the generated sql (for dbs that want
external foreignkeys) to avoid references to yet-undefined tables
Revision ChangesPath
1.17 +26 -5
jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/builder/SqlBuilder.java
Index: SqlBuilder.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/builder/SqlBuilder.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- SqlBuilder.java 2 Mar 2004 13:18:31 - 1.16
+++ SqlBuilder.java 15 Jul 2004 21:45:56 - 1.17
@@ -19,6 +19,7 @@
import java.io.Writer;
import java.sql.Connection;
import java.sql.SQLException;
+import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
@@ -111,6 +112,10 @@
tableComment(table);
createTable(table);
}
+// we're writing the foreignkeys last to ensure that all referenced tables
are already defined
+for (Iterator iter = database.getTables().iterator(); iter.hasNext(); ) {
+createExternalForeignKey((Table) iter.next());
+}
}
/**
@@ -147,7 +152,7 @@
}
/**
- * Outputs the DDL to create the table along with any constraints
+ * Outputs the DDL to create the table along with any non-external constraints
*/
public void createTable(Table table) throws IOException {
print(create table );
@@ -172,15 +177,21 @@
if (!isPrimaryKeyEmbedded()) {
writePrimaryKeysAlterTable(table);
}
-if (!isForeignKeysEmbedded()) {
-writeForeignKeysAlterTable(table);
-}
if (!isIndexesEmbedded()) {
writeIndexes(table);
}
}
/**
+ * Creates an external foreignkey definition.
+ */
+public void createExternalForeignKey(Table table) throws IOException {
+if (!isForeignKeysEmbedded()) {
+writeForeignKeysAlterTable(table);
+}
+}
+
+/**
* Outputs the DDL to add a column to a table.
*/
public void createColumn(Table table, Column column) throws IOException {
@@ -698,7 +709,8 @@
*/
public void alterDatabase(Database desiredDb, Connection cn, boolean doDrops,
boolean modifyColumns) throws IOException, SQLException {
-Database currentDb = new JdbcModelReader(cn).getDatabase();
+Database currentDb = new JdbcModelReader(cn).getDatabase();
+ArrayList deferredTables = new ArrayList();
for (Iterator iter = desiredDb.getTables().iterator(); iter.hasNext(); ) {
Table desiredTable = (Table) iter.next();
@@ -711,6 +723,8 @@
if ( currentTable == null ) {
log.info( creating table + desiredTable.getName() );
createTable( desiredTable );
+// we're deferring foreignkey generation
+deferredTables.add(desiredTable);
} else {
//add any columns, indices, or constraints
@@ -797,6 +811,13 @@
} //table exists?
} //for tables create
+
+// generating deferred foreignkeys
+for (Iterator iter = deferredTables.iterator(); iter.hasNext();)
+{
+createExternalForeignKey((Table)iter.next());
+}
+
//check for table drops
for (Iterator iter = currentDb.getTables().iterator(); iter.hasNext(); ) {
1.5 +0 -4
jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/builder/HsqlDbBuilder.java
Index: HsqlDbBuilder.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/builder/HsqlDbBuilder.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- HsqlDbBuilder.java28 Feb 2004 03:35:47 - 1.4
+++ HsqlDbBuilder.java15 Jul 2004 21:45:56 - 1.5
@@ -27,8 +27,4 @@
* @version $Revision$
*/
public class HsqlDbBuilder extends SqlBuilder {
-
-public HsqlDbBuilder() {
-setForeignKeysEmbedded(true);
-}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [workflow] new contributor
I'm going to make Colin happy :-), and go through his outstanding patches this evening (Pacific time in the US), applying what I can. :-)) Thanks, Craig. My project has its first release in a couple of weeks, so after that I will start to take a look at harvesting out re-usable stuff and submitting that back. Colin Sharples IBM Business Consulting Services, New Zealand sharples -at- nz.ibm.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Having some problems with expect 100 continue
Jennifer, (1) Are you using SSL? (2) What's the JRE version you are using? (3) What web server you are targeting? (4) Are you going through a proxy? Oleg -Original Message- From: Jennifer Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, July 15, 2004 1:49 To: Commons HttpClient Project Subject: Having some problems with expect 100 continue All, I'm now calling setUseExpectHeader(true) for my putMethod. However, I'm running into a few problems. First, when putting a 1 character text file (Content-Length: 3) it doesn't authorize and eventually I get the 'Maximum redirects (100) exceeded' exception. If I take a slightly larger text file (Content-Length: 7), then all is fine. However, I do get the INFO message: Jul 14, 2004 4:40:33 PM org.apache.commons.httpclient.HttpMethodBase processRequest INFO: Recoverable exception caught when processing request If I try to put a 1MB mpg file, the request appears to hang with: Jul 14, 2004 4:41:44 PM org.apache.commons.httpclient.HttpMethodBase writeRequest INFO: 100 (continue) read timeout. Resume sending the request Any suggestions? I did try this with the latest build of HttpClient also and had similar results. Thanks, Jen On Jul 14, 2004, at 11:43 AM, Oleg Kalnichevski wrote: On Wed, 2004-07-14 at 18:10, Jennifer Ward wrote: On Jul 13, 2004, at 8:03 PM, Michael Becke wrote: Another way to handle this problem is to use the expect 100 continue feature of HTTP. This feature is disabled in HttpClient by default, as only a few servers support it correctly. You can re-enable it by calling setUseExpectHeader(true) on the post method. Yes, Oleg mentioned this a few days ago. It sounds like this feature still causes the request to get sent twice (even though the request body will not get sent if the server cannot receive it). I was hoping for a way to send each request only once (with the correct auth header the first time). Jennifer, This can be done if you are prepared to handle the entire authentication process manually (actually with HttpClient 3.0 it can be done quite easily). The question is if it is really worth the trouble. It is important to understand Digest authentication scheme is more secure primarily because it involves frequent challenge-response exchanges. The server generates a nonce which is used by the HTTP clients to produce the password digest. If the server is configured to change the nonce too often, that would basically defeat any sort of preemptive authentication mechanism, in the worst case rendering it even less efficient than 'expect-continue' handshake. If the server is configured to keep the nonce for too long, that would inevitably make Digest authentication less secure. It is not impossible to strike a balance between efficiency and security. The question is whether the performance gains really justify additional complexity Oleg I'm not having much luck with that though, so I may end up using the expect 100 continue feature after all. Thanks Jen - 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] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29973] - HttpClient wire log performance problems
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29973. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29973 HttpClient wire log performance problems --- Additional Comments From [EMAIL PROTECTED] 2004-07-15 11:58 --- Almost everyone uses Log4J because it has been around for a long time, so it could be interesting to update the docs with the info described here: http://marc.theaimsgroup.com/?l=httpclient-commons-devm=108790997923656w=2 Otherwise most of those using Log4J will have very bad performance with HttpClient (eg. 2 minutes to stream something back instead of 0.7seconds!) Wim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30122] New: - HttpRecoverableException should store cause exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30122.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=30122
HttpRecoverableException should store cause exception
Summary: HttpRecoverableException should store cause exception
Product: Commons
Version: 2.0 Final
Platform: All
URL: http://jakarta.apache.org/commons/httpclient/apidocs/org
/apache/commons/httpclient/HttpRecoverableException.html
OS/Version: Other
Status: NEW
Severity: Enhancement
Priority: Other
Component: HttpClient
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
We are using the HttpClient library in XINS, a next-generation framework for
web-based services. A call to a XINS API is made over HTTP, using either GET or
POST. This call may fail due to a number of causes, for example:
1. connection refused
2. connection time-out
3. socket time-out
4. total call time-out
5. HTTP error code (5xx)
etc.
All these conditions need to be distinguished in the XINS client-side code, in
order to make the proper decision on whether or not fail-over should be attempted.
Cases 1, 2, 4 and 5 can be properly detected with HttpClient 2.0. However, case
3 can not be detected in a proper manner. If there is a socket time-out, then a
java.net.SocketTimeoutException is thrown. However, this exception is hidden
with the code like this:
} catch (IOException e) {
throw new HttpRecoverableException(e.toString());
}
Since Java 1.4, a cause can be associated with an exception instance. See the
class description of class Throwable:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Throwable.html
Suggestion: Change the code as follows:
} catch (IOException e) {
throw new HttpRecoverableException(e.toString()).initCause(e);
}
If you don't want to make the code Java 1.4-specific, you could change the
HttpRecoverableException constructor to add a 'Throwable cause' or 'IOException
cause' argument, along with a getCauseException() method.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30122] - HttpRecoverableException should store cause exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30122. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30122 HttpRecoverableException should store cause exception [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-07-15 13:55 --- Ernst, This is a well known problem with HttpClient 2.0. It's been already fixed in the CVS HEAD (HttpClient 3.0). For details see Bug #19868 Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30122] - HttpRecoverableException should store cause exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30122. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30122 HttpRecoverableException should store cause exception [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Additional Comments From [EMAIL PROTECTED] 2004-07-15 14:03 --- Indeed. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Having some problems with expect 100 continue
On Jul 15, 2004, at 1:09 AM, Kalnichevski, Oleg wrote: (1) Are you using SSL? No (2) What's the JRE version you are using? Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-117.1) (3) What web server you are targeting? We are using Apache Tomcat with Slide for WebDAV support. (4) Are you going through a proxy? I'm hitting the server directly at the moment. I will be going through a proxy eventually. Jen Oleg -Original Message- From: Jennifer Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, July 15, 2004 1:49 To: Commons HttpClient Project Subject: Having some problems with expect 100 continue All, I'm now calling setUseExpectHeader(true) for my putMethod. However, I'm running into a few problems. First, when putting a 1 character text file (Content-Length: 3) it doesn't authorize and eventually I get the 'Maximum redirects (100) exceeded' exception. If I take a slightly larger text file (Content-Length: 7), then all is fine. However, I do get the INFO message: Jul 14, 2004 4:40:33 PM org.apache.commons.httpclient.HttpMethodBase processRequest INFO: Recoverable exception caught when processing request If I try to put a 1MB mpg file, the request appears to hang with: Jul 14, 2004 4:41:44 PM org.apache.commons.httpclient.HttpMethodBase writeRequest INFO: 100 (continue) read timeout. Resume sending the request Any suggestions? I did try this with the latest build of HttpClient also and had similar results. Thanks, Jen On Jul 14, 2004, at 11:43 AM, Oleg Kalnichevski wrote: On Wed, 2004-07-14 at 18:10, Jennifer Ward wrote: On Jul 13, 2004, at 8:03 PM, Michael Becke wrote: Another way to handle this problem is to use the expect 100 continue feature of HTTP. This feature is disabled in HttpClient by default, as only a few servers support it correctly. You can re-enable it by calling setUseExpectHeader(true) on the post method. Yes, Oleg mentioned this a few days ago. It sounds like this feature still causes the request to get sent twice (even though the request body will not get sent if the server cannot receive it). I was hoping for a way to send each request only once (with the correct auth header the first time). Jennifer, This can be done if you are prepared to handle the entire authentication process manually (actually with HttpClient 3.0 it can be done quite easily). The question is if it is really worth the trouble. It is important to understand Digest authentication scheme is more secure primarily because it involves frequent challenge-response exchanges. The server generates a nonce which is used by the HTTP clients to produce the password digest. If the server is configured to change the nonce too often, that would basically defeat any sort of preemptive authentication mechanism, in the worst case rendering it even less efficient than 'expect-continue' handshake. If the server is configured to keep the nonce for too long, that would inevitably make Digest authentication less secure. It is not impossible to strike a balance between efficiency and security. The question is whether the performance gains really justify additional complexity Oleg I'm not having much luck with that though, so I may end up using the expect 100 continue feature after all. Thanks Jen - 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] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - 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: Having some problems with expect 100 continue
Jennifer Ward wrote: On Jul 15, 2004, at 1:09 AM, Kalnichevski, Oleg wrote: (3) What web server you are targeting? We are using Apache Tomcat with Slide for WebDAV support. Aha. At least in Tomcat 4.0, it silently processes the Expect 100 Continue so that the web-application never sees that part of the request. In the servlet environment, a web-app must enable container managed security before the client would even have a chance of the expect 100 continue process to work as desired, and even then, I don't think that the connectors necessarily support it (correctly). Absent the container managed security, Tomcat (or any other servlet container, for that matter) will be forced to pass along the request to the web application - at which point the web-application may decide that the invoker is not authorized, and force the client to send an additional request. That sounds like you might be seeing that behavior. If you control the server, then you can look at the choice of Tomcat version and supported connector, and look into doing container managed security for your Slide-based webapp. You might need to send emails to the corresponding mailing lists to get to the bottom of it -Eric. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Having some problems with expect 100 continue
Jennifer, What is the version of Tomcat you are using? Even though, as Eric pointed out, Tomcat does not fully support the expect/continue handshake, last time I checked it at least did not produce any nasty side effects. Please let me know the exact version of Tomcat I'll re-test HttpClient against that particular version. The complete wire/debug log produced with the latest HttpClient CVS snapshot might also be of help Oleg On Thu, 2004-07-15 at 18:57, Jennifer Ward wrote: On Jul 15, 2004, at 1:09 AM, Kalnichevski, Oleg wrote: (1) Are you using SSL? No (2) What's the JRE version you are using? Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-117.1) (3) What web server you are targeting? We are using Apache Tomcat with Slide for WebDAV support. (4) Are you going through a proxy? I'm hitting the server directly at the moment. I will be going through a proxy eventually. Jen Oleg -Original Message- From: Jennifer Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, July 15, 2004 1:49 To: Commons HttpClient Project Subject: Having some problems with expect 100 continue All, I'm now calling setUseExpectHeader(true) for my putMethod. However, I'm running into a few problems. First, when putting a 1 character text file (Content-Length: 3) it doesn't authorize and eventually I get the 'Maximum redirects (100) exceeded' exception. If I take a slightly larger text file (Content-Length: 7), then all is fine. However, I do get the INFO message: Jul 14, 2004 4:40:33 PM org.apache.commons.httpclient.HttpMethodBase processRequest INFO: Recoverable exception caught when processing request If I try to put a 1MB mpg file, the request appears to hang with: Jul 14, 2004 4:41:44 PM org.apache.commons.httpclient.HttpMethodBase writeRequest INFO: 100 (continue) read timeout. Resume sending the request Any suggestions? I did try this with the latest build of HttpClient also and had similar results. Thanks, Jen On Jul 14, 2004, at 11:43 AM, Oleg Kalnichevski wrote: On Wed, 2004-07-14 at 18:10, Jennifer Ward wrote: On Jul 13, 2004, at 8:03 PM, Michael Becke wrote: Another way to handle this problem is to use the expect 100 continue feature of HTTP. This feature is disabled in HttpClient by default, as only a few servers support it correctly. You can re-enable it by calling setUseExpectHeader(true) on the post method. Yes, Oleg mentioned this a few days ago. It sounds like this feature still causes the request to get sent twice (even though the request body will not get sent if the server cannot receive it). I was hoping for a way to send each request only once (with the correct auth header the first time). Jennifer, This can be done if you are prepared to handle the entire authentication process manually (actually with HttpClient 3.0 it can be done quite easily). The question is if it is really worth the trouble. It is important to understand Digest authentication scheme is more secure primarily because it involves frequent challenge-response exchanges. The server generates a nonce which is used by the HTTP clients to produce the password digest. If the server is configured to change the nonce too often, that would basically defeat any sort of preemptive authentication mechanism, in the worst case rendering it even less efficient than 'expect-continue' handshake. If the server is configured to keep the nonce for too long, that would inevitably make Digest authentication less secure. It is not impossible to strike a balance between efficiency and security. The question is whether the performance gains really justify additional complexity Oleg I'm not having much luck with that though, so I may end up using the expect 100 continue feature after all. Thanks Jen - 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] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you
DO NOT REPLY [Bug 30127] New: - MultipartPost parameter values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30127. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30127 MultipartPost parameter values Summary: MultipartPost parameter values Product: Commons Version: 2.0 Final Platform: All OS/Version: OS/400 Status: NEW Severity: Normal Priority: Other Component: HttpClient AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] How can I get the parameter values for a MultipartPost method! For a string part all I need is the value! For the File part I would like to see file name and the actual file data that is being posted to the server! I can trace the file upload when using Microsoft IE 6 to send my file to a web site by using TracePlus/web Detective software! I then can get a view of exactly what is being sent as parameters to the web server I am posting a file to! I do not know of a way to get the same information using the Httpclient! I am providing a Microsoft Word document that shows a copy of the trace when using Microsoft IE 6! How can I get this same information for the HttpClient so that I can compare them? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30127] - MultipartPost parameter values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30127. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30127 MultipartPost parameter values --- Additional Comments From [EMAIL PROTECTED] 2004-07-15 18:47 --- Created an attachment (id=12119) Trace of MultipartPost to web site using Microsoft IE 6 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Having some problems with expect 100 continue
On Jul 15, 2004, at 11:02 AM, Oleg Kalnichevski wrote: Jennifer, What is the version of Tomcat you are using? Even though, as Eric pointed out, Tomcat does not fully support the expect/continue handshake, last time I checked it at least did not produce any nasty side effects. Please let me know the exact version of Tomcat I'll re-test HttpClient against that particular version. Were using 4.1.27, but moving soon to 4.1.30. The complete wire/debug log produced with the latest HttpClient CVS snapshot might also be of help I've already rebuilt my client using HttpClient 2.0. I'll rebuild it using the latest snapshot, rerun and grab the log. Thanks Jen Oleg On Thu, 2004-07-15 at 18:57, Jennifer Ward wrote: On Jul 15, 2004, at 1:09 AM, Kalnichevski, Oleg wrote: (1) Are you using SSL? No (2) What's the JRE version you are using? Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-117.1) (3) What web server you are targeting? We are using Apache Tomcat with Slide for WebDAV support. (4) Are you going through a proxy? I'm hitting the server directly at the moment. I will be going through a proxy eventually. Jen Oleg -Original Message- From: Jennifer Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, July 15, 2004 1:49 To: Commons HttpClient Project Subject: Having some problems with expect 100 continue All, I'm now calling setUseExpectHeader(true) for my putMethod. However, I'm running into a few problems. First, when putting a 1 character text file (Content-Length: 3) it doesn't authorize and eventually I get the 'Maximum redirects (100) exceeded' exception. If I take a slightly larger text file (Content-Length: 7), then all is fine. However, I do get the INFO message: Jul 14, 2004 4:40:33 PM org.apache.commons.httpclient.HttpMethodBase processRequest INFO: Recoverable exception caught when processing request If I try to put a 1MB mpg file, the request appears to hang with: Jul 14, 2004 4:41:44 PM org.apache.commons.httpclient.HttpMethodBase writeRequest INFO: 100 (continue) read timeout. Resume sending the request Any suggestions? I did try this with the latest build of HttpClient also and had similar results. Thanks, Jen On Jul 14, 2004, at 11:43 AM, Oleg Kalnichevski wrote: On Wed, 2004-07-14 at 18:10, Jennifer Ward wrote: On Jul 13, 2004, at 8:03 PM, Michael Becke wrote: Another way to handle this problem is to use the expect 100 continue feature of HTTP. This feature is disabled in HttpClient by default, as only a few servers support it correctly. You can re-enable it by calling setUseExpectHeader(true) on the post method. Yes, Oleg mentioned this a few days ago. It sounds like this feature still causes the request to get sent twice (even though the request body will not get sent if the server cannot receive it). I was hoping for a way to send each request only once (with the correct auth header the first time). Jennifer, This can be done if you are prepared to handle the entire authentication process manually (actually with HttpClient 3.0 it can be done quite easily). The question is if it is really worth the trouble. It is important to understand Digest authentication scheme is more secure primarily because it involves frequent challenge-response exchanges. The server generates a nonce which is used by the HTTP clients to produce the password digest. If the server is configured to change the nonce too often, that would basically defeat any sort of preemptive authentication mechanism, in the worst case rendering it even less efficient than 'expect-continue' handshake. If the server is configured to keep the nonce for too long, that would inevitably make Digest authentication less secure. It is not impossible to strike a balance between efficiency and security. The question is whether the performance gains really justify additional complexity Oleg I'm not having much luck with that though, so I may end up using the expect 100 continue feature after all. Thanks Jen --- -- 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] * ** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please
DO NOT REPLY [Bug 30127] - MultipartPost parameter values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30127. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30127 MultipartPost parameter values [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-07-15 19:00 --- Tom, Please refer to the HttpClient logging guide for details how to activate the wire log http://jakarta.apache.org/commons/httpclient/logging.html Please send all your further questions about HttpClient to the mailing list http://jakarta.apache.org/commons/httpclient/mail-lists.html Bugzilla should _ideally_ be used to file bugs/feature requests only - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Having some problems with expect 100 continue
Jennifer,
I ran a small test app that posted a 3 byte request to the local Tomcat
4.1.29 with 'expect: continue' handshake on. Everything seems fine as
far as I can tell
DEBUG] HttpClient - -Java version: 1.4.2
[DEBUG] HttpClient - -Java vendor: Sun Microsystems Inc.
...
[DEBUG] HttpClient - -Operating system name: Linux
[DEBUG] HttpClient - -Operating system architecture: i386
[DEBUG] HttpClient - -Operating system version: 2.6.6-1.435smp
...
[DEBUG] DefaultHttpParams - -Set parameter http.protocol.expect-continue
= true
[DEBUG] header - - POST /httpclienttest/body HTTP/1.1[\r][\n]
[DEBUG] HttpMethodBase - -Adding Host request header
[DEBUG] header - - User-Agent: Jakarta
Commons-HttpClient/3.0-alpha1[\r][\n]
[DEBUG] header - - Host: localhost:8080[\r][\n]
[DEBUG] header - - Expect: 100-continue[\r][\n]
[DEBUG] header - - Content-Length: 3[\r][\n]
[DEBUG] header - - [\r][\n]
[DEBUG] header - - HTTP/1.1 100 Continue[\r][\n]
[DEBUG] HttpMethodBase - -OK to continue received
[DEBUG] EntityEnclosingMethod - -Request body sent
[DEBUG] header - - HTTP/1.1 200 OK[\r][\n]
[DEBUG] header - - Content-Type: text/html[\r][\n]
[DEBUG] header - - Date: Thu, 15 Jul 2004 19:08:04 GMT[\r][\n]
[DEBUG] header - - Server: Apache Tomcat/4.1.29 (HTTP/1.1
Connector)[\r][\n]
[DEBUG] header - - Transfer-Encoding: chunked[\r][\n]
HTTP/1.1 200 OK
[DEBUG] HttpMethodBase - -Resorting to protocol version default close
connection policy
[DEBUG] HttpMethodBase - -Should NOT close connection, using HTTP/1.1
[DEBUG] HttpConnection - -Releasing connection back to connection
manager.
Here's the test app source
HttpClient agent = new HttpClient();
PostMethod httppost =
new PostMethod(http://localhost:8080/httpclienttest/body;);
httppost.getParams().
setParameter(HttpMethodParams.USE_EXPECT_CONTINUE, new Boolean(true));
httppost.setRequestEntity(new StringRequestEntity(1\r\n));
try {
agent.executeMethod(httppost);
} finally {
httppost.releaseConnection();
}
System.out.println(httppost.getStatusLine());
I am afraid I'll need more details about your local execution
environment in order to be any further help. A wirelog would be a good
start
Cheers,
Oleg
On Thu, 2004-07-15 at 20:54, Jennifer Ward wrote:
On Jul 15, 2004, at 11:02 AM, Oleg Kalnichevski wrote:
Jennifer,
What is the version of Tomcat you are using? Even though, as Eric
pointed out, Tomcat does not fully support the expect/continue
handshake, last time I checked it at least did not produce any nasty
side effects. Please let me know the exact version of Tomcat I'll
re-test HttpClient against that particular version.
Were using 4.1.27, but moving soon to 4.1.30.
The complete wire/debug log produced with the latest HttpClient CVS
snapshot might also be of help
I've already rebuilt my client using HttpClient 2.0. I'll rebuild it
using the latest snapshot, rerun and grab the log.
Thanks
Jen
Oleg
On Thu, 2004-07-15 at 18:57, Jennifer Ward wrote:
On Jul 15, 2004, at 1:09 AM, Kalnichevski, Oleg wrote:
(1) Are you using SSL?
No
(2) What's the JRE version you are using?
Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.2_03-117.1)
(3) What web server you are targeting?
We are using Apache Tomcat with Slide for WebDAV support.
(4) Are you going through a proxy?
I'm hitting the server directly at the moment. I will be going through
a proxy eventually.
Jen
Oleg
-Original Message-
From: Jennifer Ward [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 15, 2004 1:49
To: Commons HttpClient Project
Subject: Having some problems with expect 100 continue
All,
I'm now calling setUseExpectHeader(true) for my putMethod. However,
I'm
running into a few problems.
First, when putting a 1 character text file (Content-Length: 3) it
doesn't authorize and eventually I get the 'Maximum redirects (100)
exceeded' exception.
If I take a slightly larger text file (Content-Length: 7), then all
is
fine. However, I do get the INFO message:
Jul 14, 2004 4:40:33 PM org.apache.commons.httpclient.HttpMethodBase
processRequest
INFO: Recoverable exception caught when processing request
If I try to put a 1MB mpg file, the request appears to hang with:
Jul 14, 2004 4:41:44 PM org.apache.commons.httpclient.HttpMethodBase
writeRequest
INFO: 100 (continue) read timeout. Resume sending the request
Any suggestions? I did try this with the latest build of HttpClient
also and had similar results.
Thanks,
Jen
On Jul 14, 2004, at 11:43 AM, Oleg Kalnichevski wrote:
On Wed, 2004-07-14 at 18:10, Jennifer Ward wrote:
On Jul 13, 2004, at 8:03 PM,
DO NOT REPLY [Bug 30127] - MultipartPost parameter values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30127. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30127 MultipartPost parameter values --- Additional Comments From [EMAIL PROTECTED] 2004-07-15 19:54 --- This can be done but I still do not see why you'd want that. You can use FilePartSource to set the Part's content, and FilePartSource already has getFileName() method. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems using HttpClient 2.0 when connecting to an especific sit e
Arturo,
When hit directly the site works just fine
[DEBUG] HttpConnection - -HttpConnection.setSoTimeout(0)
[DEBUG] HttpMethodBase - -Execute loop try 1
[DEBUG] header - - GET
/ClubPremier/Saldo/0,11100,11000.html?lang=0location=0ncuenta=0reqForm=1num_socio=767871601continuar.x=51continuar.y=12
HTTP/1.1[\r][\n]
[DEBUG] HttpMethodBase - -Adding Host request header
[DEBUG] header - - User-Agent: Jakarta
Commons-HttpClient/2.0final[\r][\n]
[DEBUG] header - - Host: www.aeromexico.com:9090[\r][\n]
[DEBUG] header - - [\r][\n]
[DEBUG] header - - HTTP/1.1 200 OK[\r][\n]
[DEBUG] header - - Server: Resin/2.1.6[\r][\n]
[DEBUG] header - - Cache-Control: private[\r][\n]
[DEBUG] header - - Set-Cookie: JSESSIONID=axQFtSY14UKg;
Path=/[\r][\n]
[DEBUG] header - - Transfer-Encoding: chunked[\r][\n]
[DEBUG] header - - Date: Thu, 15 Jul 2004 19:44:28 GMT[\r][\n]
[DEBUG] HttpMethodBase - -Cookie accepted: $Version=0;
JSESSIONID=axQFtSY14UKg; $Path=/
[DEBUG] HttpConnection - -HttpConnection.getSoTimeout()
[DEBUG] HttpMethodBase - -Resorting to protocol version default close
connection policy
[DEBUG] HttpMethodBase - -Should NOT close connection, using HTTP/1.1.
HTTP/1.1 200 OK
This has apparently something to do with the proxy you are using. My
guess is that it does not support HTTP/1.1. Try using HTTP/1.0 instead
HTH
Oleg
On Thu, 2004-07-15 at 02:41, Esquivel Sanchez, Arturo wrote:
Hi,
I'm using HttpClient 2.o to connect to the following site:
http://www.aeromexico.com:9090/ClubPremier/Saldo/0,11100,11000.html?lang=0;
location=0ncuenta=0reqForm=1num_socio=767871601continuar.x=51continuar.
y=12
the hyperlink works fine when using a browser. But when using my code i'm
always getting a 503 HTTP status code, instead of the 200 for ok. and
consecuently i´m not getting any HTML.
the code is something like this (i'm using a proxy):
url =
http://www.aeromexico.com:9090/ClubPremier/Saldo/0,11100,11000.html?lang=0;
location=0ncuenta=0reqForm=1num_socio=447739905continuar.x=51continuar.
y=12;
HttpClient client = new HttpClient();
client.getState().setProxyCredentials(null, null, new
UsernamePasswordCredentials(System.getProperty(http.proxyUserName),
System.getProperty(http.proxyPassword)));
client.getHostConfiguration().setProxy(System.getProperty(http.proxyHost),
Integer.parseInt(System.getProperty(http.proxyPort,80)));
GetMethod method1 = new GetMethod(url);
try{
statusCode = client.executeMethod(method1);
System.out.println(Return Code= + statusCode); //here i get
always 503
}catch (HttpRecoverableException e) {
System.out.println(An recoverable exception occurred,retrying. +
e.getMessage());
e.printStackTrace();
}finally{
System.out.println(Releasing Connection method 1. );
method1.releaseConnection();
}
thanks in advance
Saludos, Arturo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30127] - MultipartPost parameter values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30127. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30127 MultipartPost parameter values --- Additional Comments From [EMAIL PROTECTED] 2004-07-15 20:19 --- The feature request that I am asking for is to add a method to the FilePart class like getFileName, and getFileValue! Or for the Part Class to add a method like getPartValue! I want to be able to view all parameter attributes and values! Whether they are a string value pair, or a file part! So that I can configure the Multipart Post to send the same post as the IE 6 browser does! If I have a parameter on the MultipartPost called button with a value big I want to be able to view both the parameter attributes and it's assigned value! That way I can verify that it is working the way that I coded it to work! You do have a getFileName! But no getFileContents to view what was actually sent! I can get the name of a string parameter but can not view it's value after the method is executed (the POST method had a getParameter value)! The Post method also lets you view what your request was after it has been executed! By, using the getRequestBodyasString! If I had something that worked like that for the MultipartPost that would show me exactly what was sent to the server it would help with debugging! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30127] - MultipartPost parameter values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30127. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30127 MultipartPost parameter values --- Additional Comments From [EMAIL PROTECTED] 2004-07-15 20:34 --- Tom, Personally I do not mind having a few methods added to the FilePart class. All I am trying to say that there is a much better and simpler way to see exactly what kind of request HttpClient generates and what exactly gets sent across the wire. The wire/debug log _may_ well be what you need to debug HttpClient. Please give it a shot, and if it is not what you want, I will happily reopen the ticket and provide a patch. http://jakarta.apache.org/commons/httpclient/logging.html Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Having some problems with expect 100 continue
Oleg,
I cannot get the wire trace to work. I set the following properties in
my java app, but I only get the INFO messages.
System.setProperty(org.apache.commons.logging.Log,
org.apache.commons.logging.impl.SimpleLog);
System.setProperty(org.apache.commons.logging.simplelog.showdatetime,
true);
System.setProperty(org.apache.commons.logging.simplelog.log.httpclient.
wire, debug);
System.setProperty(org.apache.commons.logging.simplelog.log.org.apache.
commons.httpclient, debug);
However, maybe this will help. I can put a small text file with no
problems (although a 1 char file doesn't work). The problem I have is
with putting a 1MB mpg file. I get the following messages then it
appears to hang:
Jul 15, 2004 2:48:44 PM
org.apache.commons.httpclient.auth.AuthChallengeProcessor
selectAuthScheme
INFO: digest authentication scheme selected
Jul 15, 2004 2:48:47 PM org.apache.commons.httpclient.HttpMethodBase
writeRequest
INFO: 100 (continue) read timeout. Resume sending the request
Here's the wire trace (captured via tcpflow):
017.207.015.182.51117-017.207.015.236.02150: PUT
/jentest1/Pictures/martin_crashTest3.mpg HTTP/1.1
User-Agent: Jakarta Commons-HttpClient/3.0-alpha1
Host: 17.207.15.236:2150
Expect: 100-continue
Content-Length: 941220
017.207.015.236.02150-017.207.015.182.51117: HTTP/1.1 401 Unauthorized
Server: AppleDotMacServer
X-Responding-Server: qa2-webdav03-qfe0
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
WWW-Authenticate: Basic realm=idisk.mac.com
WWW-Authenticate: Digest realm=idisk.mac.com, qop=auth,
nonce=12c55e49b83f4c39e0918155b5a2dd28,
opaque=eb7ff29a0f14ddfa49f3f7880010b08a
Content-Type: text/plain
Content-Length: 23
Date: Thu, 15 Jul 2004 21:47:39 GMT
Server: Apache Coyote/1.0
017.207.015.236.02150-017.207.015.182.51117: AUTHORIZATION_REQUIRED
017.207.015.182.51117-017.207.015.236.02150: PUT
/jentest1/Pictures/martin_crashTest3.mpg HTTP/1.1
User-Agent: Jakarta Commons-HttpClient/3.0-alpha1
Expect: 100-continue
Content-Length: 941220
Authorization: Digest username=jentest1, realm=idisk.mac.com,
nonce=12c55e49b83f4c39e0918155b5a2dd28,
uri=/jentest1/Pictures/martin_crashTest3.mpg,
response=a31a69f2e53b4b0afecf44904e952cca, qop=auth, nc=0001,
cnonce=214d593beae47a6bc701094207c8ab31,
opaque=eb7ff29a0f14ddfa49f3f7880010b08a
Host: 17.207.15.236:2150
017.207.015.182.51117-017.207.015.236.02150:
!...
[content omitted]
By the way, I am running this on a Mac OS X system.
Thanks
Jen
On Jul 15, 2004, at 12:16 PM, Oleg Kalnichevski wrote:
Jennifer,
I ran a small test app that posted a 3 byte request to the local Tomcat
4.1.29 with 'expect: continue' handshake on. Everything seems fine as
far as I can tell
DEBUG] HttpClient - -Java version: 1.4.2
[DEBUG] HttpClient - -Java vendor: Sun Microsystems Inc.
...
[DEBUG] HttpClient - -Operating system name: Linux
[DEBUG] HttpClient - -Operating system architecture: i386
[DEBUG] HttpClient - -Operating system version: 2.6.6-1.435smp
...
[DEBUG] DefaultHttpParams - -Set parameter
http.protocol.expect-continue
= true
[DEBUG] header - - POST /httpclienttest/body HTTP/1.1[\r][\n]
[DEBUG] HttpMethodBase - -Adding Host request header
[DEBUG] header - - User-Agent: Jakarta
Commons-HttpClient/3.0-alpha1[\r][\n]
[DEBUG] header - - Host: localhost:8080[\r][\n]
[DEBUG] header - - Expect: 100-continue[\r][\n]
[DEBUG] header - - Content-Length: 3[\r][\n]
[DEBUG] header - - [\r][\n]
[DEBUG] header - - HTTP/1.1 100 Continue[\r][\n]
[DEBUG] HttpMethodBase - -OK to continue received
[DEBUG] EntityEnclosingMethod - -Request body sent
[DEBUG] header - - HTTP/1.1 200 OK[\r][\n]
[DEBUG] header - - Content-Type: text/html[\r][\n]
[DEBUG] header - - Date: Thu, 15 Jul 2004 19:08:04 GMT[\r][\n]
[DEBUG] header - - Server: Apache Tomcat/4.1.29 (HTTP/1.1
Connector)[\r][\n]
[DEBUG] header - - Transfer-Encoding: chunked[\r][\n]
HTTP/1.1 200 OK
[DEBUG] HttpMethodBase - -Resorting to protocol version default close
connection policy
[DEBUG] HttpMethodBase - -Should NOT close connection, using HTTP/1.1
[DEBUG] HttpConnection - -Releasing connection back to connection
manager.
Here's the test app source
HttpClient agent = new HttpClient();
PostMethod httppost =
new PostMethod(http://localhost:8080/httpclienttest/body;);
httppost.getParams().
setParameter(HttpMethodParams.USE_EXPECT_CONTINUE, new
Boolean(true));
httppost.setRequestEntity(new StringRequestEntity(1\r\n));
try {
agent.executeMethod(httppost);
} finally {
httppost.releaseConnection();
}
System.out.println(httppost.getStatusLine());
Re: Having some problems with expect 100 continue
Jennifer Please correct me if I am wrong but it looks like you are not hitting Tomcat directly. Can it be that you are using an HTTP server to do the Digest authentication and than redirect requests to Tomcat via a plugin? What on earth is 'AppleDotMacServer'? It looks like the AppleDotMacServer (whatever that is) or the plugin does not really support 'expect-continue' handshake Oleg On Fri, 2004-07-16 at 00:01, Jennifer Ward wrote: Oleg, I cannot get the wire trace to work. I set the following properties in my java app, but I only get the INFO messages. System.setProperty(org.apache.commons.logging.Log, org.apache.commons.logging.impl.SimpleLog); System.setProperty(org.apache.commons.logging.simplelog.showdatetime, true); System.setProperty(org.apache.commons.logging.simplelog.log.httpclient. wire, debug); System.setProperty(org.apache.commons.logging.simplelog.log.org.apache. commons.httpclient, debug); However, maybe this will help. I can put a small text file with no problems (although a 1 char file doesn't work). The problem I have is with putting a 1MB mpg file. I get the following messages then it appears to hang: Jul 15, 2004 2:48:44 PM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: digest authentication scheme selected Jul 15, 2004 2:48:47 PM org.apache.commons.httpclient.HttpMethodBase writeRequest INFO: 100 (continue) read timeout. Resume sending the request Here's the wire trace (captured via tcpflow): 017.207.015.182.51117-017.207.015.236.02150: PUT /jentest1/Pictures/martin_crashTest3.mpg HTTP/1.1 User-Agent: Jakarta Commons-HttpClient/3.0-alpha1 Host: 17.207.15.236:2150 Expect: 100-continue Content-Length: 941220 017.207.015.236.02150-017.207.015.182.51117: HTTP/1.1 401 Unauthorized Server: AppleDotMacServer X-Responding-Server: qa2-webdav03-qfe0 Pragma: No-cache Cache-Control: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT WWW-Authenticate: Basic realm=idisk.mac.com WWW-Authenticate: Digest realm=idisk.mac.com, qop=auth, nonce=12c55e49b83f4c39e0918155b5a2dd28, opaque=eb7ff29a0f14ddfa49f3f7880010b08a Content-Type: text/plain Content-Length: 23 Date: Thu, 15 Jul 2004 21:47:39 GMT Server: Apache Coyote/1.0 017.207.015.236.02150-017.207.015.182.51117: AUTHORIZATION_REQUIRED 017.207.015.182.51117-017.207.015.236.02150: PUT /jentest1/Pictures/martin_crashTest3.mpg HTTP/1.1 User-Agent: Jakarta Commons-HttpClient/3.0-alpha1 Expect: 100-continue Content-Length: 941220 Authorization: Digest username=jentest1, realm=idisk.mac.com, nonce=12c55e49b83f4c39e0918155b5a2dd28, uri=/jentest1/Pictures/martin_crashTest3.mpg, response=a31a69f2e53b4b0afecf44904e952cca, qop=auth, nc=0001, cnonce=214d593beae47a6bc701094207c8ab31, opaque=eb7ff29a0f14ddfa49f3f7880010b08a Host: 17.207.15.236:2150 017.207.015.182.51117-017.207.015.236.02150: !... [content omitted] By the way, I am running this on a Mac OS X system. Thanks Jen On Jul 15, 2004, at 12:16 PM, Oleg Kalnichevski wrote: Jennifer, I ran a small test app that posted a 3 byte request to the local Tomcat 4.1.29 with 'expect: continue' handshake on. Everything seems fine as far as I can tell DEBUG] HttpClient - -Java version: 1.4.2 [DEBUG] HttpClient - -Java vendor: Sun Microsystems Inc. ... [DEBUG] HttpClient - -Operating system name: Linux [DEBUG] HttpClient - -Operating system architecture: i386 [DEBUG] HttpClient - -Operating system version: 2.6.6-1.435smp ... [DEBUG] DefaultHttpParams - -Set parameter http.protocol.expect-continue = true [DEBUG] header - - POST /httpclienttest/body HTTP/1.1[\r][\n] [DEBUG] HttpMethodBase - -Adding Host request header [DEBUG] header - - User-Agent: Jakarta Commons-HttpClient/3.0-alpha1[\r][\n] [DEBUG] header - - Host: localhost:8080[\r][\n] [DEBUG] header - - Expect: 100-continue[\r][\n] [DEBUG] header - - Content-Length: 3[\r][\n] [DEBUG] header - - [\r][\n] [DEBUG] header - - HTTP/1.1 100 Continue[\r][\n] [DEBUG] HttpMethodBase - -OK to continue received [DEBUG] EntityEnclosingMethod - -Request body sent [DEBUG] header - - HTTP/1.1 200 OK[\r][\n] [DEBUG] header - - Content-Type: text/html[\r][\n] [DEBUG] header - - Date: Thu, 15 Jul 2004 19:08:04 GMT[\r][\n] [DEBUG] header - - Server: Apache Tomcat/4.1.29 (HTTP/1.1 Connector)[\r][\n] [DEBUG] header - - Transfer-Encoding: chunked[\r][\n] HTTP/1.1 200 OK [DEBUG] HttpMethodBase - -Resorting to protocol version default close connection policy [DEBUG] HttpMethodBase - -Should NOT close connection, using HTTP/1.1 [DEBUG] HttpConnection - -Releasing connection back to connection manager.
Re: Having some problems with expect 100 continue
Oleg, Yes, I believe you are correct. I was finally able to get this to work with larger tar files (still not with mpg's for some reason). However, our implementation doesn't seem to handle the handshaking very well and takes a long time to respond. Without the handshaking on I can actually put the file about 10 times faster (even with the content getting sent twice). Since I am only writing a test client, sending the request without handshaking will be adequate for my purposes. Thanks for your help with this, Jen On Jul 15, 2004, at 3:34 PM, Oleg Kalnichevski wrote: Jennifer Please correct me if I am wrong but it looks like you are not hitting Tomcat directly. Can it be that you are using an HTTP server to do the Digest authentication and than redirect requests to Tomcat via a plugin? What on earth is 'AppleDotMacServer'? It looks like the AppleDotMacServer (whatever that is) or the plugin does not really support 'expect-continue' handshake Oleg On Fri, 2004-07-16 at 00:01, Jennifer Ward wrote: Oleg, I cannot get the wire trace to work. I set the following properties in my java app, but I only get the INFO messages. System.setProperty(org.apache.commons.logging.Log, org.apache.commons.logging.impl.SimpleLog); System.setProperty(org.apache.commons.logging.simplelog.showdatetime , true); System.setProperty(org.apache.commons.logging.simplelog.log.httpclien t. wire, debug); System.setProperty(org.apache.commons.logging.simplelog.log.org.apach e. commons.httpclient, debug); However, maybe this will help. I can put a small text file with no problems (although a 1 char file doesn't work). The problem I have is with putting a 1MB mpg file. I get the following messages then it appears to hang: Jul 15, 2004 2:48:44 PM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: digest authentication scheme selected Jul 15, 2004 2:48:47 PM org.apache.commons.httpclient.HttpMethodBase writeRequest INFO: 100 (continue) read timeout. Resume sending the request Here's the wire trace (captured via tcpflow): 017.207.015.182.51117-017.207.015.236.02150: PUT /jentest1/Pictures/martin_crashTest3.mpg HTTP/1.1 User-Agent: Jakarta Commons-HttpClient/3.0-alpha1 Host: 17.207.15.236:2150 Expect: 100-continue Content-Length: 941220 017.207.015.236.02150-017.207.015.182.51117: HTTP/1.1 401 Unauthorized Server: AppleDotMacServer X-Responding-Server: qa2-webdav03-qfe0 Pragma: No-cache Cache-Control: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT WWW-Authenticate: Basic realm=idisk.mac.com WWW-Authenticate: Digest realm=idisk.mac.com, qop=auth, nonce=12c55e49b83f4c39e0918155b5a2dd28, opaque=eb7ff29a0f14ddfa49f3f7880010b08a Content-Type: text/plain Content-Length: 23 Date: Thu, 15 Jul 2004 21:47:39 GMT Server: Apache Coyote/1.0 017.207.015.236.02150-017.207.015.182.51117: AUTHORIZATION_REQUIRED 017.207.015.182.51117-017.207.015.236.02150: PUT /jentest1/Pictures/martin_crashTest3.mpg HTTP/1.1 User-Agent: Jakarta Commons-HttpClient/3.0-alpha1 Expect: 100-continue Content-Length: 941220 Authorization: Digest username=jentest1, realm=idisk.mac.com, nonce=12c55e49b83f4c39e0918155b5a2dd28, uri=/jentest1/Pictures/martin_crashTest3.mpg, response=a31a69f2e53b4b0afecf44904e952cca, qop=auth, nc=0001, cnonce=214d593beae47a6bc701094207c8ab31, opaque=eb7ff29a0f14ddfa49f3f7880010b08a Host: 17.207.15.236:2150 017.207.015.182.51117-017.207.015.236.02150: !. .. .. .. [content omitted] By the way, I am running this on a Mac OS X system. Thanks Jen On Jul 15, 2004, at 12:16 PM, Oleg Kalnichevski wrote: Jennifer, I ran a small test app that posted a 3 byte request to the local Tomcat 4.1.29 with 'expect: continue' handshake on. Everything seems fine as far as I can tell DEBUG] HttpClient - -Java version: 1.4.2 [DEBUG] HttpClient - -Java vendor: Sun Microsystems Inc. ... [DEBUG] HttpClient - -Operating system name: Linux [DEBUG] HttpClient - -Operating system architecture: i386 [DEBUG] HttpClient - -Operating system version: 2.6.6-1.435smp ... [DEBUG] DefaultHttpParams - -Set parameter http.protocol.expect-continue = true [DEBUG] header - - POST /httpclienttest/body HTTP/1.1[\r][\n] [DEBUG] HttpMethodBase - -Adding Host request header [DEBUG] header - - User-Agent: Jakarta Commons-HttpClient/3.0-alpha1[\r][\n] [DEBUG] header - - Host: localhost:8080[\r][\n] [DEBUG] header - - Expect: 100-continue[\r][\n] [DEBUG] header - - Content-Length: 3[\r][\n] [DEBUG] header - - [\r][\n] [DEBUG] header - - HTTP/1.1 100 Continue[\r][\n] [DEBUG] HttpMethodBase - -OK to continue received [DEBUG] EntityEnclosingMethod - -Request body sent [DEBUG] header - - HTTP/1.1 200 OK[\r][\n] [DEBUG] header - - Content-Type: text/html[\r][\n] [DEBUG] header - - Date: Thu, 15 Jul 2004 19:08:04 GMT[\r][\n] [DEBUG]
