[jira] Created: (CONFIGURATION-273) Saving with interpolation
Saving with interpolation
-
Key: CONFIGURATION-273
URL: https://issues.apache.org/jira/browse/CONFIGURATION-273
Project: Commons Configuration
Issue Type: New Feature
Affects Versions: 1.4
Reporter: Daniel Adrian
It will be very nice if you'll add the ability to save a configuration file
with the interpolation data.
so if my config file is :
my_home=127.0.0.1
my_place=Is ${my_home}
when I save the configuration (let's say with save(true)) it will look like
my_home=127.0.0.1
my_place=Is 127.0.0.1
Thank you!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-271) BaseConfiguration duplicates multi value keys values
[ https://issues.apache.org/jira/browse/CONFIGURATION-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498258 ] Daniel Adrian commented on CONFIGURATION-271: - Actually I used ConfigurationUtils. append which uses addProperty... Maybe some flag to indicate if duplicated values are allowed or not... > BaseConfiguration duplicates multi value keys values > > > Key: CONFIGURATION-271 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-271 > Project: Commons Configuration > Issue Type: Bug >Affects Versions: 1.4 > Reporter: Daniel Adrian > Assigned To: Emmanuel Bourg > Fix For: 1.5 > > > In addPropertyDirect(String key, Object value) the method adds the new value > to the property. > If the property has the same value in the list, it will get duplicated. > The method should check if the list contains the value and only if the result > is false add the value. > There is no logic in saving a multi value key with more than one instance of > a value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-271) BaseConfiguration duplicates multi value keys values
[ https://issues.apache.org/jira/browse/CONFIGURATION-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498008 ] Daniel Adrian commented on CONFIGURATION-271: - yes, If I have file1.ini and file2.ini and I want to merge the values from file2 to file1. file1: [test] some_key=xxx,yyy file2: [test] some_key=xxx,yyy,zzz,fff If you'll add all the properties of file2 to file1 the result will be: [test] some_key=xxx,yyy,xxx,yyy,zzz,fff where is should be: [test] some_key=,yyy,zzz,fff > BaseConfiguration duplicates multi value keys values > > > Key: CONFIGURATION-271 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-271 > Project: Commons Configuration > Issue Type: Bug >Affects Versions: 1.4 > Reporter: Daniel Adrian > Fix For: 1.5 > > > In addPropertyDirect(String key, Object value) the method adds the new value > to the property. > If the property has the same value in the list, it will get duplicated. > The method should check if the list contains the value and only if the result > is false add the value. > There is no logic in saving a multi value key with more than one instance of > a value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-271) BaseConfiguration duplicates multi value keys values
[ https://issues.apache.org/jira/browse/CONFIGURATION-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Adrian updated CONFIGURATION-271: Component/s: (was: Build) > BaseConfiguration duplicates multi value keys values > > > Key: CONFIGURATION-271 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-271 > Project: Commons Configuration > Issue Type: Bug >Affects Versions: 1.4 > Reporter: Daniel Adrian > > In addPropertyDirect(String key, Object value) the method adds the new value > to the property. > If the property has the same value in the list, it will get duplicated. > The method should check if the list contains the value and only if the result > is false add the value. > There is no logic in saving a multi value key with more than one instance of > a value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-270) INIConfiguration Does not support multi value keys
[ https://issues.apache.org/jira/browse/CONFIGURATION-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Adrian updated CONFIGURATION-270: Component/s: (was: Build) > INIConfiguration Does not support multi value keys > -- > > Key: CONFIGURATION-270 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-270 > Project: Commons Configuration > Issue Type: Bug >Affects Versions: 1.4 > Reporter: Daniel Adrian > > The INIConfiguration save(Writer writer) uses PrintWriter instead of using a > class like PropertiesConfiguration.PropertiesWriter. > Because of that the method uses getString(String key) to get the keys value > (which return onlt the first element of the list) and in doing so there is no > support for multi value keys. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONFIGURATION-271) BaseConfiguration duplicates multi value keys values
BaseConfiguration duplicates multi value keys values Key: CONFIGURATION-271 URL: https://issues.apache.org/jira/browse/CONFIGURATION-271 Project: Commons Configuration Issue Type: Bug Components: Build Affects Versions: 1.4 Reporter: Daniel Adrian In addPropertyDirect(String key, Object value) the method adds the new value to the property. If the property has the same value in the list, it will get duplicated. The method should check if the list contains the value and only if the result is false add the value. There is no logic in saving a multi value key with more than one instance of a value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONFIGURATION-270) INIConfiguration Does not support multi value keys
INIConfiguration Does not support multi value keys -- Key: CONFIGURATION-270 URL: https://issues.apache.org/jira/browse/CONFIGURATION-270 Project: Commons Configuration Issue Type: Bug Components: Build Affects Versions: 1.4 Reporter: Daniel Adrian The INIConfiguration save(Writer writer) uses PrintWriter instead of using a class like PropertiesConfiguration.PropertiesWriter. Because of that the method uses getString(String key) to get the keys value (which return onlt the first element of the list) and in doing so there is no support for multi value keys. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/xdocs news.xml
adrian 2004/10/11 05:06:42 Modified:httpclient/xdocs Tag: HTTPCLIENT_2_0_BRANCH news.xml Log: Added latest news item from Oleg Kalnichevski. Revision ChangesPath No revision No revision 1.20.2.15 +32 -1 jakarta-commons/httpclient/xdocs/news.xml Index: news.xml === RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/news.xml,v retrieving revision 1.20.2.14 retrieving revision 1.20.2.15 diff -u -r1.20.2.14 -r1.20.2.15 --- news.xml 10 Oct 2004 00:00:35 - 1.20.2.14 +++ news.xml 11 Oct 2004 12:06:41 - 1.20.2.15 @@ -10,6 +10,37 @@ + + +HttpClient project has taken a very important step toward becoming +a full-fledged Jakarta level project. From today, HttpClient is +a separate project in Apache Bugzilla issue tracking system. It is no +longer a component of the Commons project. Please use the following +details when filing bug reports for 2.0 and 3.0 branches of HttpClient: + + + +Product: +HttpClient + + +Component: +Commons HttpClient + + +Use the following URL for convenience: +http://issues.apache.org/bugzilla/enter_bug.cgi?product=HttpClient";> + Jakarta HttpClient new issue report. + + +Currently HttpClient project is debating whether we should continue using Bugzilla +as an issue tracking system or migrate to JIRA. +http://www.atlassian.com/software/jira/";>JIRA is a newer, more flexible +issue tracking system. However, http://www.atlassian.com/software/jira/";> +JIRA is not open-source software. If you have a strong opinion on this matter, +please let us know. + + We are pleased to announce the latest stable release of HttpClient, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/xdocs logging.xml tutorial.xml userguide.xml
adrian 2004/08/03 14:48:24
Modified:httpclient/xdocs Tag: HTTPCLIENT_2_0_BRANCH logging.xml
tutorial.xml userguide.xml
Log:
Minor documentation updates.
* Remove "To be completed" from the index pages. Those pages were completed long
ago.
* Moved the call to releaseConnection into a finally block in the tutorial (that
code is getting copied into a lot of projects so we should probably get it right).
* Added a note that users should ensure that log4j is configured to avoid
performance problems. (Bug 29973)
Revision ChangesPath
No revision
No revision
1.11.2.3 +6 -1 jakarta-commons/httpclient/xdocs/logging.xml
Index: logging.xml
===
RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/logging.xml,v
retrieving revision 1.11.2.2
retrieving revision 1.11.2.3
diff -u -r1.11.2.2 -r1.11.2.3
--- logging.xml 5 Jul 2004 20:55:53 - 1.11.2.2
+++ logging.xml 3 Aug 2004 21:48:24 - 1.11.2.3
@@ -142,6 +142,11 @@
log4j.logger.org.apache.commons.httpclient=DEBUG
+ Note that the default configuration for Log4J is very
+ inefficient as it causes all the logging information to be
+ generated but not actually sent anywhere. The Log4J manual is the
+ best reference for how to configure Log4J. It is available at http://logging.apache.org/log4j/docs/manual.html";>http://logging.apache.org/log4j/docs/manual.html
1.2.2.4 +32 -27jakarta-commons/httpclient/xdocs/tutorial.xml
Index: tutorial.xml
===
RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/tutorial.xml,v
retrieving revision 1.2.2.3
retrieving revision 1.2.2.4
diff -u -r1.2.2.3 -r1.2.2.4
--- tutorial.xml 23 Feb 2004 23:09:05 - 1.2.2.3
+++ tutorial.xml 3 Aug 2004 21:48:24 - 1.2.2.4
@@ -207,39 +207,44 @@
// Create a method instance.
HttpMethod method = new GetMethod(url);
-
-// Execute the method.
-int statusCode = -1;
-// We will retry up to 3 times.
-for (int attempt = 0; statusCode == -1 && attempt < 3; attempt++) {
- try {
-// execute the method.
-statusCode = client.executeMethod(method);
- } catch (HttpRecoverableException e) {
-System.err.println(
- "A recoverable exception occurred, retrying." +
- e.getMessage());
- } catch (IOException e) {
-System.err.println("Failed to download file.");
-e.printStackTrace();
-System.exit(-1);
+
+try {
+ // Execute the method.
+ int statusCode = -1;
+ byte[] responseBody = null;
+ // We will retry up to 3 times.
+ for (int attempt = 0; statusCode == -1 && attempt < 3; attempt++) {
+try {
+ // execute the method.
+ statusCode = client.executeMethod(method);
+} catch (HttpRecoverableException e) {
+ System.err.println(
+"A recoverable exception occurred, retrying." +
+e.getMessage());
+} catch (IOException e) {
+ System.err.println("Failed to download file.");
+ e.printStackTrace();
+ System.exit(-1);
+}
+ }
+ // Check that we didn't run out of retries.
+ if (statusCode == -1) {
+System.err.println("Failed to recover from exception.");
+System.exit(-2);
}
-}
-// Check that we didn't run out of retries.
-if (statusCode == -1) {
- System.err.println("Failed to recover from exception.");
- System.exit(-2);
-}
-// Read the response body.
-byte[] responseBody = method.getResponseBody();
+ // Read the response body.
+ responseBody = method.getResponseBody();
-// Release the connection.
-method.releaseConnection();
+} finally {
+ // Release the connection.
+ method.releaseConnection();
+}
// Deal with the response.
// Use caution: ensu
cvs commit: jakarta-commons/httpclient/xdocs logging.xml tutorial.xml userguide.xml
adrian 2004/08/02 21:11:09
Modified:httpclient/xdocs logging.xml tutorial.xml userguide.xml
Log:
Minor documentation updates.
* Remove "To be completed" from the index pages. Those pages were completed long
ago.
* Moved the call to releaseConnection into a finally block in the tutorial (that
code is getting copied into a lot of projects so we should probably get it right).
* Added a note that users should ensure that log4j is configured to avoid
performance problems. (Bug 29973)
Revision ChangesPath
1.14 +6 -1 jakarta-commons/httpclient/xdocs/logging.xml
Index: logging.xml
===
RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/logging.xml,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- logging.xml 5 Jul 2004 20:47:53 - 1.13
+++ logging.xml 3 Aug 2004 04:11:09 - 1.14
@@ -142,6 +142,11 @@
log4j.logger.org.apache.commons.httpclient=DEBUG
+ Note that the default configuration for Log4J is very
+ inefficient as it causes all the logging information to be
+ generated but not actually sent anywhere. The Log4J manual is the
+ best reference for how to configure Log4J. It is available at http://logging.apache.org/log4j/docs/manual.html";>http://logging.apache.org/log4j/docs/manual.html
1.6 +32 -27jakarta-commons/httpclient/xdocs/tutorial.xml
Index: tutorial.xml
===
RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/tutorial.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- tutorial.xml 23 Feb 2004 23:05:43 - 1.5
+++ tutorial.xml 3 Aug 2004 04:11:09 - 1.6
@@ -207,39 +207,44 @@
// Create a method instance.
HttpMethod method = new GetMethod(url);
-
-// Execute the method.
-int statusCode = -1;
-// We will retry up to 3 times.
-for (int attempt = 0; statusCode == -1 && attempt < 3; attempt++) {
- try {
-// execute the method.
-statusCode = client.executeMethod(method);
- } catch (HttpRecoverableException e) {
-System.err.println(
- "A recoverable exception occurred, retrying." +
- e.getMessage());
- } catch (IOException e) {
-System.err.println("Failed to download file.");
-e.printStackTrace();
-System.exit(-1);
+
+try {
+ // Execute the method.
+ int statusCode = -1;
+ byte[] responseBody = null;
+ // We will retry up to 3 times.
+ for (int attempt = 0; statusCode == -1 && attempt < 3; attempt++) {
+try {
+ // execute the method.
+ statusCode = client.executeMethod(method);
+} catch (HttpRecoverableException e) {
+ System.err.println(
+"A recoverable exception occurred, retrying." +
+e.getMessage());
+} catch (IOException e) {
+ System.err.println("Failed to download file.");
+ e.printStackTrace();
+ System.exit(-1);
+}
+ }
+ // Check that we didn't run out of retries.
+ if (statusCode == -1) {
+System.err.println("Failed to recover from exception.");
+System.exit(-2);
}
-}
-// Check that we didn't run out of retries.
-if (statusCode == -1) {
- System.err.println("Failed to recover from exception.");
- System.exit(-2);
-}
-// Read the response body.
-byte[] responseBody = method.getResponseBody();
+ // Read the response body.
+ responseBody = method.getResponseBody();
-// Release the connection.
-method.releaseConnection();
+} finally {
+ // Release the connection.
+ method.releaseConnection();
+}
// Deal with the response.
// Use caution: ensure correct character encoding and is not binary data
System.err.println(new String(responseBody));
+
}
}
RE: [httpclient] commons-httpclient-2.0.jar - class not found: org\apache\commons\httpclient\HttpMethod
>Problem: I am getting a runtime error when posting an XML file >via HTTP POST to a servlet running on Tomcat 5.0.18 >Error: java.lang.NoClassDefFoundError: org\apache\commons\httpclient\HttpMethod Hi Diana, Don't put commons-logging on your boot classpath it does some funky stuff with class loaders and doesn't always work well. Generally speaking it's a bad idea to use the lib/ext folder for anything except overriding items already on the boot classpath (which is what that directory is for). Use the -classpath argument to java to specify the classpath to use. There is a whole heap of HttpClient documentation at http://jakarta.apache.org/commons/httpclient which covers most areas people have problems with. Regards, Adrian Sutton. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [httpclient] Handling Yahoo redirect...
Shame on me. I could have sworn we actually had a redirect example on that
page, but apparently we don't. It appears we don't actually have an example
atm though you might get lucky in the examples directory even though there's
no specific example for redirects:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/
I don't have time to do up a full example at the moment but the structure
will be:
int status = -1;
String url = "http://www.yahoo.com";;
while (status < 200 || status >= 300) {
// create method.
status = client.excute(method);
if (status == REDIRECT) { // check the redirects article for all the
redirect status codes
url = method.getResponseHeader("Location");
}
}
If that doesn't help give a yell on the HttpClient-dev list and someone
should be able to get a comprehensive example.
Regards,
Adrian Sutton, Software Engineer
Ephox Corporation
www.ephox.com
-Original Message-
From: Adrian Sutton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 29 October 2003 9:46 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [httpclient] Handling Yahoo redirect...
Hi Joe,
This question is best asked on the HttpClient-dev list as that's where all
the HttpClient developers hang out.
Fortunately, the answer is pretty simple - you want to take a look at the
documentation on our web page, specifically the "Cross hosts redirect guide"
at http://jakarta.apache.org/commons/httpclient/redirects.html
Regards,
Adrian Sutton, Software Engineer
Ephox Corporation
www.ephox.com
-Original Message-
From: Joe Ryburn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 29 October 2003 8:24 AM
To: [EMAIL PROTECTED]
Subject: Handling Yahoo redirect...
When loggin in to Yahoo mail, after a successful post of data the following
URL is returned...
http://login.yahoo.com/config/verify?.done=http%3a//my.yahoo.com
When I redirect the connection to that URL then I get the exception...
WARNING: Invalid Redirect URI from: http://login.yahoo.com:80/config/verify
to: http://my.yahoo.com
I understand I need to handle this manually, but I'm unsure how to proceed.
Anyone solved this before me?
Regards,
Joe Ryburn
Affiliated Foods Southwest
12103 Interstate 30
Little Rock, AR 72203-3627
501-455-3590 extension 6319
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [httpclient] Handling Yahoo redirect...
Hi Joe, This question is best asked on the HttpClient-dev list as that's where all the HttpClient developers hang out. Fortunately, the answer is pretty simple - you want to take a look at the documentation on our web page, specifically the "Cross hosts redirect guide" at http://jakarta.apache.org/commons/httpclient/redirects.html Regards, Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com -Original Message- From: Joe Ryburn [mailto:[EMAIL PROTECTED] Sent: Wednesday, 29 October 2003 8:24 AM To: [EMAIL PROTECTED] Subject: Handling Yahoo redirect... When loggin in to Yahoo mail, after a successful post of data the following URL is returned... http://login.yahoo.com/config/verify?.done=http%3a//my.yahoo.com When I redirect the connection to that URL then I get the exception... WARNING: Invalid Redirect URI from: http://login.yahoo.com:80/config/verify to: http://my.yahoo.com I understand I need to handle this manually, but I'm unsure how to proceed. Anyone solved this before me? Regards, Joe Ryburn Affiliated Foods Southwest 12103 Interstate 30 Little Rock, AR 72203-3627 501-455-3590 extension 6319 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [HttpClient] Freezes w/ MultiThreadedHttpConnectionManager
Hi Adam, This looks like a bug in VFS that I think has been mentioned on this list before - it doesn't always release the connection when it's done with it and as such, HttpClient reaches the limit for concurrent connections and sits waiting for an old one to be released. I would suggest trying the latest version of VFS straight out of CVS as I think they should have fixed this by now. Regards, Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com -Original Message- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: Friday, 10 October 2003 1:47 AM To: Jakarta Commons Developers List Subject: [HttpClient] Freezes w/ MultiThreadedHttpConnectionManager My single threaded user of VFS (an HttpClient user, that uses MultiThreadedHttpConnectionManager) hangs [I suspect indefinitely] on minor activity. I've turned on HttpClient debug and I see this, the last line being the last thing I get... 2003/10/09 09:34:26:482 MDT [DEBUG] wire - -<< "Content-Type: text/html[\r][\n]" 2003/10/09 09:34:26:482 MDT [DEBUG] HttpMethodBase - -Resorting to protocol version default close co nnection policy 2003/10/09 09:34:26:492 MDT [DEBUG] HttpMethodBase - -Should NOT close connection, using HTTP/1.1 2003/10/09 09:34:26:502 MDT [DEBUG] HttpMethodDirector - -Execute loop try 1 2003/10/09 09:34:26:512 MDT [DEBUG] MultiThreadedHttpConnectionManager - -HttpConnectionManager.getC onnection: config = HostConfiguration[host=www.ibiblio.org, protocol=http:80, port=80], timeout = 0 2003/10/09 09:34:26:522 MDT [DEBUG] MultiThreadedHttpConnectionManager - -Unable to get a connection , waiting..., hostConfig=HostConfiguration[host=www.ibiblio.org, protocol=http:80, port=80] I can send the full run logs if folks need/want. This is pretty reproducible. When I hack VFS not to use the MultiThreadedHttpConnectionManager I don't get the problem. I'll go find the bug tracking system (not sure why it isn't jumping out at me from the WWW site, but then -- nor are mailing lists, hence this -- maybe I need more coffee, or less sun glare before I look) . I'll enter a but report. FWIIW: I think I've noticed this for about a week, I only just found time to dig in. regards Adam - 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: [Convert] Mandate (draft)
>The system is Object->Object, though I suspect that 95% of converters will >be String->Object or Object->String. It would also be nice to have Object->primitive as well. Particularly when combined with the chaining you mention later on. You could convert Object->Integer, then Integer->int. Though the creation of an extra object may be a waste in some cases. Just something to think about. I'm very interested in this project btw, but have very little available time. Regards, Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [BeanUtils] Interesting Microbenchmarks
Please note that ASM is under the LGPL license which I believe is considered incompatible with the Apache license by the ASF. For your own entertainment etc it's fine to play with but it can't be made available through the ASF. Just my due diligence for the day - I'm sure ya'll are aware of it anyway. :) Regards, Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com -Original Message- From: Robert [mailto:[EMAIL PROTECTED] Sent: Monday, 6 October 2003 1:49 PM To: Jakarta Commons Developers List Subject: Re: [BeanUtils] Interesting Microbenchmarks Maybe the ASM main page says it all :-) Robert wrote: > I'll have to check that one out too. Any particular reason why you chose > ASM over BCEL? > > Chris Nokleberg wrote: > >> Robert wrote: >> >>> By 'generated', do you mean a runtime class generated (something like >>> BCEL for example), not source generation which is then compiled? >>> >>> The numbers are impressive regardless. >> >> >> >> Yes, everything in CGLIB uses the ASM bytecode manipulation library >> (http://asm.objectweb.org/) to dynamically generate classes at runtime. >> >> Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient NTCredentials.java
adrian 2003/08/15 17:41:24
Modified:httpclient/src/java/org/apache/commons/httpclient/auth
NTLMScheme.java NTLM.java
httpclient/xdocs authentication.xml
httpclient/src/java/org/apache/commons/httpclient
NTCredentials.java
Log:
Removed auto-configuration of JCE and updated documentation relating to NTLM.
PR: Bug 22073 and Bug 22424
Reviewed by: Oleg Kalnichevski and Michael Becke
Revision ChangesPath
1.11 +10 -8
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/auth/NTLMScheme.java
Index: NTLMScheme.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/auth/NTLMScheme.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- NTLMScheme.java 13 Aug 2003 19:57:10 - 1.10
+++ NTLMScheme.java 16 Aug 2003 00:41:24 - 1.11
@@ -68,10 +68,9 @@
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
-/**
- *
- * Microsoft proprietary NTLM authentication scheme.
- *
+/** An implementation of the Microsoft proprietary NTLM authentication scheme. For
a detailed
+ * explanation of the NTLM scheme please see http://davenport.sourceforge.net/ntlm.html";>
+ * http://davenport.sourceforge.net/ntlm.html.
*
* @author mailto:[EMAIL PROTECTED]">Remy Maucherat
* @author Rodney Waldhoff
@@ -154,7 +153,10 @@
/**
- * Returns authentication parameter with the given name, if available.
+ * Returns the authentication parameter with the given name, if available.
+ *
+ * There are no valid parameters for NTLM authentication so this method
always returns
+ * null.
*
* @param name The name of the parameter to be returned
*
1.4 +24 -39
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/auth/NTLM.java
Index: NTLM.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/auth/NTLM.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- NTLM.java 22 Jul 2003 18:10:25 - 1.3
+++ NTLM.java 16 Aug 2003 00:41:24 - 1.4
@@ -66,7 +66,6 @@
import java.io.UnsupportedEncodingException;
import java.security.InvalidKeyException;
import java.security.NoSuchAlgorithmException;
-import java.security.Security;
import javax.crypto.BadPaddingException;
import javax.crypto.Cipher;
@@ -88,6 +87,12 @@
* exists for it. This class is based upon the reverse engineering
* efforts of a wide range of people.
*
+ * Please note that an implementation of JCE must be correctly installed and
configured when
+ * using NTLM support.
+ *
+ * This class should not be used externally to HttpClient as it's API is
specifically
+ * designed to work with HttpClient's use case, in particular it's connection
management.
+ *
* @author mailto:[EMAIL PROTECTED]">Adrian Sutton
* @author mailto:[EMAIL PROTECTED]">Jeff Dever
* @author mailto:[EMAIL PROTECTED]">Mike Bowler
@@ -109,31 +114,6 @@
/** Character encoding */
public static final String DEFAULT_CHARSET = "ASCII";
-//Initialize the security provider
-static {
-//TODO: do not use System properties
-final String secProviderName
-= System.getProperty("httpclient.security.provider",
-"com.sun.crypto.provider.SunJCE");
-try {
-java.security.Provider secProvider = (java.security.Provider)
-Class.forName(secProviderName).newInstance();
-Security.addProvider(secProvider);
-} catch (ClassNotFoundException e) {
-LOG.error("Specified security provider " + secProviderName
-+ " could not be found by the class loader", e);
-} catch (ClassCastException e) {
-LOG.error("Specified security provider " + secProviderName
-+ " is not of type java.security.Provider", e);
-} catch (InstantiationException e) {
-LOG.error("Specified security provider " + secProviderName
-+ " could not be instantiated", e);
-} catch (IllegalAccessException e) {
-LOG.error("Specified security provider " + secProviderName
-+ " does not allow access to the constructor", e);
-}
-}
-
/**
* Returns the response for the given message.
*
@@ -278,10 +258,12 @@
cvs commit: jakarta-commons/httpclient/xdocs authentication.xml
adrian 2003/08/15 17:09:37
Modified:httpclient/src/java/org/apache/commons/httpclient Tag:
HTTPCLIENT_2_0_BRANCH NTLM.java NTCredentials.java
httpclient/src/java/org/apache/commons/httpclient/auth Tag:
HTTPCLIENT_2_0_BRANCH NTLMScheme.java
httpclient/xdocs Tag: HTTPCLIENT_2_0_BRANCH
authentication.xml
Log:
Removed auto-configuration of JCE and updated documentation relating to NTLM.
PR: Bug 22073 and Bug 22424
Reviewed by: Oleg Kalnichevski and Michael Becke
Revision ChangesPath
No revision
No revision
1.12.2.1 +24 -39
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/Attic/NTLM.java
Index: NTLM.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/Attic/NTLM.java,v
retrieving revision 1.12
retrieving revision 1.12.2.1
diff -u -r1.12 -r1.12.2.1
--- NTLM.java 11 Feb 2003 03:41:14 - 1.12
+++ NTLM.java 16 Aug 2003 00:09:37 - 1.12.2.1
@@ -66,7 +66,6 @@
import java.io.UnsupportedEncodingException;
import java.security.InvalidKeyException;
import java.security.NoSuchAlgorithmException;
-import java.security.Security;
import javax.crypto.BadPaddingException;
import javax.crypto.Cipher;
@@ -86,6 +85,12 @@
* protocol is a proprietary Microsoft protocol and as such no RFC
* exists for it. This class is based upon the reverse engineering
* efforts of a wide range of people.
+ *
+ * Please note that an implementation of JCE must be correctly installed and
configured when
+ * using NTLM support.
+ *
+ * This class should not be used externally to HttpClient as it's API is
specifically
+ * designed to work with HttpClient's use case, in particular it's connection
management.
*
* @deprecated this class will be made package access for 2.0beta2
*
@@ -110,31 +115,6 @@
/** Character encoding */
public static final String DEFAULT_CHARSET = "ASCII";
-//Initialize the security provider
-static {
-//TODO: do not use System properties
-final String secProviderName
-= System.getProperty("httpclient.security.provider",
-"com.sun.crypto.provider.SunJCE");
-try {
-java.security.Provider secProvider = (java.security.Provider)
-Class.forName(secProviderName).newInstance();
-Security.addProvider(secProvider);
-} catch (ClassNotFoundException e) {
-LOG.error("Specified security provider " + secProviderName
-+ " could not be found by the class loader", e);
-} catch (ClassCastException e) {
-LOG.error("Specified security provider " + secProviderName
-+ " is not of type java.security.Provider", e);
-} catch (InstantiationException e) {
-LOG.error("Specified security provider " + secProviderName
-+ " could not be instantiated", e);
-} catch (IllegalAccessException e) {
-LOG.error("Specified security provider " + secProviderName
-+ " does not allow access to the constructor", e);
-}
-}
-
/**
* Returns the response for the given message.
*
@@ -280,10 +260,12 @@
}
/**
- * TODO: Figure out what this method really does.
- * @param host The host
- * @param domain The domain
- * @return String
+ * Creates the first message (type 1 message) in the NTLM authentication
sequence.
+ * This message includes the user name, domain and host for the authentication
session.
+ *
+ * @param host the computer name of the host requesting authentication.
+ * @param domain The domain to authenticate with.
+ * @return String the message to add to the HTTP request header.
*/
private String getType1Message(String host, String domain) {
host = host.toUpperCase();
@@ -372,11 +354,14 @@
}
/**
- * Creates the type 3 message using the given server nonce.
- * @param user The user.
+ * Creates the type 3 message using the given server nonce. The type 3 message
includes all the
+ * information for authentication, host, domain, username and the result of
encrypting the
+ * nonce sent by the server using the user's password as the key.
+ *
+ * @param user The user name. This should not include the domain name.
* @param password The password.
- * @param host The host.
- * @param domain The domain.
+
cvs commit: jakarta-commons/httpclient/xdocs authentication.xml
adrian 2003/08/13 17:09:51 Modified:httpclient/xdocs authentication.xml Log: Added a note that the username should not be prefixed with the domain. Thanks to David Cowan for discovering the omission. Revision ChangesPath 1.7 +5 -2 jakarta-commons/httpclient/xdocs/authentication.xml Index: authentication.xml === RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/authentication.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- authentication.xml8 Aug 2003 07:59:53 - 1.6 +++ authentication.xml14 Aug 2003 00:09:51 - 1.7 @@ -106,7 +106,10 @@ NTLM authentication requires an instance of NTCredentials be available for the domain name of the server or the default credentials. Note that since NTLM does not use the notion of realms - HttpClient uses the domain name of the server as the name of the realm. + HttpClient uses the domain name of the server as the name of the realm. + Also note that the username provided to the NTCredentials should not + be prefixed with the domain - ie: "adrian" is correct whereas + "DOMAIN\adrian" is not correct. There are some significant differences in the way that NTLM works compared with basic and digest authentication. These differences - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/xdocs authentication.xml
adrian 2003/08/14 02:08:50 Modified:httpclient/xdocs Tag: HTTPCLIENT_2_0_BRANCH authentication.xml Log: Added note about having JCE on the classpath and using unqualified user names with NTLM authentication. Revision ChangesPath No revision No revision 1.5.2.1 +14 -4 jakarta-commons/httpclient/xdocs/authentication.xml Index: authentication.xml === RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/authentication.xml,v retrieving revision 1.5 retrieving revision 1.5.2.1 diff -u -r1.5 -r1.5.2.1 --- authentication.xml21 Jun 2003 08:25:47 - 1.5 +++ authentication.xml14 Aug 2003 09:08:50 - 1.5.2.1 @@ -106,7 +106,10 @@ NTLM authentication requires an instance of NTCredentials be available for the domain name of the server or the default credentials. Note that since NTLM does not use the notion of realms - HttpClient uses the domain name of the server as the name of the realm. + HttpClient uses the domain name of the server as the name of the realm. + Also note that the username provided to the NTCredentials should not + be prefixed with the domain - ie: "adrian" is correct whereas + "DOMAIN\adrian" is not correct. There are some significant differences in the way that NTLM works compared with basic and digest authentication. These differences @@ -151,8 +154,15 @@ of basic authentication available in the http://cvs.apache.org/viewcvs/jakarta-commons/httpclient/src/examples/";>example directory in CVS. - - + + + + Some authentication schemes may use cryptographic algorithms. It is recommended to include the + http://java.sun.com/products/jce/"; target="_blank">Java Cryptography Extension in + your runtime environment prior to JDK 1.4. + + + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] FastStringBuffer?
Chris, The overhead of uncontested synchronization is very small and in some cases is completely eliminated by the JITc. Before you worry about switching to an unsynchronized StringBuffer you should profile your code to make sure that doing so will actually help - when the StringBuffer is a local variable that's not passed to other methods, it almost certainly won't help. In some cases and on some JVMs it may make a difference though, only profiling can tell. Not that I'm against the idea... Regards, Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com -Original Message- From: Chris Feldhacker [mailto:[EMAIL PROTECTED] Sent: Thursday, 7 August 2003 1:30 PM To: Jakarta Commons Developers List Subject: [lang] FastStringBuffer? Maybe I'm missing something, or maybe this has been discussed before, but... Is there a replacement for StringBuffer someplace, perhaps a "FastStringBuffer" class? I only ask because StringBuffers are used everywhere, even internally by the JVM. However, all of the methods on the StringBuffer class are synchronized. In my experience (and in looking through most of the lang code), 99% of the time StringBuffer is only used as a method variable to compose a message String; therefore, it is not possible for multiple threads to access the same StringBuffer. So, why not eliminate the synchronized method calls and increase performance? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [codec] Update dependencies.html with Java req, and more.
>But, who is allowed to use this binary? We expect contributors to submit >patches with good JUnit tests, why not expect people to submit code with a >good amount of coverage? This has happened before, a valuable contributor >wants to make a somewhat large change, and they want to use to see how >much code is covered by the unit tests. Just for the record, a 30 day trial clover jar is included on the maven repository, but it doesn't seem to ever actually time out. So I would say the question is more - can non-committers use this 30 day trial jar after the 30 day period if they are working on a project that has a license? Ethically I'd say it's okay, but law doesn't always follow ethics. :) Hope that helps, Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/examples BasicAuthenticatonExample.java
adrian 2003/07/15 16:37:48
Modified:httpclient/src/examples BasicAuthenticatonExample.java
Log:
Fixed arguments to setCredential to be realm, host, creds instead of host, realm,
creds.
Revision ChangesPath
1.5 +7 -6
jakarta-commons/httpclient/src/examples/BasicAuthenticatonExample.java
Index: BasicAuthenticatonExample.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/examples/BasicAuthenticatonExample.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- BasicAuthenticatonExample.java7 Apr 2003 19:23:35 - 1.4
+++ BasicAuthenticatonExample.java15 Jul 2003 23:37:48 - 1.5
@@ -83,11 +83,12 @@
HttpClient client = new HttpClient();
// pass our credentials to HttpClient, they will only be used for
-// authenticating to servers with realm "realm", to authenticate agains
-// an arbitrary realm change this to null.
+// authenticating to servers with realm "realm" on the host
+// "www.verisign.com", to authenticate against
+// an arbitrary realm or host change the appropriate argument to null.
client.getState().setCredentials(
-"www.verisign.com",
"realm",
+"www.verisign.com",
new UsernamePasswordCredentials("username", "password")
);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/auth HttpAuthenticator.java
adrian 2003/07/15 16:35:06
Modified:httpclient/src/java/org/apache/commons/httpclient/auth
HttpAuthenticator.java
Log:
Minor chnage to debug message to include a space between the auth name and the end
of the sentence.
Revision ChangesPath
1.9 +4 -4
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/auth/HttpAuthenticator.java
Index: HttpAuthenticator.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/auth/HttpAuthenticator.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- HttpAuthenticator.java13 Jul 2003 13:54:51 - 1.8
+++ HttpAuthenticator.java15 Jul 2003 23:35:06 - 1.9
@@ -314,7 +314,7 @@
if (credentials == null) {
throw new AuthenticationException(
"No credentials available for the " + authscheme.getSchemeName()
-+ "authentication realm '" + realm + "'");
++ " authentication realm '" + realm + "'");
}
String auth = authscheme.authenticate(credentials, method.getName(),
method.getPath());
if (auth != null) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient HttpMethodBase.java
adrian 2003/06/27 18:38:43 Modified:httpclient/src/java/org/apache/commons/httpclient HttpMethodBase.java Log: Changed HttpMethodBase to initialize its Log object with HttpMethodBase.class instead of HttpMethod.class. PR: Bug 21159 Submitted by: Laura Werner Reviewed by: Adrian Sutton Revision ChangesPath 1.158 +5 -5 jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java Index: HttpMethodBase.java === RCS file: /home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java,v retrieving revision 1.157 retrieving revision 1.158 diff -u -r1.157 -r1.158 --- HttpMethodBase.java 27 Jun 2003 21:17:36 - 1.157 +++ HttpMethodBase.java 28 Jun 2003 01:38:43 - 1.158 @@ -147,7 +147,7 @@ // -- Constants /** Log object for this class. */ -private static final Log LOG = LogFactory.getLog(HttpMethod.class); +private static final Log LOG = LogFactory.getLog(HttpMethodBase.class); /** The User-Agent header sent on every request. */ protected static final Header USER_AGENT; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/methods/multipart ContentType.java ContentTypeFilePart.java
adrian 2003/06/26 03:27:56
Added:
httpclient/src/contrib/org/apache/commons/httpclient/contrib/methods/multipart
ContentType.java ContentTypeFilePart.java
Log:
Added classes for detecting the content type.
PR: Bug 20986
Submitted by: Eric Devlin with modifications from Adrian Sutton
Revision ChangesPath
1.1
jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/methods/multipart/ContentType.java
Index: ContentType.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2002-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Commons", and "Apache Software
*Foundation" must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "Apache"
*nor may "Apache" appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* <http://www.apache.org/>;.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.commons.httpclient.contrib.methods.multipart;
import java.io.File;
/**
* This class provides mappings from file name extensions to content types.
*
* @author mailto:[EMAIL PROTECTED]">Eric Devlin
* @author mailto:[EMAIL PROTECTED]">Adrian Sutton
*
* @version $Revision: 1.1 $
*
* DISCLAIMER: HttpClient developers DO NOT actively support this component.
* The component is provided as a reference material, which may be inappropriate
* to be used without additional customization.
*/
public final class ContentType {
/** Mime Type mappings 'liberated' from Tomcat4.1.18/conf/web.xml*/
public static final String[][] MIME_TYPE_MAPPINGS = { { "abs", "audio/x-mpeg" },
{
"ai", "application/postscript" }, {
"aif", "audio/x-aiff" }, {
"aifc", "audio/x-aiff" }, {
"aiff", "audio/x-aiff" }, {
"aim", "application/x-aim" }, {
"art", "image/x-jg" }, {
"asf", "video/x-ms-asf" }, {
"asx", "video/x-ms-asf" }, {
"au", "audio/basic" }, {
"avi", "video/x-msvideo" }, {
"avx",
cvs commit: jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/methods/multipart - New directory
adrian 2003/06/26 03:25:56 jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/methods/multipart - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/methods - New directory
adrian 2003/06/26 03:25:56 jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/methods - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/auth NTLMScheme.java
adrian 2003/06/21 04:15:47
Modified:httpclient/src/java/org/apache/commons/httpclient/auth
NTLMScheme.java
Log:
Fixed error message to report as NTLM authentication instead of basic.
CVS: --
CVS: PR:
CVS: If this change addresses a PR in the problem report tracking
CVS: database, then enter the PR number(s) here.
CVS: Obtained from:
CVS: If this change has been taken from another system, such as NCSA,
CVS: then name the system in this line, otherwise delete it.
CVS: Submitted by:
CVS: If this code has been contributed to Apache by someone else; i.e.,
CVS: they sent us a patch or a new module, then include their name/email
CVS: address here. If this is your work then delete this line.
CVS: Reviewed by:
CVS: If we are doing pre-commit code reviews and someone else has
CVS: reviewed your changes, include their name(s) here.
CVS: If you have not had it reviewed then delete this line.
Revision ChangesPath
1.6 +4 -4
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/auth/NTLMScheme.java
Index: NTLMScheme.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/auth/NTLMScheme.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- NTLMScheme.java 26 May 2003 22:07:22 - 1.5
+++ NTLMScheme.java 21 Jun 2003 11:15:47 - 1.6
@@ -222,7 +222,7 @@
ntcredentials = (NTCredentials) credentials;
} catch (ClassCastException e) {
throw new AuthenticationException(
- "Credentials cannot be used for basic authentication: "
+ "Credentials cannot be used for NTLM authentication: "
+ credentials.toString());
}
return NTLMScheme.authenticate(ntcredentials, this.ntlmchallenge);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/xdocs authentication.xml
adrian 2003/06/21 01:25:47 Modified:httpclient/xdocs authentication.xml Log: Added link to detailed NTLM documentation. Obtained from: Eric Glass CVS: -- CVS: PR: CVS: If this change addresses a PR in the problem report tracking CVS: database, then enter the PR number(s) here. CVS: Obtained from: CVS: If this change has been taken from another system, such as NCSA, CVS: then name the system in this line, otherwise delete it. CVS: Submitted by: CVS: If this code has been contributed to Apache by someone else; i.e., CVS: they sent us a patch or a new module, then include their name/email CVS: address here. If this is your work then delete this line. CVS: Reviewed by: CVS: If we are doing pre-commit code reviews and someone else has CVS: reviewed your changes, include their name(s) here. CVS: If you have not had it reviewed then delete this line. Revision ChangesPath 1.5 +5 -1 jakarta-commons/httpclient/xdocs/authentication.xml Index: authentication.xml === RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/authentication.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- authentication.xml4 Jun 2003 02:28:14 - 1.4 +++ authentication.xml21 Jun 2003 08:25:47 - 1.5 @@ -139,6 +139,10 @@ support HTTP keep-alives. + + For a detailed explanation of how NTLM authentication works, please see + http://davenport.sourceforge.net/ntlm.html";> + http://davenport.sourceforge.net/ntlm.html. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestResponseHeaders.java
adrian 2003/06/20 06:33:09
Modified:httpclient/src/test/org/apache/commons/httpclient
TestResponseHeaders.java
Log:
Test cases for the fix to bug 20938.
PR: bug 20938
Reviewed by: Michael Becke and Oleg Kalnichevski
CVS: --
CVS: PR:
CVS: If this change addresses a PR in the problem report tracking
CVS: database, then enter the PR number(s) here.
CVS: Obtained from:
CVS: If this change has been taken from another system, such as NCSA,
CVS: then name the system in this line, otherwise delete it.
CVS: Submitted by:
CVS: If this code has been contributed to Apache by someone else; i.e.,
CVS: they sent us a patch or a new module, then include their name/email
CVS: address here. If this is your work then delete this line.
CVS: Reviewed by:
CVS: If we are doing pre-commit code reviews and someone else has
CVS: reviewed your changes, include their name(s) here.
CVS: If you have not had it reviewed then delete this line.
Revision ChangesPath
1.8 +67 -4
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestResponseHeaders.java
Index: TestResponseHeaders.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestResponseHeaders.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- TestResponseHeaders.java 10 Jun 2003 22:42:52 - 1.7
+++ TestResponseHeaders.java 20 Jun 2003 13:33:09 - 1.8
@@ -73,6 +73,7 @@
*
* @author mailto:[EMAIL PROTECTED]">Davanum Srinivas
* @author mailto:[EMAIL PROTECTED]">Jeff Dever
+ * @author mailto:[EMAIL PROTECTED]">Adrian Sutton
* @version $Id$
*/
public class TestResponseHeaders extends TestCase {
@@ -153,6 +154,7 @@
"HTTP/1.1 200 OK\r\n"
+ "proxy-connection: close\r\n"
+ "proxy-connection: close\r\n"
++ "Content-Length: 0\r\n"
+ "\r\n";
conn.addResponse(headers, "");
@@ -169,6 +171,7 @@
"HTTP/1.0 200 OK\r\n"
+ "proxy-connection: keep-alive\r\n"
+ "proxy-connection: keep-alive\r\n"
++ "Content-Length: 0\r\n"
+ "\r\n";
conn.addResponse(headers, "");
@@ -202,6 +205,7 @@
"HTTP/1.0 200 OK\r\n"
+"Connection: keep-alive\r\n"
+"Connection: keep-alive\r\n"
++ "Content-Length: 0\r\n"
+"\r\n";
conn.addResponse(headers, "");
@@ -210,6 +214,65 @@
method.getResponseBodyAsString();
assertTrue(conn.isOpen());
+}
+
+public void testNoContentLength() throws Exception {
+// test with connection header
+SimpleHttpConnection conn = new SimpleHttpConnection();
+String headers =
+"HTTP/1.1 200 OK\r\n"
++ "Connection: keep-alive\r\n"
++ "\r\n";
+
+conn.addResponse(headers, "12345");
+GetMethod method = new GetMethod("/");
+method.execute(new HttpState(), conn);
+method.getResponseBodyAsString();
+
+assertFalse(conn.isOpen());
+
+// test without connection header
+conn = new SimpleHttpConnection();
+headers = "HTTP/1.1 200 OK\r\n\r\n";
+
+// test with connection header
+conn.addResponse(headers, "12345");
+method = new GetMethod("/");
+method.execute(new HttpState(), conn);
+method.getResponseBodyAsString();
+
+assertFalse(conn.isOpen());
+}
+
+public void testProxyNoContentLength() throws Exception {
+// test with proxy-connection header
+SimpleHttpConnection conn = new SimpleHttpConnection();
+String headers =
+"HTTP/1.1 200 OK\r\n"
++ "proxy-connection: keep-alive\r\n"
++ "\r\n";
+
+conn.addResponse(headers, "12345");
+conn.setProxyHost("proxy");
+conn.setProxyPort(1);
+GetMethod method = new GetMethod("/");
+method.execute(new HttpState(), conn);
+method.getResponseBodyAsString();
+
+assertFalse(conn.isOpen());
+
+// test without proxy-connection header
+conn = new SimpleHttpConnection();
+
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient HttpMethodBase.java
adrian 2003/06/20 06:30:02
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpMethodBase.java
Log:
Avoids a SocketException being thrown when the Content-Length header is missing.
PR: bug 20938
Reviewed by: Michael Becke and Oleg Kalnichevski
CVS: --
CVS: PR:
CVS: If this change addresses a PR in the problem report tracking
CVS: database, then enter the PR number(s) here.
CVS: Obtained from:
CVS: If this change has been taken from another system, such as NCSA,
CVS: then name the system in this line, otherwise delete it.
CVS: Submitted by:
CVS: If this code has been contributed to Apache by someone else; i.e.,
CVS: they sent us a patch or a new module, then include their name/email
CVS: address here. If this is your work then delete this line.
CVS: Reviewed by:
CVS: If we are doing pre-commit code reviews and someone else has
CVS: reviewed your changes, include their name(s) here.
CVS: If you have not had it reviewed then delete this line.
Revision ChangesPath
1.153 +12 -4
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java
Index: HttpMethodBase.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java,v
retrieving revision 1.152
retrieving revision 1.153
diff -u -r1.152 -r1.153
--- HttpMethodBase.java 13 Jun 2003 21:32:17 - 1.152
+++ HttpMethodBase.java 20 Jun 2003 13:30:02 - 1.153
@@ -880,6 +880,14 @@
*/
protected boolean shouldCloseConnection(HttpConnection conn) {
+// if we are not chunked and there is no content length the connection
+// cannot be reused
+if (responseHeaders.getFirstHeader("Transfer-Encoding") == null
+&& getResponseContentLength() < 0) {
+LOG.debug("Should close connection as content-length is missing.");
+return true;
+}
+
Header connectionHeader = null;
// In case being connected via a proxy server
if (!conn.isTransparent()) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] Clover licenses
Tim, Robert et al, I agree, it would be ideal if we had a commons wide or jakarta wide license. Everyone seems to be pointing to Robert as the person to talk to about it. Since Robert's suggested to talk to community or the jakarta pmc I'll head off in their direction and report back on my findings. Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com -Original Message- From: Tim O'Brien [mailto:[EMAIL PROTECTED] Sent: Wednesday, 18 June 2003 7:49 AM To: Jakarta Commons Developers List Subject: Re: [general] Clover licenses I have commons-math and commons-codec clover licenses which are available to any commons committer who asks, and are housed on apache infrastructure. I think it would be cleaner from a legal standpoint if someone like Robert asked for a commons-wide license, or better yet if the PMC asked for a Jakarta-wide clover license. Tim On Tue, 17 Jun 2003, robert burrell donkin wrote: > IIRC it was one of those threads that died down without any real > conclusion. you could try asking on community or asking the jakarta pmc. > > - robert > > On Tuesday, June 17, 2003, at 10:25 AM, Adrian Sutton wrote: > > > Hi all, > > The HttpClient team is looking to set up clover to get test coverage > > reports. I recall a discussion about what the procedure is for Apache > > projects to request a clover license but haven't been able to find the > > resolution of that discussion. > > > > Does anyone know what the correct procedure is for requesting a license > > (ie: > > do we need to go through the PMC?) or whether the jakarta project has a > > license that HttpClient can just use? > > > > Any help would be appreciated. > > > > Thanks, > > > > Adrian Sutton. > > > > > > - > > 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] > > > -- -- Tim O'Brien Evanston, IL (847) 863-7045 [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]
[general] Clover licenses
Hi all, The HttpClient team is looking to set up clover to get test coverage reports. I recall a discussion about what the procedure is for Apache projects to request a clover license but haven't been able to find the resolution of that discussion. Does anyone know what the correct procedure is for requesting a license (ie: do we need to go through the PMC?) or whether the jakarta project has a license that HttpClient can just use? Any help would be appreciated. Thanks, Adrian Sutton. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/xdocs sslguide.xml
adrian 2003/06/12 15:24:21 Modified:httpclient/xdocs sslguide.xml Log: Minor clean-ups and rewording for clarity. Contributed by Adrian Sutton Reviewed by Oleg Kalnichevski Revision ChangesPath 1.2 +127 -105 jakarta-commons/httpclient/xdocs/sslguide.xml Index: sslguide.xml === RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/sslguide.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- sslguide.xml 12 Jun 2003 03:31:50 - 1.1 +++ sslguide.xml 12 Jun 2003 22:24:21 - 1.2 @@ -5,6 +5,7 @@ HttpClient SSL Guide Oleg Kalnichevski +Adrian Sutton $Id$ @@ -16,7 +17,7 @@ HttpClient provides full support for HTTP over Secure Sockets Layer (SSL) or IETF Transport Layer Security (TLS) protocols by leveraging the http://java.sun.com/products/jsse/index.html";> Java Secure Socket Extension (JSSE). JSSE has been integrated into the Java 2 platform as of - version 1.4 and usually should work with HttpClient out of the box. On older Java 2 versions JSSE + version 1.4 and works with HttpClient out of the box. On older Java 2 versions JSSE needs to be manually installed and configured. Installation instructions can be found http://java.sun.com/products/jsse/doc/guide/API_users_guide.html#Installation";>here @@ -25,7 +26,7 @@ -With SSL properly set up and configured, secure HTTP communication over SSL should be as simple +Once you have JSSE correctly installed, secure HTTP communication over SSL should be as simple as plain HTTP communication. - + + The new instance of protocol can then be set as the protocol handler + for a HostConfiguration. For example to configure the default host and + protocol handler for a HttpClient instance use: + - -The resultant protocol object then can be used as a default protocol for a host. - + - + - + + +Finally, you can register your custom protocol as the default handler +for a specific protocol designator (eg: https) by calling the +Protocol.registerProtocol method. You can specify your own protocol +designator (such as 'myhttps') if you need to use your custom +protocol as well as the default SSL protocol implementation. + - - - Optionally register the custom protocol by calling Protocol.registerProtocol method. You can - specify your own protocol designator (such as 'myhttps') if you are going to be using this protocol - along with the default SSL protocol implementation. - + - + +Once registered the protocol be used as a 'virtual' scheme inside target URIs. + - - Once registered the protocol be used as a 'virtual' scheme inside target URIs. - + - + + If you want this protocol to represent the default SSL protocol implementation, simply register + it under 'https' designator, which will make the protocol object take place of the existing one + - - If you want this protocol to represent the default SSL protocol implementation, simply register - it under 'https' designator, which will make the protocol object take place of the existing one - - - + - + - + - + - - - - There are several custom socket factories available in our contribution package. They can - be a good start for those who seek to tailor the behavior of the HTTPS protocol to the specific - needs of their application: - + + + + There are several custom socket factories available in our contribution + package. They can be a good start for those who seek to tailor the + behavior of the HTTPS protocol to the specific needs of their + application: + - + http://cvs.apache.org/viewcvs/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/EasySSLProtocolSocketFactory.java?rev=HEAD";> @@ -185,19 +201,20 @@ Due to what appears to be a bug in Sun's older (below 1.4) implementation of Java Virtual Machines or JSSE there's no reliable way of telling if an SSL connection is 'stale' or not.
cvs commit: jakarta-commons/httpclient project.xml
adrian 2003/06/11 21:35:11 Modified:httpclient project.xml Log: Moved Adrian Sutton to be a committer instead of a contributor. Revision ChangesPath 1.34 +9 -5 jakarta-commons/httpclient/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/httpclient/project.xml,v retrieving revision 1.33 retrieving revision 1.34 diff -u -r1.33 -r1.34 --- project.xml 4 Jun 2003 06:16:29 - 1.33 +++ project.xml 12 Jun 2003 04:35:11 - 1.34 @@ -142,6 +142,14 @@ + Adrian Sutton + [EMAIL PROTECTED] + Intencha + +Java Developer + + + Rodney Waldhoff rwaldhoff [EMAIL PROTECTED] @@ -186,10 +194,6 @@ [EMAIL PROTECTED] - Adrian Sutton - [EMAIL PROTECTED] - - Laura Werner [EMAIL PROTECTED] @@ -206,7 +210,7 @@ 1.0.2 http://jakarta.apache.org/commons/logging.html - + [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: help - multiple location of commons releases
>A version of Apple's tar had some kind of bug. I'm not sure if that's >still there. The main problem with OS X is that the default [and only >reasonable] filing system is case insensitive [windows has this problem >though], and more painfully, the default unzipper stuffit likes to chop >filenames off at a certain length. But these are the same problems for >tag.gz and zip. Actually, Apple doesn't really have it's own version of tar, it shipped the same tar that comes with Solaris and gnutar (the one that handles long filenames) installed as gnutar. The standard tar now reports itself as GNU tar on 10.2.4 so I imagine that it was changed around either 10.1 or 10.2. You'll most likely find that a lot of solaris boxes still don't have gnutar and so they also suffer from the truncated filename problem that OS X did as well (though checking our Solaris 8 box here it has GNU tar, not sure if we installed that or not though). As for StuffIt, earlier versions chopped filenames off, however this was fixed quite some time ago as well and you are correct that it affected both tar.gz and zip. As for case insensitive file systems, you'll find that that's a very common problem so you should never name two files the same thing differing only by case - at the very least it confuses users. You'll also note that there are actually three types of file systems with regards to case: 1. Case sesitive (Linux, Solaris, most UNIX's) 2. Case insensitive (DOS and perhaps early versions of Windows) 3. Case preserving (Mac and more recent versions of Windows) Case preserving is case insensitive for finding a file but case sensitive for creating a new file, hence if I create a file on a mac called "File" I can refer to it as either "File" or "file" but if I transfer it to a Linux box it will always come across as "File". If the same was done with a DOS file system it would come across to the Linux box as "FILE". As for what to distribute as: * make sure the .zip file stays as .tar.gz still isn't particularly common on Windows * make very sure you assume case sensitivity when referring to files but never have two files of the same name with different case * try to keep the file names under 32 characters if possible (the maximum file length on Mac OS 8 and below). Of course, if you're using anything above Java 1.1 it won't run on OS 8 or 9 anyway. I've been working with Macs, Windows and Linux for many years now and that advise seems to get me through nearly every situation pretty happily. Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] MethodUtils [WAS Re: [beanutils][lang][PROPOSAL] deprecated beanutils version of MethodUtils]
>static {
>if (System.getProperty("org.apache.commons.lang.Debug") != null) {
> debugLogging = true;
>}
>}
>
>If it's useful for us, it might be useful for other developers.
Careful, this would throw a SecurityException when used in an unsigned
applet or webstart app. It also has the disadvantage of not being optimised
out by the compiler as would be the case with an 'if (DEBUG)' where DEBUG is
static final DEBUG = true/false.
Just something to keep in mind
Adrian Sutton, Software Engineer
Ephox Corporation
www.ephox.com
This email and any files transmitted with it are confidential and intended
solely for the use of the individual to whom they are addressed. Opinions
contained in this email do not necessarily reflect the opinions of Ephox
Corporation.
If you have received this email in error please notify the sender
immediately and delete all copies of the correspondence from your computer
and/or computer network. No warranty is given that this message upon its
receipt is virus free and the sender in this respect accepts no liability.
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
RE: cvs commit: jakarta-commons/httpclient project.xml
Noticed this come through the cvs commits - thanks for the recogition. Could I be picky and request that an Organisation tag be added akin to: Ephox Since they're paying me to do the work I figure they should get a mention. :) Thanks. Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com This email and any files transmitted with it are confidential and intended solely for the use of the individual to whom they are addressed. Opinions contained in this email do not necessarily reflect the opinions of Ephox Corporation. If you have received this email in error please notify the sender immediately and delete all copies of the correspondence from your computer and/or computer network. No warranty is given that this message upon its receipt is virus free and the sender in this respect accepts no liability. -Original Message- From: [EMAIL PROTECTED] [mailto:jsdever@;apache.org] Sent: Thursday, 31 October 2002 6:37 PM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-commons/httpclient project.xml jsdever 2002/10/31 00:37:03 Modified:httpclient project.xml Log: Update the contributors and committer. Update the dependancy of commons-logging 1.0.2 Revision ChangesPath 1.8 +19 -4 jakarta-commons/httpclient/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/httpclient/project.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- project.xml 8 Sep 2002 05:51:42 - 1.7 +++ project.xml 31 Oct 2002 08:37:03 - 1.8 @@ -10,7 +10,7 @@ Commons HttpClient -Embeddable Http Client +Embeddable HTTP Client @@ -56,16 +56,31 @@ Independent consultant Java Developer - + + + Sung-Gu + jericho + jericho_at_pache_org + + Java Developer + + Ryan Lubke [EMAIL PROTECTED] + + + Adrian Sutton + adrian.sutton_at_ephox_com + + + @@ -76,11 +91,11 @@ commons-logging - 1.0.1 + 1.0.2 - + -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
RE: What should we do about sandbox ? RE: License and copyright issues
>I would propose to ask the sandbox to be removed from viewcvs >and the eventually discuss what to do about the public cvs. >As a way to protect ourself. I wouldn't mind if this is voted >down :-) > >What do you think about this issue ? Any other proposed solutions ? As a non-committer, I'd have to be very strongly against closing the sandbox CVS repository unless it was definitely a legal requirement. I say this not so much because I wouldn't have access (I don't currently use anything from sandbox) but because it would be a limiting factor on the community development for sandbox projects. There seems to be the feeling that community == committers around the ASF but I definitely think there is more to it than that (what's the ratio of committers to non-committers on this list for instance?). I think it is also important to present a welcoming face to new comers so that they stay around and contribute (possibly becomming committers in time). Closing things off creates the impression that ASF is an elite club rather than an open collaboration. Of course, this is all completely irrelevant if sandbox has to be kept closed for legal reasons, but it is probably worth keeping in mind. Yours, Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com This email and any files transmitted with it are confidential and intended solely for the use of the individual to whom they are addressed. Opinions contained in this email do not necessarily reflect the opinions of Ephox Corporation. If you have received this email in error please notify the sender immediately and delete all copies of the correspondence from your computer and/or computer network. No warranty is given that this message upon its receipt is virus free and the sender in this respect accepts no liability. -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
[httpclient] Reused connection is not fully read before reuse with NTLM
I've found a problem with the integration of NTLM into HttpClient that I'd
appreciate some advice on how to solve.
The problem is that NTLM (unlike any other authentication process) requires
the same connection to be used both to receive the challenge and to respond.
In basic and digest authentication the connection is closed when an
unauthorized response is recieved, but with NTLM it's kept open. This would
work quite well except that when an unauthorized message is received, the
body of the response isn't read.
Now, the question that lingers in my mind is where we should put the fix.
We could change the currently empty processResponseBody(HttpState state,
HttpConnection conn) in HttpMethodBase to:
protected void processResponseBody(HttpState state, HttpConnection conn) {
log.trace("enter processResponseBody(HttpState state, HttpConnection
conn)");
getResponseBody();
}
Alternatively, this call could be added to readResponseBody so that it
actually works as advertised.
which would ensure that the body of the message is always read and thus
ensure that this problem doesn't crop up again in the future (I'm not sure I
can think of any other place this would pop up though), the downside of that
is the waste of memory, time and bandwidth if the connection would have been
closed anyway.
The other option is to add a call to getResponseBody() in the Authenticator
class when NTLM authentication is used. That seems somewhat out of place
for this kind of thing though and any other authentication scheme that
leaves connections open would have problems.
It's worth noting that if GetMethod is set to use disk, it will buffer the
response to disk and everything will work correctly.
Any preferences/other options?
Adrian Sutton.
I've included a full trace to show what's happening below but let me extract
just the key lines here first so you don't get too lost in it all.
[DEBUG] wire - ->> "GET /DAV/test%20dir/help.gif HTTP/1.1
" [\r\n]
...
[DEBUG] wire - ->> "Authorization: NTLM
TlRMTVNTUAABBlIsDAAMACAxOTIuMTY4LjAuNDM=
" [\r\n] <-- This is message 1 of NTLM authentication. The connection must
be kept alive from here in.
...
This is the section where the bug actually lies. Despite readResponseBody
being called, the body is never read but instead the InputStream is just
stored for later. This means that later when we try to read from the stream
again, we get the body of this response before the start of the next
response.
[DEBUG] wire - -<< "HTTP/1.1 401 Access Denied" [\r\n]
[TRACE] HttpMethod - -enter
HttpMethodBase.readResponseHeaders(HttpState,HttpConnection)
[TRACE] HttpConnection - -enter HttpConnection.readLine()
[DEBUG] wire - -<< "Server: Microsoft-IIS/5.0" [\r\n]
[TRACE] HttpConnection - -enter HttpConnection.readLine()
[DEBUG] wire - -<< "Date: Wed, 02 Oct 2002 04:34:14 GMT" [\r\n]
[TRACE] HttpConnection - -enter HttpConnection.readLine()
[DEBUG] wire - -<< "WWW-Authenticate: NTLM
TlRMTVNTUAACCgAKADAGAoEATXpvbJTDtnYAAJ4AngA6SU5UUkFFUEhP
WAIAFABJAE4AVABSAEEARQBQAEgATwBYAAEAEgBCAE8AQQBSAEQAUgBPAE8ATQAEACgAaQBuAHQA
cgBhAGUAcABoAG8AeAAuAGUAcABoAG8AeAAuAGMAbwBtAAMAPABCAG8AYQByAGQAcgBvAG8AbQAu
AGkAbgB0AHIAYQBlAHAAaABvAHgALgBlAHAAaABvAHgALgBjAG8AbQAA" [\r\n]
[TRACE] HttpConnection - -enter HttpConnection.readLine()
[DEBUG] wire - -<< "Content-Length: 20" [\r\n]
[TRACE] HttpConnection - -enter HttpConnection.readLine()
[DEBUG] wire - -<< "Content-Type: text/html" [\r\n]
[TRACE] HttpConnection - -enter HttpConnection.readLine()
[TRACE] HttpMethod - -enter HttpMethodBase.processResponseHeaders(HttpState,
HttpConnection)
[TRACE] GetMethod - -enter GetMethod.readResponseBody(HttpState,
HttpConnection)
[TRACE] HttpMethod - -enter HttpMethodBase.readResponseBody(HttpState,
HttpConnection)
[TRACE] HttpMethod - -enter HttpMethodBase.readResponseBody(HttpState,
HttpConnection)
[TRACE] HttpConnection - -enter
HttpConnection.getResponseInputStream(HttpMethod)
[TRACE] HttpMethod - -enter writeRemainingRequestBody(HttpState,
HttpConnection)
[DEBUG] HttpMethod - -Authorization required
[TRACE] HttpMethod - -enter
HttpMethodBase.processAuthenticationResponse(HttpState, HttpConnection)
Note below how the last line of the previous response is prepended to the
first line of the next, thus causing readStatusLine to discard the line (in
an attempt to avoid processing the end of the previous response). However,
it will never find another status line because it just missed it.
[TRACE] HttpMethod - -enter HttpMethodBase.readStatusLine(HttpState,
HttpConnection)
[TRACE] HttpConnection - -enter HttpConnection.readLine()
[DEBUG] wire - -<< "HomeHTTP/1.1 200 OK" [\r\n]
[DEBUG] wire - -<<
"GIF89aAiii???III?AAA??
Re: [GUMP][httpclient] Build Failure - commons-httpclient
>I didn't see that before I checked in your patch. In general it is a bad idea to use >the com.sun packages directly. Can you do this more >genericly? I don't believe so though I'm not an expert on JCE so I'd love to hear corrections if I'm wrong about that. The best option that I can see is to rip out that static section altogether and require the user to load the JCE library they wish to use before calling into HttpClient. That way the user can decide which crypto package they want to use. As far as I know though, there is no way to autodetect crypto packages and they must be manually loaded as the line in question is doing. I'm at home for the weekend (it's Saturday morning here) so can I leave you to make this change as supplying a patch from me probably won't be possible until Monday. Adrian Sutton Software Engineer Ephox Corporation -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
RE: [HttpClient] Method to determine required credential type
>Is there a case for returning a class object, as opposed to just returning >"Basic", "Digest" or "NTLM" (or null). Not a particularly good one. It would be useful to know the actual class required for when pluggable authentication modules come in, but there isn't much chance of being able to provide the required information if you didn't specifically add support for it anyway (ie: just knowing the class required isn't enough, you also need to know the required parameters for it's constructor etc). With that in mind, it probably would be best just to return the name of the authentication type being used. Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com This email and any files transmitted with it are confidential and intended solely for the use of the individual to whom they are addressed. Opinions contained in this email do not necessarily reflect the opinions of Ephox Corporation. If you have received this email in error please notify the sender immediately and delete all copies of the correspondence from your computer and/or computer network. No warranty is given that this message upon its receipt is virus free and the sender in this respect accepts no liability. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
RE: [HttpClient][PATCH] Basic Authentication does not use default credentials
>This test shows that basic authenticaiton uses the default creds (the creds with >the null realm in the httpstate). I'm not sure what your patch is trying to fix >... can you supply a test case that fails with the current code, but passes >after your patch is applied? I could have sworn that exact test case was failing for me yesterday. You are indeed right it does pass for me today. I must have had a versioning conflict somewhere or something else weird (I'm playing with the version of HttpClient in Slide as well). My apologies for the false alarm. Yours, Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com This email and any files transmitted with it are confidential and intended solely for the use of the individual to whom they are addressed. Opinions contained in this email do not necessarily reflect the opinions of Ephox Corporation. If you have received this email in error please notify the sender immediately and delete all copies of the correspondence from your computer and/or computer network. No warranty is given that this message upon its receipt is virus free and the sender in this respect accepts no liability. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
RE: [HttpClient] Method to determine required credential type
>Would people agree to adding a method that returns the Class required for >authentication? I'd suggest it should go into HttpState since that's where >the credentials are set. It would have the following cases: Just to clarify, it would obviously take the name of the realm as an argument as per the other credentials related methods. null would be an interesting case here since default doesn't really apply. It would probably be best to mean the last realm we authenticated against? If not, we would also need to add a method to get the last realm authenticated against. This is starting to get a little icky Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
[HttpClient] Method to determine required credential type
HttpClient has the ability to use different Credential classes for different authentication schemes (and is required for NTLM), however there is currently no way to find out which class is required when authenticating without pulling out the WWW-Authenticate header and parsing it. Would people agree to adding a method that returns the Class required for authentication? I'd suggest it should go into HttpState since that's where the credentials are set. It would have the following cases: No authentication required (because a request hasn't yet been made or because there was no 401 response): return null. Basic or Digest: return UsernamePasswordCredentials.class NTLM authentication: return NTCredentials.class Unsupported authentication scheme: null Others to be added as more authentication schemes are added. This functionality will be essential when pluggable authentication modules comes in but would be useful even now. I can get to work coding this if the idea is worthwhile (and I haven't missed something in the current docs). Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com This email and any files transmitted with it are confidential and intended solely for the use of the individual to whom they are addressed. Opinions contained in this email do not necessarily reflect the opinions of Ephox Corporation. If you have received this email in error please notify the sender immediately and delete all copies of the correspondence from your computer and/or computer network. No warranty is given that this message upon its receipt is virus free and the sender in this respect accepts no liability. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
[HttpClient][PATCH] Basic Authentication does not use default credentials
Digest authentication falls back to the default credentials (state.getCredentials(null)) when credentials for the specific realm aren't found, however basic authentication doesn't currently do that. This patch makes basic authentication behave like digest authentication. There is the security issue of having the username and password sent in clear text without specifically saying to (normally it would be specified on a per realm basis so it would be known to be sent via clear text), however I think that's a little paranoid and it's better to behave consistently. Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com .. EditLive! The world leader in browser-based web authoring tools: Desktop & Enterprise. .. This email and any files transmitted with it are confidential and intended solely for the use of the individual to whom they are addressed. Opinions contained in this email do not necessarily reflect the opinions of Ephox Corporation. If you have received this email in error please notify the sender immediately and delete all copies of the correspondence from your computer and/or computer network. No warranty is given that this message upon its receipt is virus free and the sender in this respect accepts no liability. basic_default.patch Description: Binary data -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
RE: [HttpClient] [prelim-PATCH] NTLM Authentication
>NTLM support is targeted as a HttpClient 2.1 feature on the bug you raised: >http://issues.apache.org/bugzilla/show_bug.cgi?id=10851 > >There has not been a "feature freeze" for 2.0 yet, so we're still open to adding >this earlier. There was also the idea for adding "plugable authentication" >modules for just this purpose as well. You obviously have need for NTLM, so I'm >OK with moving this up, with a few caveats: My original intent was to wait for plugable authentication modules however the schedule pressures that I'm under decreed that it had to be done now. I figure that I may as well do it in a way that can easily be incorporated back into HttpClient so that others can gain some use out of it as well. To do that though I need to run it past the experts here on the list as this is my first modifications to HttpClient or in fact any Jakarta project. Thanks for your help. It would be excellent if this could make the 2.0 release, particularly so if that release were to happen before our product has to ship. Regardless, we use only a small subset of the HttpClient functionality so we'd be happy with using a CVS version and putting it through our testing proceedures as we're yet to find any issues with the current CVS builds. >1) Using the JCE is preferable to a seperate DES class. It must only be >required at runtime if the NTLM auth code is actually executed (similar to how >https works currently) Okay, I will fold the DES stuff into the main NTLM class and ensure it is not needlessly required. >2) Testing for this is going to be difficult. A nice complete JUnit test suite >is going to be necessisary Agreed. I'll base these off of the tests for the other authentication methods. >3) Need assurance that all code (particularly NTLM.java) is free to be licenced >under the Apache software license. I can provide that assurance now since we will be using the JCE for encryption. >BTW: Integration into Authenticator looks like the logical, minimal approach. >"Pluggable authentication modules" can just be left as a future enhancement. Good to hear. Thanks for your assistance Jeff, you (and many others) are doing an sensational job around here. Yours, Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com This email and any files transmitted with it are confidential and intended solely for the use of the individual to whom they are addressed. Opinions contained in this email do not necessarily reflect the opinions of Ephox Corporation. If you have received this email in error please notify the sender immediately and delete all copies of the correspondence from your computer and/or computer network. No warranty is given that this message upon its receipt is virus free and the sender in this respect accepts no liability. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
[HttpClient] [prelim-PATCH] NTLM Authentication
I have now completed a patch to add NTLM authentication to the latest version of HttpClient, however there are a couple of issues remaining so it should considered "beta-patch" at this point and this is really a request for comment rather than a request for commit. The issues are: 1. Does not comply with current coding style of HttpClient - particularly in the new files. 2. Needs improvement to logging 3. Requires the Java Cryptography Extensions The first two just require me to get around to it, the third I'd like some comments on. My preference is to not depend on JCE and to implement DES encryption ourselves in a standalone form. To that end I have implemented the DES encryption through a wrapper file so that it is simple to switch later if required. Note that JCE does not work with JRE 1.1 at all and is an optional add on for 1.2 and 1.3. I recieved no reply from an email sent to the author of the DES encryption class I have previously mentioned and two of the author's email addresses bounced so chance of relicencing it under the Apache License is pretty much nil at this point. I have done some more research and found that the MD4 encryption can be avoided by using the Windows 98 version of the protocol which seems to be more reliable anyway. Any thoughts, comments or cryptography experts? The other thing I would like confirmation on is that the integration into HttpClient (in Authenticator.java) is the best way to do it. It certainly seems like it is, but I can't be certain of that since I don't know the HttpClient code particularly well. Thanks in advance, Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com This email and any files transmitted with it are confidential and intended solely for the use of the individual to whom they are addressed. Opinions contained in this email do not necessarily reflect the opinions of Ephox Corporation. If you have received this email in error please notify the sender immediately and delete all copies of the correspondence from your computer and/or computer network. No warranty is given that this message upon its receipt is virus free and the sender in this respect accepts no liability. auth_ntlm.patch Description: Binary data NTLM.java Description: Binary data DES.java Description: Binary data -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
[HttpClient] [PATCH] HttpMultiClient Catches IOException Twice
In HttpMultiClient (latest version in CVS) there is a catch statement for IOException followed by HttpException, however since HttpException extends from IOException there is no possible way the HttpException catch clause can be activated. Since they both just throw the exception again anyway, this patch just removes the HttpException catch clause. Javac on my system refuses to compile HttpMultiClient due to this. I think I got the patch format right... Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com This email and any files transmitted with it are confidential and intended solely for the use of the individual to whom they are addressed. Opinions contained in this email do not necessarily reflect the opinions of Ephox Corporation. If you have received this email in error please notify the sender immediately and delete all copies of the correspondence from your computer and/or computer network. No warranty is given that this message upon its receipt is virus free and the sender in this respect accepts no liability. double_catch.patch Description: Binary data -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
[HttpClient] NTLM Authentication (heading for a patch)
persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Any lawyers around? Any other options? Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com This email and any files transmitted with it are confidential and intended solely for the use of the individual to whom they are addressed. Opinions contained in this email do not necessarily reflect the opinions of Ephox Corporation. If you have received this email in error please notify the sender immediately and delete all copies of the correspondence from your computer and/or computer network. No warranty is given that this message upon its receipt is virus free and the sender in this respect accepts no liability. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
