[GUMP] Build Failure - commons-jelly-tags-html
This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2003-03-31/commons-jelly-tags-html.html Buildfile: build.xml init: [mkdir] Created dir: /home/rubys/jakarta/jelly-tags/html/target/lib get-deps: compile: [mkdir] Created dir: /home/rubys/jakarta/jelly-tags/html/target/classes [javac] Compiling 2 source files to /home/rubys/jakarta/jelly-tags/html/target/classes [copy] Copying 5 files to /home/rubys/jakarta/jelly-tags/html/target/test-classes compile-tests: [javac] Compiling 1 source file to /home/rubys/jakarta/jelly-tags/html/target/test-classes internal-test: [mkdir] Created dir: /home/rubys/jakarta/jelly-tags/html/target/test-reports [junit] Running org.apache.commons.jelly.html.TestJelly [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.319 sec [junit] Testsuite: org.apache.commons.jelly.html.TestJelly [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.319 sec [junit] Testcase: testSimpleParse took 0.202 sec [junit] Caused an ERROR [junit] file:/home/rubys/jakarta/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:9:46: html:parse null Nested exception: null [junit] org.apache.commons.jelly.JellyTagException: file:/home/rubys/jakarta/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:9:46: html:parse null Nested exception: null [junit] at org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSupport.java:232) [junit] at org.apache.commons.jelly.tags.html.ParseTag.doTag(ParseTag.java:116) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:105) [junit] Caused by: org.dom4j.DocumentException: null Nested exception: null [junit] at org.dom4j.io.SAXReader.read(SAXReader.java:358) [junit] at org.dom4j.io.SAXReader.read(SAXReader.java:233) [junit] at org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSupport.java:211) [junit] ... 13 more [junit] Root cause [junit] org.dom4j.DocumentException: null Nested exception: null [junit] at org.dom4j.io.SAXReader.read(SAXReader.java:358) [junit] at org.dom4j.io.SAXReader.read(SAXReader.java:233) [junit] at org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSupport.java:211) [junit] at org.apache.commons.jelly.tags.html.ParseTag.doTag(ParseTag.java:116) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:105) [junit] Nested exception: [junit] java.lang.NullPointerException [junit] at org.apache.xerces.parsers.AbstractSAXParser.startNamespaceMapping(Unknown Source) [junit] at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) [junit] at org.cyberneko.html.HTMLTagBalancer.startElement(Unknown Source) [junit] at org.cyberneko.html.HTMLScanner$ContentScanner.scanStartElement(Unknown Source) [junit] at org.cyberneko.html.HTMLScanner$ContentScanner.scan(Unknown Source) [junit] at org.cyberneko.html.HTMLScanner.scanDocument(Unknown Source) [junit] at org.cyberneko.html.HTMLConfiguration.parse(Unknown Source) [junit] at org.cyberneko.html.HTMLConfiguration.parse(Unknown Source) [junit] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) [junit] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) [junit] at org.dom4j.io.SAXReader.read(SAXReader.java:339) [junit] at org.dom4j.io.SAXReader.read(SAXReader.java:233) [junit] at org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSupport.java:211) [junit] at org.apache.commons.jelly.tags.html.ParseTag.doTag(ParseTag.java:116) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:105) [junit] Testcase: testSimpleParse BUILD FAILED file:///home/rubys/jakarta/jelly-tags/html/build.xml:95: Test org.apache.commons.jelly.html.TestJelly failed Total time: 6 seconds - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14120] - [FileUpload] uploading files with non-ASCII filenames
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14120. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14120 [FileUpload] uploading files with non-ASCII filenames --- Additional Comments From [EMAIL PROTECTED] 2003-03-31 12:48 --- When is this bug fixed? I encountered it when I used the different encoding between the system default encoding and the web app. encoding. For example, tomcat uses EUC-JP as the system default encoding, and the web app. uses UTF-8 as the HTML page encoding. In this case, we get ??? as the uploaded file name. Because baos.toString() uses the default encoding, to parse the file name should use HTML page encoding. (If the system default encoding is the same as web app. one, this bug is not reproduced.) I created the patch to add an encoding parameter. It does not break the existing user's application using commons-fileupload. Please evaluate and integrate this patch. Multibyte users (including me) need this feature... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14120] - [FileUpload] uploading files with non-ASCII filenames
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14120. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14120 [FileUpload] uploading files with non-ASCII filenames --- Additional Comments From [EMAIL PROTECTED] 2003-03-31 12:49 --- Created an attachment (id=5575) patch to add the encoding parameter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] StringEscapeUtils
Howdy, A couple of comments, and a request: see intermixed. I've checked in my first pass at StringEscapeUtils. It handles Java, JavaScript, and HTML entity escaping and unescaping. Great -- thank you for contributing ;) * StringEscapeUtils is a bit much to type for a quick static API call -- should we rename it EscapeUtils? It's not like there will be any other type of Escape... I don't think it's a bit much, and I do like having the String in the name of the class. I can't think of any other EscapeUtils candidates, but that doesn't mean there can't be any, so let's keep it as StringEscapeUtils. * Java strings can handle raw single-quotes inside strings, but I I agree. Good thinking. * escapeJava now uses lowercase letters for hex codes. Are there any feelings about switching to capital letters? I prefer caps (like \uCAFE instead of \ucafe) but I could go either way. No biggie either way. * I made use of (and thus contributed) my StringPrintWriter class. Do you think it's useful enough to make it part of the public API (and add tests and docs for it)? I would say keep it private unless/until there's demand to make it public. The more public stuff we have, the more we have to worry about support and maintenance as we move forward. * XML escape, SQL escape. They're both easy, at least in the first pass. But does anyone know how to escape high-bit and control chars in SQL? (I know that JDBC has its own curly-brace escapes; that's out of scope for this function.) XML escape and unescape was my request, so good to see you already had that in mind ;) It should be fairly simple to do with the regex stuff, just have patterns for ,',,,... * I think it'll be ready to roll for 2.0, but if we decide to postpone, I'll have to change the build.xml to exclude it from the jar. A bit of a sticky point, the whole 2.0 release ;) I think Mr. Yandell already addressed this one ;) Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] StringEscapeUtils
| * escapeJava now uses lowercase letters for hex codes. Are there any | feelings about switching to capital letters? I prefer caps (like | \uCAFE instead of \ucafe) but I could go either way. I would vote for using uppercase, because this is what Sun uses throughout the JDK. --Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/example QuicksortExample.java
rwaldhoff2003/03/31 10:21:52 Modified:functor/xdocs examples.xml functor/src/test/org/apache/commons/functor/example QuicksortExample.java Log: minor changes to examples Revision ChangesPath 1.3 +6 -4 jakarta-commons-sandbox/functor/xdocs/examples.xml Index: examples.xml === RCS file: /home/cvs/jakarta-commons-sandbox/functor/xdocs/examples.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- examples.xml 12 Mar 2003 21:08:16 - 1.2 +++ examples.xml 31 Mar 2003 18:21:52 - 1.3 @@ -80,15 +80,17 @@ /p p The -a href=xref-test/org/apache/commons/functor/example/FlexiMapExample.html#88FlexiMap/a -example applies this design to codejava.util.Map/code, demonstrating how +a href=xref-test/org/apache/commons/functor/example/FlexiMapExample.html#88FlexiMap example/a +applies this design to codejava.util.Map/code, demonstrating how pluggable functors can be applied to a generic codeMap/code structure in order to introduce new behaviors. /p /subsection - subsection name=A Functional Quicksort Implementation + subsection name=A Quicksort Implementation p - See the a href=xref-test/org/apache/commons/functor/example/QuicksortExample.html#79Quicksort/a example. + The a href=xref-test/org/apache/commons/functor/example/QuicksortExample.html#79Quicksort example/a + presents an implementation of the Quicksort sorting algorithm written in a functional programming + style using Commons Functor. /p /subsection /section 1.3 +160 -51 jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/example/QuicksortExample.java Index: QuicksortExample.java === RCS file: /home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/example/QuicksortExample.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- QuicksortExample.java 12 Mar 2003 21:08:16 - 1.2 +++ QuicksortExample.java 31 Mar 2003 18:21:52 - 1.3 @@ -342,13 +342,92 @@ System.out.println(); } + /* - * BUILDING BLOCKS: + * THE QUICKSORT ALGORITHM: * + */ + +/* + * Our quicksort method will invoke a UnaryFunction named + * quicksort: + */ + +public List quicksort(List list) { +return (List)(quicksort.evaluate(list)); +} + +/* + * The quicksort sorting algorithm can be summarized as follows: + * + * Given a list of elements to be sorted: + * + * A) If the list is empty, consider it already sorted. + * + * B) If the list is non-empty, we can sort it by first splitting it into + * three lists: + * 1) one list containing only the first element in the list (the head) + * 2) one (possibly empty) list containing every element in the remaining + *list that is less than the head + * 3) one (possibly empty) list containing every element in the remaining + *list that is greater than or equal to the head + *applying the quicksort algorithm recursively to the second and third lists, + *and joining the results back together as (2) + (1) + (3). + */ + +/* + * Using a functional style (or at least a semi-functional style), it's easy + * to transalate this description directly into code: + */ + +private UnaryFunction quicksort = new ConditionalUnaryFunction( +/* if the list is empty... */ +IsEmpty.getIsEmpty(), +/* ...then return an empty list... */ +new ConstantFunction(Collections.EMPTY_LIST), +/* ...else, apply the following function... */ +new ListFunction() { +public Object evaluate(List list) { +/* Create a list to contain the results. */ +List result = new ArrayList(list.size()); +/* + * Recursively apply quicksort the the elements in the + * tail less than the head, adding the result to the + * sorted list we're generating. + */ +result.addAll( +(List)quicksort.evaluate( +lesserTail.evaluate( +head.evaluate(list), +tail.evaluate(list; +/* + * Add the head to the sorted
cvs commit: jakarta-commons/el/src/java/org/apache/commons/el ArraySuffix.java BinaryOperatorExpression.java ComplexValue.java ConditionalExpression.java Expression.java ExpressionEvaluatorImpl.java ExpressionString.java FunctionInvocation.java Literal.java NamedValue.java PropertySuffix.java UnaryOperatorExpression.java ValueSuffix.java
luehe 2003/03/31 10:29:42 Modified:el build.properties el/src/java/org/apache/commons/el ArraySuffix.java BinaryOperatorExpression.java ComplexValue.java ConditionalExpression.java Expression.java ExpressionEvaluatorImpl.java ExpressionString.java FunctionInvocation.java Literal.java NamedValue.java PropertySuffix.java UnaryOperatorExpression.java ValueSuffix.java Log: Removed default prefix [patch by Kin-Man Chung] Revision ChangesPath 1.2 +1 -1 jakarta-commons/el/build.properties Index: build.properties === RCS file: /home/cvs/jakarta-commons/el/build.properties,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.properties 4 Feb 2003 00:22:24 - 1.1 +++ build.properties 31 Mar 2003 18:29:42 - 1.2 @@ -3,7 +3,7 @@ # The directory containing your binary distribution of JUnit, # version 3.7 or later -junit.home = /usr/local/junit3.7 +junit.home = ../../junit3.7 # The pathname of the junit.jar JAR file junit.jar = ${junit.home}/junit.jar 1.2 +3 -6 jakarta-commons/el/src/java/org/apache/commons/el/ArraySuffix.java Index: ArraySuffix.java === RCS file: /home/cvs/jakarta-commons/el/src/java/org/apache/commons/el/ArraySuffix.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ArraySuffix.java 4 Feb 2003 00:22:24 - 1.1 +++ ArraySuffix.java 31 Mar 2003 18:29:42 - 1.2 @@ -146,12 +146,10 @@ **/ Object evaluateIndex (VariableResolver pResolver, FunctionMapper functions, - String defaultPrefix, Logger pLogger) throws ELException { -return mIndex.evaluate (pResolver, functions, defaultPrefix, - pLogger); +return mIndex.evaluate (pResolver, functions, pLogger); } //- @@ -185,7 +183,6 @@ public Object evaluate (Object pValue, VariableResolver pResolver, FunctionMapper functions, - String defaultPrefix, Logger pLogger) throws ELException { @@ -205,8 +202,8 @@ } // Evaluate the index -else if ((indexVal = evaluateIndex (pResolver, functions, defaultPrefix, - pLogger)) == null) { +else if ((indexVal = evaluateIndex (pResolver, functions, pLogger)) + == null) { if (pLogger.isLoggingWarning ()) { pLogger.logWarning (Constants.CANT_GET_NULL_INDEX, 1.2 +2 -4 jakarta-commons/el/src/java/org/apache/commons/el/BinaryOperatorExpression.java Index: BinaryOperatorExpression.java === RCS file: /home/cvs/jakarta-commons/el/src/java/org/apache/commons/el/BinaryOperatorExpression.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- BinaryOperatorExpression.java 4 Feb 2003 00:22:24 - 1.1 +++ BinaryOperatorExpression.java 31 Mar 2003 18:29:42 - 1.2 @@ -148,12 +148,10 @@ **/ public Object evaluate (VariableResolver pResolver, FunctionMapper functions, - String defaultPrefix, Logger pLogger) throws ELException { -Object value = mExpression.evaluate (pResolver, functions, - defaultPrefix, pLogger); +Object value = mExpression.evaluate (pResolver, functions, pLogger); for (int i = 0; i mOperators.size (); i++) { BinaryOperator operator = (BinaryOperator) mOperators.get (i); @@ -166,7 +164,7 @@ if (operator.shouldEvaluate (value)) { Expression expression = (Expression) mExpressions.get (i); Object nextValue = expression.evaluate (pResolver, - functions, defaultPrefix, + functions, pLogger); value = operator.apply (value, nextValue, pLogger); 1.2 +2 -5 jakarta-commons/el/src/java/org/apache/commons/el/ComplexValue.java Index: ComplexValue.java === RCS file: /home/cvs/jakarta-commons/el/src/java/org/apache/commons/el/ComplexValue.java,v retrieving revision 1.1 retrieving revision
cvs commit: jakarta-commons-sandbox/functor/xdocs examples.xml
rwaldhoff2003/03/31 11:04:53 Modified:functor/xdocs examples.xml Log: update link Revision ChangesPath 1.4 +1 -1 jakarta-commons-sandbox/functor/xdocs/examples.xml Index: examples.xml === RCS file: /home/cvs/jakarta-commons-sandbox/functor/xdocs/examples.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- examples.xml 31 Mar 2003 18:21:52 - 1.3 +++ examples.xml 31 Mar 2003 19:04:53 - 1.4 @@ -80,7 +80,7 @@ /p p The -a href=xref-test/org/apache/commons/functor/example/FlexiMapExample.html#88FlexiMap example/a +a href=xref-test/org/apache/commons/functor/example/FlexiMapExample.html#84FlexiMap example/a applies this design to codejava.util.Map/code, demonstrating how pluggable functors can be applied to a generic codeMap/code structure in order to introduce new behaviors. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[beanutil] Re: Accessing normal properties on a DynaBean using PropertyUtils.
On Monday, March 31, 2003, at 02:09 AM, Gavin McPhee wrote: I had previously raise a bug report that the PropertyUtils class doesn't recognise normal properties on a DynaBean (see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17036). This has been closed without action for very valid reasons, however, I am sill after a mechanism to access bean properties that are methods and not just object instances (as is the current BasicDynaBean implementation). As an example, I may wish to have a method such as public Long getUpTime( ) (which has to calculate its result) and access this method from the PropertyUtils class. I believe that this could be done by modifying the BasicDynaBean implementation or by creating a DynaBean implementation to allow for the registration of a user defined getter and setter methods for individual properties. This mechanism would not break any current DynaBean and PropertyUtils implementations. hi gavin this seems like the right way go about this. this isn't a really big itch for me but if you wanted to submit a patch and some test cases, i'll gladly take a look. see http://jakarta.apache.org/commons/patches.html. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VFS] exposing LocalFileName and it's associates
Howdy, I've found it very useful to reuse some of the functionality in various implementations of FileName outside of VFS. To do so with local files, I found it necessary to expose LocalFileName and some of it's associates with a public modifier. It wasn't necessary for GenericFileName, it's already public. Is there any chance of this change making into the VFS? The changes are below for more info: Index: src/java/org/apache/commons/vfs/provider/local/GenericFileNameParser.java === RCS file: /home/cvspublic/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/local/GenericFileNameParser.java,v retrieving revision 1.5 diff -u -r1.5 GenericFileNameParser.java --- src/java/org/apache/commons/vfs/provider/local/GenericFileNameParser.java 12 Feb 2003 07:56:15 - 1.5 +++ src/java/org/apache/commons/vfs/provider/local/GenericFileNameParser.java 31 Mar 2003 19:44:52 - @@ -63,7 +63,7 @@ * @author a href=mailto:[EMAIL PROTECTED]Adam Murdoch/a * @version $Revision: 1.3 $ $Date: 2002/07/05 04:08:18 $ */ -final class GenericFileNameParser +public final class GenericFileNameParser extends LocalFileNameParser { /** Index: src/java/org/apache/commons/vfs/provider/local/LocalFileName.java === RCS file: /home/cvspublic/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/local/LocalFileName.java,v retrieving revision 1.5 diff -u -r1.5 LocalFileName.java --- src/java/org/apache/commons/vfs/provider/local/LocalFileName.java 17 Feb 2003 09:22:15 - 1.5 +++ src/java/org/apache/commons/vfs/provider/local/LocalFileName.java 31 Mar 2003 19:44:52 - @@ -66,14 +66,14 @@ * @author a href=mailto:[EMAIL PROTECTED]Adam Murdoch/a * @version $Revision: 1.5 $ $Date: 2003/02/17 09:22:15 $ */ -class LocalFileName +public class LocalFileName extends AbstractFileName { private final String rootFile; -private LocalFileName( final String scheme, - final String rootFile, - final String path ) +protected LocalFileName( final String scheme, + final String rootFile, + final String path ) { super( scheme, path ); this.rootFile = rootFile; Index: src/java/org/apache/commons/vfs/provider/local/LocalFileNameParser.java === RCS file: /home/cvspublic/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/local/LocalFileNameParser.java,v retrieving revision 1.8 diff -u -r1.8 LocalFileNameParser.java --- src/java/org/apache/commons/vfs/provider/local/LocalFileNameParser.java 12 Feb 2003 07:56:15 - 1.8 +++ src/java/org/apache/commons/vfs/provider/local/LocalFileNameParser.java 31 Mar 2003 19:44:52 - @@ -64,7 +64,7 @@ * @author a href=mailto:[EMAIL PROTECTED]Adam Murdoch/a * @version $Revision: 1.5 $ $Date: 2002/03/09 10:31:30 $ */ -abstract class LocalFileNameParser +public abstract class LocalFileNameParser { /** * Determines if a name is an absolute file name. Index: src/java/org/apache/commons/vfs/provider/local/WindowsFileNameParser.java === RCS file: /home/cvspublic/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/local/WindowsFileNameParser.java,v retrieving revision 1.5 diff -u -r1.5 WindowsFileNameParser.java --- src/java/org/apache/commons/vfs/provider/local/WindowsFileNameParser.java 12 Feb 2003 07:56:15 - 1.5 +++ src/java/org/apache/commons/vfs/provider/local/WindowsFileNameParser.java 31 Mar 2003 19:44:52 - @@ -63,7 +63,7 @@ * @author a href=mailto:[EMAIL PROTECTED]Adam Murdoch/a * @version $Revision: 1.3 $ $Date: 2002/07/05 04:08:18 $ */ -final class WindowsFileNameParser +public final class WindowsFileNameParser extends LocalFileNameParser { /** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [COLLECTIONS] OrderedSet - Bugzilla # 18006
Sounds like a sensible addition to [collections]. At some point, one of the commiters will take a look (I've been on holiday for the last few days...). Stephen - Original Message - From: Henning P. Schmiedehausen [EMAIL PROTECTED] Newsgroups: hometree.jakarta.commons.dev To: [EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 10:10 AM Subject: [COLLECTIONS] OrderedSet - Bugzilla # 18006 Hi, some days ago I put a new class for the Collections component into bugzilla bug haven't received any feedback on this. So I resend here. :-) --- cut --- This is a class implementing the Set interface but keeping the sequence of the objects added to the set. The patch contains unit tests based on TestSet and it passed all the unit tests by the commons collections suite. It is fully documented and I could use it in the Turbine project. Please add! --- cut --- You can also get the following attachment from bugzilla: http://issues.apache.org/bugzilla/showattachment.cgi?attach_id=5343 Regards Henning diff --exclude=CVS -Nurb collections/src/java/org/apache/commons/collections/OrderedSet.java collections.p/src/java/org/apache/commons/collections/OrderedSet.java --- collections/src/java/org/apache/commons/collections/OrderedSet.java Thu Jan 1 01:00:00 1970 +++ collections.p/src/java/org/apache/commons/collections/OrderedSet.java Fri Mar 14 18:57:24 2003 @@ -0,0 +1,509 @@ +/* + * $Header$ + * $Revision$ + * $Date$ + * + * + * + * The Apache Software License, Version 1.1 + * + * Copyright (c) 1999-2002 The Apache Software Foundation. All rights + * reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in + *the documentation and/or other materials provided with the + *distribution. + * + * 3. The end-user documentation included with the redistribution, if + *any, must include the following acknowlegement: + * This product includes software developed by the + *Apache Software Foundation (http://www.apache.org/). + *Alternately, this acknowlegement may appear in the software itself, + *if and wherever such third-party acknowlegements normally appear. + * + * 4. The names The Jakarta Project, Commons, and Apache Software + *Foundation must not be used to endorse or promote products derived + *from this software without prior written permission. For written + *permission, please contact [EMAIL PROTECTED] + * + * 5. Products derived from this software may not be called Apache + *nor may Apache appear in their names without prior written + *permission of the Apache Group. + * + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR + * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT + * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * + * This software consists of voluntary contributions made by many + * individuals on behalf of the Apache Software Foundation. For more + * information on the Apache Software Foundation, please see + * http://www.apache.org/. + * + */ + +package org.apache.commons.collections; + +import java.util.ArrayList; +import java.util.Collection; +import java.util.ConcurrentModificationException; +import java.util.Iterator; +import java.util.List; +import java.util.Set; + +/** + * A [EMAIL PROTECTED] Collection} that contains each object only once but keeps the sequence + * of the objects like a list. + * + * @author a hef=mailto:[EMAIL PROTECTED]Henning P. Schmiedehausen/a + * @version $Id$ + */ + +public class OrderedSet +implements Set +{ +/** Internal list to hold the sequence of objects */ +private List setList = null; + +/** + * Constructs a new, empty Set. + */ +public OrderedSet() +{ +clear(); +} + +/** + * Constructs a
Re: [lang] StringEscapeUtils
From: Alex Chaffee / Purple Technology [EMAIL PROTECTED] There are a few nitpicky issues I'd like some consensus on: * StringEscapeUtils is a bit much to type for a quick static API call -- should we rename it EscapeUtils? It's not like there will be any other type of Escape... I prefer String EscapeUtils. * escapeJava now uses lowercase letters for hex codes. Are there any feelings about switching to capital letters? I prefer caps (like \uCAFE instead of \ucafe) but I could go either way. I prefer upper case * I made use of (and thus contributed) my StringPrintWriter class. Do you think it's useful enough to make it part of the public API (and add tests and docs for it)? private at the moment. This is connected with the need for a better StringBuffer class. * I think it'll be ready to roll for 2.0, but if we decide to postpone, I'll have to change the build.xml to exclude it from the jar. I would like to see it included. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/combo build.xml
craigmcc2003/03/31 15:09:41 Modified:combobuild.xml Log: Update betwixt tag to BETWIXT_1_0_ALPHA_1. Revision ChangesPath 1.7 +2 -2 jakarta-commons/combo/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-commons/combo/build.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- build.xml 11 Mar 2003 19:42:55 - 1.6 +++ build.xml 31 Mar 2003 23:09:41 - 1.7 @@ -133,7 +133,7 @@ !-- (above) when you update the CVS tag for one of these pacakges. -- property name=beanutils.tag value=BEANUTILS_1_6_1/ -property name=betwixt.tagvalue=/ !-- FIXME: release it -- +property name=betwixt.tagvalue=BETWIXT_1_0_ALPHA_1/ !-- FIXME: release it -- property name=cli.tagvalue=CLI_1_0/ property name=collections.tagvalue=COLLECTIONS_2_1/ property name=dbcp.tag value=DBCP_1_0/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] Status of typed collection patch?
I submitted a patch for typed Collections about 2 weeks ago, but I haven't noticed it in the cvs log... 1) I saw one vote of -0, but no others. Is that enough to veto it? 2) Was their something wrong/confusing about the patch itself? 3) Would the addition of methods such as CollectionUtils.predicatedCollection(Predicate), which will return a predicated Collection of a default type, still be considered useful? - 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 StatusLine.java
mbecke 2003/03/31 16:25:24 Modified:httpclient/src/java/org/apache/commons/httpclient HttpMethodBase.java StatusLine.java Log: Adds support for unusual HTTP status line returned by some servers. PR: 18439 Reviewed by: Jeff Dever and Oleg Kalnichevski Revision ChangesPath 1.127 +12 -6 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.126 retrieving revision 1.127 diff -u -r1.126 -r1.127 --- HttpMethodBase.java 27 Mar 2003 20:58:27 - 1.126 +++ HttpMethodBase.java 1 Apr 2003 00:25:24 - 1.127 @@ -2000,7 +2000,10 @@ //read out the HTTP status string String statusString = conn.readLine(); -while ((statusString != null) !statusString.startsWith(HTTP/)) { +while ((statusString != null) !statusString.startsWith(HTTP)) { +if (Wire.enabled()) { +Wire.input(statusString + \r\n); +} statusString = conn.readLine(); } if (statusString == null) { @@ -2008,7 +2011,7 @@ // response. Try again. throw new HttpRecoverableException(Error in parsing the status + line from the response: unable to find line starting with -+ \HTTP/\); ++ \HTTP\); } if (Wire.enabled()) { Wire.input(statusString + \r\n); @@ -2022,6 +2025,9 @@ http11 = false; } else if (httpVersion.equals(HTTP/1.1)) { http11 = true; +} else if (httpVersion.equals(HTTP)) { +// some servers do not specify the version correctly, we will just assume 1.0 +http11 = false; } else { throw new HttpException(Unrecognized server protocol: ' + httpVersion + '); 1.9 +6 -6 jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/StatusLine.java Index: StatusLine.java === RCS file: /home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/StatusLine.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- StatusLine.java 30 Jan 2003 05:01:54 - 1.8 +++ StatusLine.java 1 Apr 2003 00:25:24 - 1.9 @@ -121,9 +121,9 @@ //check validity of the Status-Line -if (!statusLine.startsWith(HTTP/)) { +if (!statusLine.startsWith(HTTP)) { throw new HttpException(Status-Line ' + statusLine -+ ' does not start with HTTP/); ++ ' does not start with HTTP); } //handle the HTTP-Version - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
resource message in validation
Hi, Is there any way to change / specify message resource bundle in validation.xml / validation-rules.xml. validation_1_1.dtd doesn't seem to define that ... (i guess it assumes arg0 key=registrationForm.firstname.displayname/ key from default message resource) or is there a way to change message resource in Plug-in class (may be extend it) Thanks Mahesh Bhagia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient HttpConnection.java
mbecke 2003/03/31 18:13:09 Modified:httpclient/src/java/org/apache/commons/httpclient HttpConnection.java Log: An attempt to make reusing HttpConnections more reliable. Connections are now closed whenever an exception occurs during writing. All exceptions that occur when writing to reused connections are now treated as recoverable. PR: 18507 Reviewed by: Oleg Kalnichevski Revision ChangesPath 1.52 +72 -34 jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java Index: HttpConnection.java === RCS file: /home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java,v retrieving revision 1.51 retrieving revision 1.52 diff -u -r1.51 -r1.52 --- HttpConnection.java 13 Mar 2003 01:33:07 - 1.51 +++ HttpConnection.java 1 Apr 2003 02:13:09 - 1.52 @@ -63,6 +63,7 @@ package org.apache.commons.httpclient; +import java.io.FilterOutputStream; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; @@ -100,7 +101,7 @@ * * @author Rod Waldhoff * @author Sean C. Sullivan - * @author Ortwin Glück + * @author Ortwin Gl�ck * @author a href=mailto:[EMAIL PROTECTED]Jeff Dever/a * @author a href=mailto:[EMAIL PROTECTED]Mike Bowler/a * @author a href=mailto:[EMAIL PROTECTED]Oleg Kalnichevski/a @@ -542,8 +543,9 @@ socket.setTcpNoDelay(soNodelay); socket.setSoTimeout(soTimeout); inputStream = socket.getInputStream(); -outputStream = socket.getOutputStream(); +outputStream = new WrappedOutputStream(socket.getOutputStream()); isOpen = true; +used = false; } catch (IOException e) { // Connection wasn't opened properly // so close everything out @@ -638,12 +640,11 @@ throws IOException, IllegalStateException { LOG.trace(enter HttpConnection.getRequestOutputStream(boolean)); -assertOpen(); +OutputStream out = getRequestOutputStream(); if (useChunking) { -return new ChunkedOutputStream(outputStream); -} else { -return outputStream; +out = new ChunkedOutputStream(out); } +return out; } /** @@ -743,6 +744,8 @@ try { outputStream.write(data, offset, length); +} catch (HttpRecoverableException hre) { +throw hre; } catch (SocketException se) { LOG.debug( HttpConnection: Socket exception while writing data, @@ -766,19 +769,8 @@ public void writeLine(byte[] data) throws IOException, IllegalStateException, HttpRecoverableException { LOG.trace(enter HttpConnection.writeLine(byte[])); - -assertOpen(); - -try { -outputStream.write(data); -writeLine(); -} catch (SocketException se) { -LOG.info(SocketException while writing data to output, se); -throw new HttpRecoverableException(se.toString()); -} catch (IOException ioe) { -LOG.info(IOException while writing data to output, ioe); -throw ioe; -} +write(data); +writeLine(); } /** @@ -792,16 +784,7 @@ public void writeLine() throws IOException, IllegalStateException, HttpRecoverableException { LOG.trace(enter HttpConnection.writeLine()); - -try { -outputStream.write(CRLF); -} catch (SocketException se) { -LOG.warn(HttpConnection: Socket exception while writing data, se); -throw new HttpRecoverableException(se.toString()); -} catch (IOException ioe) { -LOG.warn(HttpConnection: IO exception while writing data, ioe); -throw ioe; -} +write(CRLF); } /** @@ -922,6 +905,8 @@ // connections so we want to close them after one use close(); } +// we are assuming that the connection will only be released once used +used = true; if (httpConnectionManager != null) { httpConnectionManager.releaseConnection(this); } @@ -1046,6 +1031,55 @@ } } +/** + * A wrapper for output streams that closes the connection and converts to recoverable + * exceptions as appropriable when an IOException occurs. + */ +private class WrappedOutputStream extends FilterOutputStream { + +/** + * @param out the output stream to wrap + */ +public
Re: Adding TERMINAL-TYPE option to TelnetClient
On Sun, 30 Mar 2003 20:01:27 +0200, [EMAIL PROTECTED] [EMAIL PROTECTED] said: Maybe converting the examples to documentation is the best thing to do. Alternatively, I could modify the TelnetClientExample3 to output the spy on a file instead of waiting a second telnet connection and spying the primary connection on the second connection as it does at the moment. What do you think about? Writing to a file sounds reasonable for the example. If you want to add documentation that would also be great. Maybe a how-to or faq of sorts. You could just provide xdocs or use the apache wiki. what should the test do in case an I/O exception occurs? (throw the exception, catch it silently...?) I mean, how is it normally managed an error condition in the test? I'll try to restructure TelnetClientTest not to do so much in the setUp(). The general convention when there is an error condition that the test is not testing for is to let the exceptions fly. Junit will ultimately catch all the exceptions and report it as an *error* and not a *failure*. Generally I don't catch exceptions in my test cases unless I'm explicitly testing for the throwing of an exception. * The code style conventions should be followed. ( minor ) Could you be more specific? I tried to keep up to the standard coding style used in commons net, which is fairly low :-). I'll try to add javadoc comments to each new class and method, but I don't have the time to fully comment the code... http://jakarta.apache.org/commons/net/code-standards.html I know there are violations in the current code base, the checkstyle report shows that. But for new stuff we should try to stick to the above standard when possible and verify with checkstyle. The functional tests are nice to see in there, but I suppose we'll need to find out a way to skip them at compile time for users who build but don't have access to get to the internet. Two solutions for TelnetClientFunctionalTest: 1) we could try to skip it if you don't have connection to the internet, but in this case it would be a test that is always succeeding! I think that the running of the fuctional tests could require a connection to a real server over a network. I just think that the build shouldn't depend on the functional tests. This is something that I've been wanting to add to Maven for some time. An additional goal for functional tests so they can be removed from the normal *unit* test run that happens at each build. I was thinking of just a different goal, like maven test:ftests or something. For now I suppose we could exclude the tests that require the net and just provide directions to run single tests with maven to run those that require the net. I'll still take a look at the tcpspy stuff as I get time. Thanks again. jb -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14120] - [FileUpload] uploading files with non-ASCII filenames
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14120. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14120 [FileUpload] uploading files with non-ASCII filenames --- Additional Comments From [EMAIL PROTECTED] 2003-04-01 04:22 --- It'll be fixed when I get to it. Right now, I'm working on some other fixes that affect a lot of the code base. Once that is done, I will be looking into this one again. Please be patient. ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18550] New: - Add defaultTransactionIsolation to BasicDataSource
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18550. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18550 Add defaultTransactionIsolation to BasicDataSource Summary: Add defaultTransactionIsolation to BasicDataSource Product: Commons Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Dbcp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] BasicDataSource currently supports properties like defaultReadOnly and defaultAutoCommit for the Connection objects it returns. Is it feasible/useful to define a defaultTransactionIsolation property that would call Connection.setTransactionIsolation() with an appropriate constant? AFAIK, the JDBC spec doesn't define what the default transaction level should be for new Connections so this would be a good way to remove an implementation detail from JDBC coding. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17678] - DBCP Fails silently in many cases
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17678. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17678 DBCP Fails silently in many cases --- Additional Comments From [EMAIL PROTECTED] 2003-04-01 06:00 --- It's confusing why a method like PoolableConnectionFactory.passivateObject() declares that it throws Exception and then proceeds to swallow the SQLExceptions. Is there a valid reason that it should swallow them? IMO, any code like: } catch(SQLException e) { ; // ignored } should be refactored to throw or log the exception. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18355] - HttpState cannot differentiate credentials for different hosts with same Realm names
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18355. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18355 HttpState cannot differentiate credentials for different hosts with same Realm names --- Additional Comments From [EMAIL PROTECTED] 2003-03-31 08:25 --- Oleg, Were you working on this or should I take a look at it? I already have some code for this that could be fairly easily updated to the current HttpClient. One question that remains for me is what the new search order should be. The two most obvious answers to me are: 1. Expect to always get a realm and a host or null for both and just provide backwards compatibility for setting just the realm. The search order would then be: a. realm host b. realm c. null 2. Provide maximum flexibility. I'd imagine the search order to then be: a. realm host b. host c. realm d. null Though the order of searching for host and realm is quite arbitrary, I've generally found that people know what host they are connecting to better than they know the realm. Also, there is the security consideration of sending the credentials to the wrong host. I don't have any particular preference for the order though. Sorry if I missed part of the discussion of this on-list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18507] - reusing connections is unreliable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18507. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18507 reusing connections is unreliable --- Additional Comments From [EMAIL PROTECTED] 2003-03-31 20:13 --- Makes sense to me Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18355] - HttpState cannot differentiate credentials for different hosts with same Realm names
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18355. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18355 HttpState cannot differentiate credentials for different hosts with same Realm names --- Additional Comments From [EMAIL PROTECTED] 2003-03-31 22:54 --- Oleg, I've moved the code I have over to the latest HttpClient and from memory it matches the search pattern you've outlined below. It doesn't consider host.domain.com to be the same as .domain.com and I generally feel that doing so would be too much overhead for little gain. We could add this functionality easily enough in the future if requested anyway without breaking compatibility (semantic compatibility would be maintained by only matching domains with the . in front so it wouldn't match by accident). Unfortunately, the code is at home and I'm at work so I won't be able to post it until tonight. The code is simple anyway so feel free to go ahead and just use what you have or write your own in the mean time anyway. Generally though it may be better if you focus on the more technical issues where your level of knowledge of HttpClient is required. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18439] - Unusual Http status line
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18439. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18439 Unusual Http status line [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18507] - reusing connections is unreliable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18507. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18507 reusing connections is unreliable [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18355] - HttpState cannot differentiate credentials for different hosts with same Realm names
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18355. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18355 HttpState cannot differentiate credentials for different hosts with same Realm names --- Additional Comments From [EMAIL PROTECTED] 2003-03-31 19:03 --- Adrian I have already started working on this bug. However, if you feel like taking the lead, just let me know. Credentials matching algorithm is exactly the sticking point. I have been thinking whether we should make an assumption of an authentication realm being related to just one host or should we assume that it could span across several hosts in a domain? For instance, should myhost.mydomain.com match .mydomain.com when picking credentials for an authentication realm? Let me know what is your take on this. Here's how I see the search order: codenull/code host should match any host. codenull/code realm should match any realm. We start searching by trying to find an exact match '[EMAIL PROTECTED]'. If that yields no results, '[EMAIL PROTECTED]' should be tried next, followed by '[EMAIL PROTECTED]' if unsuccessful. If none of this results in a match, default credentials '[EMAIL PROTECTED]' should be used. It's not the most elegant or intuitive scheme, but it is the only one I can think of which would allow us to stay backward-compatible. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]