DO NOT REPLY [Bug 35774] - [logging] TCCL problem in J2EE Container
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35774. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35774 --- Additional Comments From [EMAIL PROTECTED] 2006-02-17 11:15 --- The API is compatible with 1.0.x for normal uses of JCL. There are some minor incompatibilites for code that extends commons-logging classes; this is a pretty rare thing to do, however. See the release notes for full details. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] please check release candidate 5
On Fri, 2006-02-17 at 08:44 +0100, Boris Unckel wrote: Good Morning, Simon Kitching wrote: At some point I think it would be a good idea to post a notice to the tomcat dev list, as the subscribers there are likely to (a) care about JCL, and (b) have some interesting apps to test it with. Maybe jboss would also be good to contact, as they have had problems with JCL in the past. I believe they actually have special-case handling for JCL in their classloaders. I can test on WSAD and WAS if there is interest. We have situations where a company propietary logging framework fails, I can reproduce them with JCL. Yes please! If there are any issues (hopefully there won't be), please enable JCL's diagnostic output and include that in the bugreport or email. Details on enabling diagnostic output are in the release notes. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38537] - [VFS] copyFrom keep the file with imaginary type
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38537. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38537 --- Additional Comments From [EMAIL PROTECTED] 2006-02-17 12:30 --- Hi! I tried to reproduce it with the following code snipped: FileObject existFile = VFS.getManager().resolveFile(/home/im/tmp/exists.txt); FileObject newFile = VFS.getManager().resolveFile(/home/im/tmp/new.txt); System.err.println(Exists: + existFile.exists()); System.err.println(New: + newFile.exists()); newFile.copyFrom(existFile, Selectors.SELECT_SELF); newFile.getContent().setLastModifiedTime(0L); System.err.println(Exists: + existFile.exists()); System.err.println(New: + newFile.exists()); and it worked as expected. Could you please try again. And maybe post the ant-task (only the v-copy stuff) Thanks! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r378488 - /jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFile.java
Author: imario
Date: Fri Feb 17 03:51:44 2006
New Revision: 378488
URL: http://svn.apache.org/viewcvs?rev=378488view=rev
Log:
PR: 38105
Changed to treat a file as file it is a special file like socket or fifo.
Treat a file as file even if java.io.File.exists() returns false but its length
is 0 (hiberfil.sys on windows)
Thanks to Robert and Anton for pointing it out
Modified:
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFile.java
Modified:
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFile.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFile.java?rev=378488r1=378487r2=378488view=diff
==
---
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFile.java
(original)
+++
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFile.java
Fri Feb 17 03:51:44 2006
@@ -81,20 +81,25 @@
protected FileType doGetType()
throws Exception
{
-if (!file.exists())
+ // JDK BUG: 6192331
+// if (!file.exists())
+if (!file.exists() file.length() == 0)
{
return FileType.IMAGINARY;
}
-else if (file.isDirectory())
+
+if (file.isDirectory())
{
return FileType.FOLDER;
}
-else if (file.isFile())
-{
+
+// In doubt, treat an existing file as file
+// if (file.isFile())
+// {
return FileType.FILE;
-}
+// }
-throw new FileSystemException(vfs.provider.local/get-type.error,
file);
+// throw new FileSystemException(vfs.provider.local/get-type.error,
file);
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r378489 - /jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFile.java
Author: imario
Date: Fri Feb 17 03:52:16 2006
New Revision: 378489
URL: http://svn.apache.org/viewcvs?rev=378489view=rev
Log:
be more defensive
Modified:
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFile.java
Modified:
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFile.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFile.java?rev=378489r1=378488r2=378489view=diff
==
---
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFile.java
(original)
+++
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/LocalFile.java
Fri Feb 17 03:52:16 2006
@@ -83,7 +83,7 @@
{
// JDK BUG: 6192331
// if (!file.exists())
-if (!file.exists() file.length() == 0)
+if (!file.exists() file.length() 1)
{
return FileType.IMAGINARY;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38105] - [vfs] NullPointerException in DefaultFileContent.getLastModifiedTime()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38105. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38105 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38105] - [vfs] NullPointerException in DefaultFileContent.getLastModifiedTime()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38105. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38105 --- Additional Comments From [EMAIL PROTECTED] 2006-02-17 12:52 --- Thanks! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Potential Bug In Circular Redirect
Oleg, Thanks for the reply. Ok, the behavior can be correct, i understand you have a flag to disable circular redirects, but this still seems inappropriate. Becasue i still want to guard against genuine circular redirects from these false circular redirects, and since all browsers support this functionality, i think it would be nice if HttpClient could offer support for Browser HTTP Protocol like you can set a Param to act.like.a.browser which will 302 redirect when the uri is same but query string is different and basically operate as a forgiving http protocol if you so choose. Just an idea since the http protocol and the way all popular browsers implement it are much different. Thanks Oleg Kalnichevski wrote: On Thu, 2006-02-16 at 17:24 -0500, Ryan Smith wrote: ... I am using 3.0 RELEASE But i checked out the latest snap shot code, and the logic in HttpMethodDirector.java only checks for the URI, not URI + Query string. Ryan, I think this behavior is correct. It was implemented per this bug report: http://issues.apache.org/bugzilla/show_bug.cgi?id=33021 Set 'http.protocol.allow-circular-redirects' parameter to true to disable the check Oleg Below, plerase see my MANIFEST.MF that came with my httpclient.jar : Manifest-Version: 1.0 Ant-Version: Apache Ant 1.5.3 Created-By: Apache Maven Built-By: Michael Package: org.apache.commons.httpclient Build-Jdk: 1.3.1_17 Extension-Name: commons-httpclient Specification-Title: Jakarta Commons HttpClient Specification-Vendor: Apache Software Foundation Implementation-Title: org.apache.commons.httpclient Implementation-Vendor: Apache Software Foundation Implementation-Version: 3.0 - 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: commons-email needs care
Hi Dion, all, I created a patch against HtmlEmail as you proposed in you comment to bug 37344 (using the class provided in the same bug). It fixes bugs 37159, 37178 and 37344. I personally verified bug 37159 using proposed test (nice and complete one..) and Mozilla Thunderbird 1.5 on Windows as email client. Let me know what you think about this patch and if you like it please apply. Bye Piero Alle 22:56, mercoledì 15 febbraio 2006, Dion Gillard ha scritto: Tested and applied. On 2/16/06, Piero Ottuzzi [EMAIL PROTECTED] wrote: Hi Dion, all, I'm still alive ;) Attached you can find my reworked patch to fix many problems you can have if using commons-email with a MailSession mainly caused by typos in constant declaration or missing constant declaration. It fixes bugs 38538 and 38656 (just opened to hold the patch): please have a look and let me know. Probably tomorrow I will test what is in the repository. Thanks for your attention Bye Piero Ping? On 2/12/06, Dion Gillard [EMAIL PROTECTED] wrote: Hi Piero, some comments inline. On 2/9/06, Piero Ottuzzi [EMAIL PROTECTED] wrote: Hi Hen, many thanks for your answer. Here is a long mail on commons-email status :) SVN Repository The activity on SVN repository (speaking of the src/java dir) is stalled about 5 month ago. What you can find in SVN repository compiles fine and looks like what has been released as 'Commons Email 1.0' on 2005-09-27. Bugs As you can see in [1] there are 11 bug open [37344] This bug provide a patch (in reality it provides a whole new class). I'm using this provided class with my patched version of commons-email and it is working fine without any issue so far. The issue here is the way the patch has been implemented. I'd be happier to see this implemented as a fix to HtmlEmail, rather than a new class [37178] Can be resolved using the new class provided in previous bug. See above. [38538] This is fixed in my own attached patch. Unfortunately your patch does more than fix 38538. It adds new functionality as well, and this makes it hard to apply. e.g. there is code there to set the Mail Session from JNDI, which is a nice to have feature and means we now need to include the jndi dependency. It would be nicer to split these into separate enhancement requests as well as the bug fix. [37902] Trivial ;) Sounds reasonable. Fixed. [37783] Includes a patch. I'm using this provided patch with my patched version of commons-email and it is working fine without any issue so far. Looks reasonable. Will apply and test. Done. [37782] Includes a patch which forces a new dependency on javax.naming.* I'm using this provided patch with my patched version of commons-email and it is working fine without any issue so far. it also includes the TLS authentication helpers. I'm committing this one as: a) The TLS helpers are useful b) jndi is in jdk1.3 and above [36856] Includes patches I cannot test and I do not need Looks like it needs some testing. [36844] Includes patches I did not test Introduces a dependency on commons-lang, something I'd rather not do. [37363] Don't have a clue on this one. That one needs some more working out by the looks. Patch Attached you can find a SVN patch that fixes many problems you can see if using a MailSession that needs authentication. It includes also the patch from bug [37782]. I'm using this provided patch with my patched version of commons-email and it is working fine without any issue so far. let me know if my recent commits are working for you. -- http://www.multitask.com.au/people/dion/ If I close my eyes it doesn't seem so dark. - SpongeBob SquarePants -- http://www.multitask.com.au/people/dion/ Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid of the dark, but because the dark is afraid of Chuck Norris -- http://www.multitask.com.au/people/dion/ Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid of the dark, but because the dark is afraid of Chuck Norris -- GPG KeyID: 84AE988E Fingerprint: F0A0 CA2A 8D8F CC12 3F5E C04C D8D5 9DC3 84AE 988E gpg --keyserver x-hkp://search.keyserver.net:11371 --recv-key 84AE988E Index: src/java/org/apache/commons/mail/HtmlEmail.java === --- src/java/org/apache/commons/mail/HtmlEmail.java (revision 378506) +++ src/java/org/apache/commons/mail/HtmlEmail.java (working copy) @@ -19,9 +19,9 @@ import java.io.InputStream; import java.net.MalformedURLException; import java.net.URL; -import java.util.ArrayList; +import java.util.HashMap; import
Re: Potential Bug In Circular Redirect
Ryan Smith wrote: Oleg, Thanks for the reply. Ok, the behavior can be correct, i understand you have a flag to disable circular redirects, but this still seems inappropriate. Becasue i still want to guard against genuine circular redirects from these false circular redirects, and since all browsers support this functionality, i think it would be nice if HttpClient could offer support for Browser HTTP Protocol like you can set a Param to act.like.a.browser which will 302 redirect when the uri is same but query string is different and basically operate as a forgiving http protocol if you so choose. Just an idea since the http protocol and the way all popular browsers implement it are much different. The trouble is that so called popular browsers do it rather badly. They tend to accept any garbage some badly written CGI scripts spit out at them instead of rejecting malformed HTTP messages as invalid thus giving the developers of those sites some incentive to do their job properly. We usually provide a lenient mode in those cases where the wording of the HTTP spec is vague or ambiguous, but we have no intension to work around some pretty gross violations of the HTTP spec that common browsers tend to forgive. After all, HttpClient is not a browser, nor a vacuum cleaner, it is what it is, an HTTP library. Hope this explains our position Oleg Thanks Oleg Kalnichevski wrote: On Thu, 2006-02-16 at 17:24 -0500, Ryan Smith wrote: ... I am using 3.0 RELEASE But i checked out the latest snap shot code, and the logic in HttpMethodDirector.java only checks for the URI, not URI + Query string. Ryan, I think this behavior is correct. It was implemented per this bug report: http://issues.apache.org/bugzilla/show_bug.cgi?id=33021 Set 'http.protocol.allow-circular-redirects' parameter to true to disable the check Oleg Below, plerase see my MANIFEST.MF that came with my httpclient.jar : Manifest-Version: 1.0 Ant-Version: Apache Ant 1.5.3 Created-By: Apache Maven Built-By: Michael Package: org.apache.commons.httpclient Build-Jdk: 1.3.1_17 Extension-Name: commons-httpclient Specification-Title: Jakarta Commons HttpClient Specification-Vendor: Apache Software Foundation Implementation-Title: org.apache.commons.httpclient Implementation-Vendor: Apache Software Foundation Implementation-Version: 3.0 - 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: Potential Bug In Circular Redirect
Oleg, Understood, thanks. Well, in the future, if you would ever decide to offer that functionality to be lienient on http as an option, i have some code for ya. Reverse Engineering popular browsers is a pain! Thanks again! :) -Ryan Oleg Kalnichevski wrote: Ryan Smith wrote: Oleg, Thanks for the reply. Ok, the behavior can be correct, i understand you have a flag to disable circular redirects, but this still seems inappropriate. Becasue i still want to guard against genuine circular redirects from these false circular redirects, and since all browsers support this functionality, i think it would be nice if HttpClient could offer support for Browser HTTP Protocol like you can set a Param to act.like.a.browser which will 302 redirect when the uri is same but query string is different and basically operate as a forgiving http protocol if you so choose. Just an idea since the http protocol and the way all popular browsers implement it are much different. The trouble is that so called popular browsers do it rather badly. They tend to accept any garbage some badly written CGI scripts spit out at them instead of rejecting malformed HTTP messages as invalid thus giving the developers of those sites some incentive to do their job properly. We usually provide a lenient mode in those cases where the wording of the HTTP spec is vague or ambiguous, but we have no intension to work around some pretty gross violations of the HTTP spec that common browsers tend to forgive. After all, HttpClient is not a browser, nor a vacuum cleaner, it is what it is, an HTTP library. Hope this explains our position Oleg Thanks Oleg Kalnichevski wrote: On Thu, 2006-02-16 at 17:24 -0500, Ryan Smith wrote: ... I am using 3.0 RELEASE But i checked out the latest snap shot code, and the logic in HttpMethodDirector.java only checks for the URI, not URI + Query string. Ryan, I think this behavior is correct. It was implemented per this bug report: http://issues.apache.org/bugzilla/show_bug.cgi?id=33021 Set 'http.protocol.allow-circular-redirects' parameter to true to disable the check Oleg Below, plerase see my MANIFEST.MF that came with my httpclient.jar : Manifest-Version: 1.0 Ant-Version: Apache Ant 1.5.3 Created-By: Apache Maven Built-By: Michael Package: org.apache.commons.httpclient Build-Jdk: 1.3.1_17 Extension-Name: commons-httpclient Specification-Title: Jakarta Commons HttpClient Specification-Vendor: Apache Software Foundation Implementation-Title: org.apache.commons.httpclient Implementation-Vendor: Apache Software Foundation Implementation-Version: 3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38688] - [net] TelnetInputStream.read sometimes hangs if reader thread is disabled
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38688. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38688 --- Additional Comments From [EMAIL PROTECTED] 2006-02-17 15:52 --- Note that the code snippet in the description is missing the closing brace of the while loop. It occurs right after the if(__threaded) block. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Potential Bug In Circular Redirect
Ryan Smith wrote: Oleg, Understood, thanks. Well, in the future, if you would ever decide to offer that functionality to be lienient on http as an option, i have some code for ya. Reverse Engineering popular browsers is a pain! Thanks again! :) -Ryan Ryan, Commons HttpClient in its present form suffers from feature and options bloat more than anything else. We can no longer keep on piling stuff on top of it. We (The Jakarta HttpComponents project) are currently in the process of rewriting HttpClient from scratch, primarily to make it more modular and reusable http://wiki.apache.org/jakarta-httpclient/HttpClientApiRedesign http://wiki.apache.org/jakarta-httpclient/ProjectGoalsPage Feel free to consider submitting your code to HttpComponents at some point of time Oleg Oleg Kalnichevski wrote: Ryan Smith wrote: Oleg, Thanks for the reply. Ok, the behavior can be correct, i understand you have a flag to disable circular redirects, but this still seems inappropriate. Becasue i still want to guard against genuine circular redirects from these false circular redirects, and since all browsers support this functionality, i think it would be nice if HttpClient could offer support for Browser HTTP Protocol like you can set a Param to act.like.a.browser which will 302 redirect when the uri is same but query string is different and basically operate as a forgiving http protocol if you so choose. Just an idea since the http protocol and the way all popular browsers implement it are much different. The trouble is that so called popular browsers do it rather badly. They tend to accept any garbage some badly written CGI scripts spit out at them instead of rejecting malformed HTTP messages as invalid thus giving the developers of those sites some incentive to do their job properly. We usually provide a lenient mode in those cases where the wording of the HTTP spec is vague or ambiguous, but we have no intension to work around some pretty gross violations of the HTTP spec that common browsers tend to forgive. After all, HttpClient is not a browser, nor a vacuum cleaner, it is what it is, an HTTP library. Hope this explains our position Oleg Thanks Oleg Kalnichevski wrote: On Thu, 2006-02-16 at 17:24 -0500, Ryan Smith wrote: ... I am using 3.0 RELEASE But i checked out the latest snap shot code, and the logic in HttpMethodDirector.java only checks for the URI, not URI + Query string. Ryan, I think this behavior is correct. It was implemented per this bug report: http://issues.apache.org/bugzilla/show_bug.cgi?id=33021 Set 'http.protocol.allow-circular-redirects' parameter to true to disable the check Oleg Below, plerase see my MANIFEST.MF that came with my httpclient.jar : Manifest-Version: 1.0 Ant-Version: Apache Ant 1.5.3 Created-By: Apache Maven Built-By: Michael Package: org.apache.commons.httpclient Build-Jdk: 1.3.1_17 Extension-Name: commons-httpclient Specification-Title: Jakarta Commons HttpClient Specification-Vendor: Apache Software Foundation Implementation-Title: org.apache.commons.httpclient Implementation-Vendor: Apache Software Foundation Implementation-Version: 3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38165] - [beanutils] provide better error message for argument type mismatch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38165. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38165 --- Additional Comments From [EMAIL PROTECTED] 2006-02-17 18:06 --- Created an attachment (id=17731) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17731action=view) PropertyUtilsBean.patch a slight improvement -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Potential Bug In Circular Redirect
Olag, Thanks, i am exactly looking for a project like this. Thanks so much. I was thinking, the component idea is great, i like the http-spider, since thats what i work on . I have an open source project that was started a year ago: http://aspider.sf.net/ This is a autonomous java spider 1.4 compatible. Do you know who i could contact at the new http components projects to offer suggestions/code? Thanks again. -Ryan Oleg Kalnichevski wrote: Ryan Smith wrote: Oleg, Understood, thanks. Well, in the future, if you would ever decide to offer that functionality to be lienient on http as an option, i have some code for ya. Reverse Engineering popular browsers is a pain! Thanks again! :) -Ryan Ryan, Commons HttpClient in its present form suffers from feature and options bloat more than anything else. We can no longer keep on piling stuff on top of it. We (The Jakarta HttpComponents project) are currently in the process of rewriting HttpClient from scratch, primarily to make it more modular and reusable http://wiki.apache.org/jakarta-httpclient/HttpClientApiRedesign http://wiki.apache.org/jakarta-httpclient/ProjectGoalsPage Feel free to consider submitting your code to HttpComponents at some point of time Oleg Oleg Kalnichevski wrote: Ryan Smith wrote: Oleg, Thanks for the reply. Ok, the behavior can be correct, i understand you have a flag to disable circular redirects, but this still seems inappropriate. Becasue i still want to guard against genuine circular redirects from these false circular redirects, and since all browsers support this functionality, i think it would be nice if HttpClient could offer support for Browser HTTP Protocol like you can set a Param to act.like.a.browser which will 302 redirect when the uri is same but query string is different and basically operate as a forgiving http protocol if you so choose. Just an idea since the http protocol and the way all popular browsers implement it are much different. The trouble is that so called popular browsers do it rather badly. They tend to accept any garbage some badly written CGI scripts spit out at them instead of rejecting malformed HTTP messages as invalid thus giving the developers of those sites some incentive to do their job properly. We usually provide a lenient mode in those cases where the wording of the HTTP spec is vague or ambiguous, but we have no intension to work around some pretty gross violations of the HTTP spec that common browsers tend to forgive. After all, HttpClient is not a browser, nor a vacuum cleaner, it is what it is, an HTTP library. Hope this explains our position Oleg Thanks Oleg Kalnichevski wrote: On Thu, 2006-02-16 at 17:24 -0500, Ryan Smith wrote: ... I am using 3.0 RELEASE But i checked out the latest snap shot code, and the logic in HttpMethodDirector.java only checks for the URI, not URI + Query string. Ryan, I think this behavior is correct. It was implemented per this bug report: http://issues.apache.org/bugzilla/show_bug.cgi?id=33021 Set 'http.protocol.allow-circular-redirects' parameter to true to disable the check Oleg Below, plerase see my MANIFEST.MF that came with my httpclient.jar : Manifest-Version: 1.0 Ant-Version: Apache Ant 1.5.3 Created-By: Apache Maven Built-By: Michael Package: org.apache.commons.httpclient Build-Jdk: 1.3.1_17 Extension-Name: commons-httpclient Specification-Title: Jakarta Commons HttpClient Specification-Vendor: Apache Software Foundation Implementation-Title: org.apache.commons.httpclient Implementation-Vendor: Apache Software Foundation Implementation-Version: 3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38685] - [validator] Error Message '{field} is not in the range null through null' in validator framework
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38685. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38685 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2006-02-17 19:19 --- Hi Niall, Thanks that struts example helped me. The position attribute solved the problem. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Potential Bug In Circular Redirect
On Fri, 2006-02-17 at 12:51 -0500, Ryan Smith wrote: Olag, Thanks, i am exactly looking for a project like this. Thanks so much. I was thinking, the component idea is great, i like the http-spider, since thats what i work on . I have an open source project that was started a year ago: http://aspider.sf.net/ This is a autonomous java spider 1.4 compatible. Do you know who i could contact at the new http components projects to offer suggestions/code? Thanks again. -Ryan Ryan, You can get in touch with the Jakarta HttpComponents developers by subscribing to the httpclient-dev@jakarta.apache.org list. Just post your suggestions / ideas / patches to the list and participate in the discussion that will follow. Cheers, Oleg Oleg Kalnichevski wrote: Ryan Smith wrote: Oleg, Understood, thanks. Well, in the future, if you would ever decide to offer that functionality to be lienient on http as an option, i have some code for ya. Reverse Engineering popular browsers is a pain! Thanks again! :) -Ryan Ryan, Commons HttpClient in its present form suffers from feature and options bloat more than anything else. We can no longer keep on piling stuff on top of it. We (The Jakarta HttpComponents project) are currently in the process of rewriting HttpClient from scratch, primarily to make it more modular and reusable http://wiki.apache.org/jakarta-httpclient/HttpClientApiRedesign http://wiki.apache.org/jakarta-httpclient/ProjectGoalsPage Feel free to consider submitting your code to HttpComponents at some point of time Oleg Oleg Kalnichevski wrote: Ryan Smith wrote: Oleg, Thanks for the reply. Ok, the behavior can be correct, i understand you have a flag to disable circular redirects, but this still seems inappropriate. Becasue i still want to guard against genuine circular redirects from these false circular redirects, and since all browsers support this functionality, i think it would be nice if HttpClient could offer support for Browser HTTP Protocol like you can set a Param to act.like.a.browser which will 302 redirect when the uri is same but query string is different and basically operate as a forgiving http protocol if you so choose. Just an idea since the http protocol and the way all popular browsers implement it are much different. The trouble is that so called popular browsers do it rather badly. They tend to accept any garbage some badly written CGI scripts spit out at them instead of rejecting malformed HTTP messages as invalid thus giving the developers of those sites some incentive to do their job properly. We usually provide a lenient mode in those cases where the wording of the HTTP spec is vague or ambiguous, but we have no intension to work around some pretty gross violations of the HTTP spec that common browsers tend to forgive. After all, HttpClient is not a browser, nor a vacuum cleaner, it is what it is, an HTTP library. Hope this explains our position Oleg Thanks Oleg Kalnichevski wrote: On Thu, 2006-02-16 at 17:24 -0500, Ryan Smith wrote: ... I am using 3.0 RELEASE But i checked out the latest snap shot code, and the logic in HttpMethodDirector.java only checks for the URI, not URI + Query string. Ryan, I think this behavior is correct. It was implemented per this bug report: http://issues.apache.org/bugzilla/show_bug.cgi?id=33021 Set 'http.protocol.allow-circular-redirects' parameter to true to disable the check Oleg Below, plerase see my MANIFEST.MF that came with my httpclient.jar : Manifest-Version: 1.0 Ant-Version: Apache Ant 1.5.3 Created-By: Apache Maven Built-By: Michael Package: org.apache.commons.httpclient Build-Jdk: 1.3.1_17 Extension-Name: commons-httpclient Specification-Title: Jakarta Commons HttpClient Specification-Vendor: Apache Software Foundation Implementation-Title: org.apache.commons.httpclient Implementation-Vendor: Apache Software Foundation Implementation-Version: 3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38703] New: - [collections] [PATCH] Avoid unnecessary object instantiation with any/all/none/one predicate factory methods
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38703. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38703 Summary: [collections] [PATCH] Avoid unnecessary object instantiation with any/all/none/one predicate factory methods Product: Commons Version: Nightly Builds Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Collections AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] With bug 37979 resolved, the any/all/none/one predicates allow zero- and one- element Predicate groups. This patch adds some checking to their static factory methods to avoid instantiating unnecessary objects. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38703] - [collections] [PATCH] Avoid unnecessary object instantiation with any/all/none/one predicate factory methods
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38703. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38703 --- Additional Comments From [EMAIL PROTECTED] 2006-02-17 23:17 --- Created an attachment (id=17734) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17734action=view) patch as described -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r378650 - /jakarta/commons/proper/codec/trunk/project.xml
Author: rahul Date: Fri Feb 17 15:14:41 2006 New Revision: 378650 URL: http://svn.apache.org/viewcvs?rev=378650view=rev Log: Change coverage tool from clover to cobertura based on recent discussion with Gary Gregory on dev list. Modified: jakarta/commons/proper/codec/trunk/project.xml Modified: jakarta/commons/proper/codec/trunk/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/codec/trunk/project.xml?rev=378650r1=378649r2=378650view=diff == --- jakarta/commons/proper/codec/trunk/project.xml (original) +++ jakarta/commons/proper/codec/trunk/project.xml Fri Feb 17 15:14:41 2006 @@ -1,6 +1,6 @@ ?xml version=1.0 encoding=UTF-8? !-- -Copyright 2002-2005 The Apache Software Foundation. +Copyright 2002-2006 The Apache Software Foundation. Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. @@ -193,6 +193,16 @@ scopetest/scope /properties /dependency +dependency +groupIdmaven-plugins/groupId +artifactIdmaven-cobertura-plugin/artifactId +version1.1.1/version + urlhttp://maven-plugins.sourceforge.net/maven-cobertura-plugin//url +typeplugin/type +properties + commentSite generation/comment +/properties +/dependency /dependencies issueTrackingUrlhttp://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;email1=amp;emailtype1=substringamp;emailassigned_to1=1amp;email2=amp;emailtype2=substringamp;emailreporter2=1amp;bugidtype=includeamp;bug_id=amp;changedin=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;product=Commonsamp;component=Codecamp;short_desc=amp;short_desc_type=allwordssubstramp;long_desc=amp;long_desc_type=allwordssubstramp;bug_file_loc=amp;bug_file_loc_type=allwordssubstramp;keywords=amp;keywords_type=anywordsamp;field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=amp;cmdtype=doitamp;newqueryname=amp;order=Reuse+same+sort+as+last+time/issueTrackingUrl build @@ -224,7 +234,8 @@ reportmaven-changes-plugin/report reportmaven-changelog-plugin/report reportmaven-checkstyle-plugin/report -reportmaven-clover-plugin/report +!-- reportmaven-clover-plugin/report -- +reportmaven-cobertura-plugin/report reportmaven-developer-activity-plugin/report reportmaven-file-activity-plugin/report !-- reportmaven-findbugs-plugin/report -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r378686 - /jakarta/commons/proper/digester/trunk/xdocs/index.xml
Author: skitching Date: Fri Feb 17 20:38:11 2006 New Revision: 378686 URL: http://svn.apache.org/viewcvs?rev=378686view=rev Log: Add reference to the wiki. Modified: jakarta/commons/proper/digester/trunk/xdocs/index.xml Modified: jakarta/commons/proper/digester/trunk/xdocs/index.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/xdocs/index.xml?rev=378686r1=378685r2=378686view=diff == --- jakarta/commons/proper/digester/trunk/xdocs/index.xml (original) +++ jakarta/commons/proper/digester/trunk/xdocs/index.xml Fri Feb 17 20:38:11 2006 @@ -57,8 +57,11 @@ download the files. /p -/section +pFor the FAQ and other digester-related information, see + a href=http://wiki.apache.org/jakarta-commons/Digester;the Digester wiki page/a. +/p +/section section name=Releases subsection name='Digester 1.7 Release (12 June 2005)' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r378687 - in /jakarta/commons/proper/digester/trunk/src: java/org/apache/commons/digester/NodeCreateRule.java test/org/apache/commons/digester/NodeCreateRuleTestCase.java test/org/apache/c
Author: skitching
Date: Fri Feb 17 20:40:46 2006
New Revision: 378687
URL: http://svn.apache.org/viewcvs?rev=378687view=rev
Log:
Fix bugzilla#36773, where NodeCreateRule was losing xml attribute prefix when
creating an element to represent an attribute in an input document. Thanks to
Kurt Zettel II for the patch (and for his patience). This potentially causes
an incompatibility with the old version of this class, in that the DOM node
created now (correctly) has a namespace prefix on the QName.
Added:
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/Test10.xml
Modified:
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/NodeCreateRule.java
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/NodeCreateRuleTestCase.java
Modified:
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/NodeCreateRule.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/NodeCreateRule.java?rev=378687r1=378686r2=378687view=diff
==
---
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/NodeCreateRule.java
(original)
+++
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/NodeCreateRule.java
Fri Feb 17 20:40:46 2006
@@ -397,7 +397,7 @@
doc.createElementNS(namespaceURI, name);
for (int i = 0; i attributes.getLength(); i++) {
element.setAttributeNS(attributes.getURI(i),
- attributes.getLocalName(i),
+ attributes.getQName(i),
attributes.getValue(i));
}
} else {
Modified:
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/NodeCreateRuleTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/NodeCreateRuleTestCase.java?rev=378687r1=378686r2=378687view=diff
==
---
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/NodeCreateRuleTestCase.java
(original)
+++
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/NodeCreateRuleTestCase.java
Fri Feb 17 20:40:46 2006
@@ -381,6 +381,55 @@
}
+/**
+ * Tests whether namespaced attributes are handled correctly, using the
example from
+ * the file Test10 XML file.
+ */
+public void testNamespacedAttribute()
+throws SAXException, ParserConfigurationException, IOException {
+
+digester.setNamespaceAware(true);
+digester.setRuleNamespaceURI(null);
+digester.addRule(employee,
+ new NodeCreateRule(Node.ELEMENT_NODE));
+Object result = digester.parse(getInputStream(Test10.xml));
+
+assertNotNull(result);
+assertTrue(result instanceof Element);
+Element element = (Element)result;
+
+
assertNotNull(element.getAttributeNodeNS(http://jakarta.apache.org/digester/Bar;,
test));
+assertEquals(MyTestAttribute,
element.getAttributeNodeNS(http://jakarta.apache.org/digester/Bar;,
test).getNodeValue());
+assertEquals(test,
element.getAttributeNodeNS(http://jakarta.apache.org/digester/Bar;,
test).getLocalName());
+assertEquals(bar,
element.getAttributeNodeNS(http://jakarta.apache.org/digester/Bar;,
test).getPrefix());
+assertEquals(bar:test,
element.getAttributeNodeNS(http://jakarta.apache.org/digester/Bar;,
test).getName());
+
+}
+
+/**
+ * Tests whether non-namespaced attributes are handled correctly, using
the example from
+ * the file Test11 XML file.
+ */
+public void testNonNamespacedAttribute()
+throws SAXException, ParserConfigurationException, IOException {
+
+digester.setNamespaceAware(true);
+digester.setRuleNamespaceURI(null);
+digester.addRule(employee,
+ new NodeCreateRule(Node.ELEMENT_NODE));
+Object result = digester.parse(getInputStream(Test10.xml));
+
+assertNotNull(result);
+assertTrue(result instanceof Element);
+Element element = (Element)result;
+
+assertNotNull(element.getAttributeNodeNS(null, firstName));
+assertEquals(First Name, element.getAttributeNodeNS(null,
firstName).getNodeValue());
+assertEquals(firstName, element.getAttributeNodeNS(null,
firstName).getLocalName());
+assertEquals(null, element.getAttributeNodeNS(null,
firstName).getPrefix());
+assertEquals(firstName, element.getAttributeNodeNS(null,
firstName).getName());
+
+}
/**
* Tests whether the created fragment can be
DO NOT REPLY [Bug 36773] - [digester] [PATCH] NodeCreateRule does not correctly handle namespaced attributes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36773. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36773 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-02-18 05:42 --- Hi Kurt, After further thought, I think you're right. The old behaviour is just a bug, so a change in behaviour is ok, not an incompatibility. I've committed your patch. Thanks very much for your contribution - and your patience! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
