[GUMP@lsd]: jelly-tags/commons-jelly-tags-jetty failed
Project: commons-jelly-tags-jetty State: Failed URL: http://lsd.student.utwente.nl/gump/jelly-tags/commons-jelly-tags-jetty.html - G U M P Y Annotations: - Error - Failed with reason build failed - G U M P Y Work Name: build_jelly-tags_commons-jelly-tags-jetty (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 6 seconds Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/data/gump/xml-xerces2/java/build/xercesImpl.jar:/data/gump/xml-xerces2/java/build/xmlParserAPIs.jar org.apache.tools.ant.Main -Dbuild.clonevm=true -Dgump.merge=/data/gump/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-jetty-20040131 jar [Working Directory: /data/gump/jelly-tags/jetty] - [javac] symbol : class OutputStreamLogSink [javac] location: class org.apache.commons.jelly.tags.jetty.JettyHttpServerTag [javac] private static OutputStreamLogSink _logSink; [javac]^ [javac] /data/gump/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/SecurityHandlerTag.java:71: cannot resolve symbol [javac] symbol : class Authenticator [javac] location: class org.mortbay.http.SecurityConstraint [javac] import org.mortbay.http.SecurityConstraint.Authenticator; [javac]^ [javac] /data/gump/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/SecurityHandlerTag.java:75: cannot resolve symbol [javac] symbol : class Code [javac] location: package util [javac] import org.mortbay.util.Code; [javac] ^ [javac] /data/gump/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/JettyHttpServerTag.java:118: cannot resolve symbol [javac] symbol : class OutputStreamLogSink [javac] location: class org.apache.commons.jelly.tags.jetty.JettyHttpServerTag [javac] _logSink = new OutputStreamLogSink(DEFAULT_LOG_FILE); [javac]^ [javac] /data/gump/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/JettyHttpServerTag.java:120: cannot resolve symbol [javac] symbol : variable Log [javac] location: class org.apache.commons.jelly.tags.jetty.JettyHttpServerTag [javac] Log.instance().add(_logSink); [javac] ^ [javac] /data/gump/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/SecurityHandlerTag.java:236: cannot resolve symbol [javac] symbol : variable Code [javac] location: class org.apache.commons.jelly.tags.jetty.SecurityHandlerTag [javac] Code.warning(Unknown user-data-constraint:+guarantee); [javac] ^ [javac] /data/gump/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/SecurityHandlerTag.java:281: cannot resolve symbol [javac] symbol : class Authenticator [javac] location: class org.apache.commons.jelly.tags.jetty.SecurityHandlerTag [javac] Authenticator authenticator=null; [javac] ^ [javac] /data/gump/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/SecurityHandlerTag.java:293: cannot resolve symbol [javac] symbol : variable Code [javac] location: class org.apache.commons.jelly.tags.jetty.SecurityHandlerTag [javac] Code.warning(UNKNOWN AUTH METHOD: +m); [javac] ^ [javac] /data/gump/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/SecurityHandlerTag.java:306: cannot resolve symbol [javac] symbol : variable Code [javac] location: class org.apache.commons.jelly.tags.jetty.SecurityHandlerTag [javac] Code.warning(FORM Authentication miss-configured); [javac] ^ [javac] 13 errors BUILD FAILED /data/gump/jelly-tags/jetty/build.xml:31: Compile failed; see the compiler error output for details. Total time: 4 seconds - - G U M P Y RSS: http://lsd.student.utwente.nl/gump/jelly-tags/commons-jelly-tags-jetty.rss | Atom: http://lsd.student.utwente.nl/gump/jelly-tags/commons-jelly-tags-jetty.atom -- Gump http://jakarta.apache.org/gump [lsd] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@lsd]: jelly-tags/commons-jelly-tags-junit failed
Project: commons-jelly-tags-junit
State: Failed
URL: http://lsd.student.utwente.nl/gump/jelly-tags/commons-jelly-tags-junit.html
- G U M P Y
Annotations:
- Error - Failed with reason build failed
- G U M P Y
Work Name: build_jelly-tags_commons-jelly-tags-junit (Type: Build)
State: Failed
Elapsed: 0 hours, 0 minutes, 8 seconds
Command Line: java -Djava.awt.headless=true
-Xbootclasspath/p:/data/gump/xml-xerces2/java/build/xercesImpl.jar:/data/gump/xml-xerces2/java/build/xmlParserAPIs.jar
org.apache.tools.ant.Main -Dbuild.clonevm=true
-Dgump.merge=/data/gump/gump/work/merge.xml -Dbuild.sysclasspath=only
-Dfinal.name=commons-jelly-tags-junit-20040131 jar
[Working Directory: /data/gump/jelly-tags/junit]
-
[junit]
[junit] The exception was:
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:31:-1:
lt;test:failgt;
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:31:-1:
lt;test:failgt; This should always fail
[junit]
[junit]
[junit] The exception was:
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:47:-1:
lt;test:assertEqualsgt;
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:47:-1:
lt;test:assertEqualsgt; This should always fail expected:[def] but was:[abc]
[junit] Expected expression: def
[junit] Actual expression: ${foo}
[junit] Tests run: 4, Failures: 0, Errors: 1, Time elapsed: 0.278 sec
[junit] Testsuite: org.apache.commons.jelly.tags.junit.TestJUnit
[junit] Tests run: 4, Failures: 0, Errors: 1, Time elapsed: 0.278 sec
[junit] - Standard Error -
[junit] Jan 31, 2004 6:41:25 AM
org.apache.commons.jelly.tags.junit.AssertThrowsTag getThrowableClass
[junit] WARNING: The class: java.lang.Class is not an Exception class.
[junit] Jan 31, 2004 6:41:25 AM
org.apache.commons.jelly.tags.junit.AssertThrowsTag getThrowableClass
[junit] WARNING: Could not find exception class: foo.bar.Baz
[junit] - ---
[junit] Testcase: assertTests took 0.116 sec
[junit] Testcase: failTests took 0.015 sec
[junit] Testcase: assertEqualTests took 0.014 sec
[junit] Testcase: assertThrowsTests took 0.099 sec
[junit] Caused an ERROR
[junit]
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:103:-1:
test:assert
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:103:-1:
test:assert columnNumber not set. Assertion failed while evaluating test:
${ex.columnNumber gt 0}
[junit] org.apache.commons.jelly.JellyTagException:
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:103:-1:
test:assert
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:103:-1:
test:assert columnNumber not set. Assertion failed while evaluating test:
${ex.columnNumber gt 0}
[junit] at
org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:707)
[junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:296)
[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.apache.commons.jelly.tags.junit.JellyAssertionFailedError:
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:103:-1:
test:assert columnNumber not set. Assertion failed while evaluating test:
${ex.columnNumber gt 0}
[junit] at
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:85)
[junit] at
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:96)
[junit] at
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:104)
[junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
[junit] ... 11 more
[junit] Root cause
[junit] org.apache.commons.jelly.tags.junit.JellyAssertionFailedError:
file:/data/gump/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:103:-1:
test:assert columnNumber not set. Assertion failed while evaluating test:
${ex.columnNumber gt 0}
[junit] at
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:85)
[junit] at
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:96)
[junit
[GUMP@lsd]: directory-naming/directory-naming failed
Project: directory-naming State: Failed URL: http://lsd.student.utwente.nl/gump/directory-naming/directory-naming.html - G U M P Y Annotations: - Error - Failed with reason build failed - G U M P Y Work Name: build_directory-naming_directory-naming (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 0 seconds Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/data/gump/xml-xerces2/java/build/xercesImpl.jar:/data/gump/xml-xerces2/java/build/xmlParserAPIs.jar org.apache.tools.ant.Main -Dbuild.clonevm=true -Dgump.merge=/data/gump/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=directory-naming-20040131 -f build.xml dist [Working Directory: /data/gump/directory-naming] - Buildfile: build.xml does not exist! Build failed - - G U M P Y RSS: http://lsd.student.utwente.nl/gump/directory-naming/directory-naming.rss | Atom: http://lsd.student.utwente.nl/gump/directory-naming/directory-naming.atom -- Gump http://jakarta.apache.org/gump [lsd] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Array concat?
From: Tim Reilly [EMAIL PROTECTED]
Object[] anArray = {one, two, three};
ArrayUtil.join(anArray, , );
outputs one, two, three
The StringUtils.join() method already handles objects as above. So no change
is required I believe.
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang ArrayUtils.java
-1 An arbitrary layout based on the alphabet is unsuitable. A related methods together is much better. Hashcode should be near Equals. Contains should be near IndexOf and LastIndexOf.. Also, this change makes it impossible to determine what really changed between versions. I want 2.0 of lang and 3.0 of collections to represent that fresh start where they are actively maintained (added to/bug fixes), rather than actively developed (refactored/added to/bug fixes). Stephen - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 30, 2004 2:12 AM Subject: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang ArrayUtils.java ggregory2004/01/29 18:12:22 Modified:lang/src/java/org/apache/commons/lang ArrayUtils.java Log: Sort members (Eclipse defaults). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[chain] Contextes and Attribute-Property Transparency
Hi all.
I have a question about the context implementation of the commons-chain
project.
I think it is a good way to have JavaBean Properties in a context like:
private User user;
with get()- and set()- Methods like
public User getUser() ... and so one
So you have type-safeness.
What is the benefit of Attribute-Property Transparency (I don't hear
this concept before). You get the attributes via
User user = (User) context.get(getUser());
where getUser() in this case returns a string to have access to the
propery. The benefit is to avoid having fixed strings like
User user = (User) context.get(user);
Now you have the handicap, that you must cast the value into the real
type and all benefit of having JavaBean properties are away. The other
way I would prefer.
Regardless having JavaBean properties or some untyped values in the
Map: Every values will store in the same Map. Than you have a nice
possibility to clone contextes in an easy way.
Example:
class myContext extends Context {
private String userString = user;
// --- Property User
private User user;
public User getUser() {
return (User) get(userString);
}
public void setUser(User user) {
put(userString, user);
}
}
Perhaps somebody can me more explain about the benefits of the current
implementation.
Manfred
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang ArrayUtils.java
scolebourne2004/01/31 01:57:39 Modified:lang/src/java/org/apache/commons/lang ArrayUtils.java Log: Rollback of sort of members Revision ChangesPath 1.38 +1656 -1656jakarta-commons/lang/src/java/org/apache/commons/lang/ArrayUtils.java http://cvs.apache.org/viewcvs/jakarta-commons/lang/src/java/org/apache/commons/lang/ArrayUtils.java.diff?r1=1.37r2=1.38 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang][collections] Project stage
I wanted to see if my own mental classification fitted with others on lang and collections. I am kindof splitting stages of a project into categories like these: Experimemtation - where new ideas are tried Initial development - leading up to a 1.0 release Active development - adding and refactoring now you've used it Active maintanance - adding, but not refactoring Passive maintainance - responding to problems, rather than seeking to add new Asleep - Finished with, various reasons Whether this coresponds with any proper management scheme I don't know, but I reckon most if not all commons components could be classified using it. To do so might be useful to our users. I believe that [lang] is in Active maintainance since 2.0. I believe that [collections] went straight from Active development at 2.1 to Passive maintainance immediately after the 2.1 release which caused problems. Hence the last 6 months back in Active development have annoyed some. Collections 3.0 should represent the move to Active maintainance (ie. I hope we get a 3.1 at some point in the next 6 months). If people would find a classification like this useful, I could add it to the commons website, but I guess it might be controversial. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/util StringIdentifierFactory.java IdentifierUtils.java IdentifierFactory.java LongIdentifierFactory.java
scolebourne2004/01/31 02:12:56
Modified:lang/src/java/org/apache/commons/lang/util
StringIdentifierFactory.java IdentifierUtils.java
IdentifierFactory.java LongIdentifierFactory.java
Log:
Deprecate id code prior to removal
Revision ChangesPath
1.3 +1 -6
jakarta-commons/lang/src/java/org/apache/commons/lang/util/StringIdentifierFactory.java
Index: StringIdentifierFactory.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/util/StringIdentifierFactory.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- StringIdentifierFactory.java 18 Aug 2003 02:22:25 - 1.2
+++ StringIdentifierFactory.java 31 Jan 2004 10:12:56 - 1.3
@@ -54,12 +54,7 @@
package org.apache.commons.lang.util;
/**
- * pcodeStringIdentifierFactory/code defines a simple interface for
- * String based identifier generation./p
- *
- * @author Stephen Colebourne
- * @since 2.0
- * @version $Id$
+ * @deprecated WILL BE DELETED SOON. See Commons ID in the sandbox.
*/
public interface StringIdentifierFactory extends IdentifierFactory {
1.8 +1 -11
jakarta-commons/lang/src/java/org/apache/commons/lang/util/IdentifierUtils.java
Index: IdentifierUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/util/IdentifierUtils.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- IdentifierUtils.java 18 Aug 2003 02:22:25 - 1.7
+++ IdentifierUtils.java 31 Jan 2004 10:12:56 - 1.8
@@ -57,17 +57,7 @@
import java.util.Random;
/**
- * pcodeIdentifierUtils/code provides a number of different identifier
- * reference implementations./p
- *
- * pAll the identifer factories are serializable and synchronized.
- * The factories all implement one of the factory interfaces defined in this
- * package. This allows you to obtain and use multiple factories for
- * different reasons./p
- *
- * @author Stephen Colebourne
- * @since 2.0
- * @version $Id$
+ * @deprecated WILL BE DELETED SOON. See Commons ID in the sandbox.
*/
public class IdentifierUtils {
1.3 +1 -6
jakarta-commons/lang/src/java/org/apache/commons/lang/util/IdentifierFactory.java
Index: IdentifierFactory.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/util/IdentifierFactory.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- IdentifierFactory.java18 Aug 2003 02:22:25 - 1.2
+++ IdentifierFactory.java31 Jan 2004 10:12:56 - 1.3
@@ -54,12 +54,7 @@
package org.apache.commons.lang.util;
/**
- * pcodeIdentifierFactory/code defines a simple interface for
- * identifier generation./p
- *
- * @author Stephen Colebourne
- * @since 2.0
- * @version $Id$
+ * @deprecated WILL BE DELETED SOON. See Commons ID in the sandbox.
*/
public interface IdentifierFactory {
1.3 +1 -6
jakarta-commons/lang/src/java/org/apache/commons/lang/util/LongIdentifierFactory.java
Index: LongIdentifierFactory.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/util/LongIdentifierFactory.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- LongIdentifierFactory.java18 Aug 2003 02:22:25 - 1.2
+++ LongIdentifierFactory.java31 Jan 2004 10:12:56 - 1.3
@@ -54,12 +54,7 @@
package org.apache.commons.lang.util;
/**
- * pcodeLongIdentifierFactory/code defines a simple interface for
- * Long based identifier generation./p
- *
- * @author Stephen Colebourne
- * @since 2.0
- * @version $Id$
+ * @deprecated WILL BE DELETED SOON. See Commons ID in the sandbox.
*/
public interface LongIdentifierFactory extends IdentifierFactory {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CLI] Refactoring plans
Hi Rob, This is just a quick heads up to let you know what I've got planned in the next few days for the cli2 package (on the ROXSPRING branch) it's mostly refactoring and minor stuff before I get back to experimenting with option paths. 1) Refactor CommandLine. This class is getting pretty big and I'm hoping I can rationalise it a little, firstly by extracting readonly and writeable interfaces, and then probably moving some (potential) functionality to decorators. CommandLine interface WriteableCommandLine interface CommandLineImpl implements both of above TypedCommandLine decorates CommandLine (provide typed getValue() varients) DefaultingCommandLine decorates CommandLine (defaults provided by alternative CommandLine or maybe configuration?) Sounds good. 2) Repackage some cli2. Currently there are 33 classes/interfaces in the cli2 package and I'd like to reduce that. I'm not sure which direction I'll end up going but possibilities include the following: o.a.c.cli2.api - the interfaces and OptionException o.a.c.cli2.impl - the implementations and other exceptions o.a.c.cli2.commandline - the refactored CommandLine and friends o.a.c.cli2.help - Help* Not sure about creating the api package. Why not keep these interfaces in the cli2 package? An alternative would include subpackages based on the argument/group/parent separation but I don't see that getting us anywhere. Nah, the first suggestion is better. 3) Reformat some code. There is a slight mix of code formatting involved currently and I'd like to pick one and bring the source in line using either checkstyle and some nagging or jalopy. Currently we appear to have slightly fewer checkstyle errors if we use the sun settings rather than turbine (5290 vs5640) or we could hack at a checkstyle config and come to a custom conclusion. I think I'm leaning towards to sun style but am open to suggestions. Fine, lets pick one (I'm not fussed about which one is chosen). Lets stick to it then. If you get the chance you could change the license to version 2.0 as well. This license can be included by reference in each source file. -John K - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang CharUtilsTest.java LangTestSuite.java
scolebourne2004/01/31 05:00:07
Modified:lang/src/test/org/apache/commons/lang LangTestSuite.java
Added: lang/src/java/org/apache/commons/lang CharUtils.java
lang/src/test/org/apache/commons/lang CharUtilsTest.java
Log:
Add CharUtils classes
Revision ChangesPath
1.1
jakarta-commons/lang/src/java/org/apache/commons/lang/CharUtils.java
Index: CharUtils.java
===
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowledgement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgement may appear in the software itself,
*if and wherever such third-party acknowledgements 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 Software Foundation.
*
* 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.lang;
/**
* pOperations on char primitives and Char objects./p
*
* pThis class tries to handle codenull/code input gracefully.
* An exception will not be thrown for a codenull/code input.
* Each method documents its behaviour in more detail./p
*
* @author Stephen Colebourne
* @since 2.1
* @version $Id: CharUtils.java,v 1.1 2004/01/31 13:00:07 scolebourne Exp $
*/
public class CharUtils {
private static final String CHAR_STRING =
\u\u0001\u0002\u0003\u0004\u0005\u0006\u0007 +
\b\t\n\u000b\f\r\u000e\u000f +
\u0010\u0011\u0012\u0013\u0014\u0015\u0016\u0017 +
\u0018\u0019\u001a\u001b\u001c\u001d\u001e\u001f +
\u0020\u0021\\u0023\u0024\u0025\u0026\u0027 +
\u0028\u0029\u002a\u002b\u002c\u002d\u002e\u002f +
\u0030\u0031\u0032\u0033\u0034\u0035\u0036\u0037 +
\u0038\u0039\u003a\u003b\u003c\u003d\u003e\u003f +
\u0040\u0041\u0042\u0043\u0044\u0045\u0046\u0047 +
\u0048\u0049\u004a\u004b\u004c\u004d\u004e\u004f +
\u0050\u0051\u0052\u0053\u0054\u0055\u0056\u0057 +
\u0058\u0059\u005a\u005b\\\u005d\u005e\u005f +
\u0060\u0061\u0062\u0063\u0064\u0065\u0066\u0067 +
\u0068\u0069\u006a\u006b\u006c\u006d\u006e\u006f +
\u0070\u0071\u0072\u0073\u0074\u0075\u0076\u0077 +
\u0078\u0079\u007a\u007b\u007c\u007d\u007e\u007f;
private static final String[] CHAR_STRING_ARRAY = new String[128];
private static final Character[] CHAR_ARRAY = new Character[128];
static {
for (int i = 127; i = 0; i--) {
CHAR_STRING_ARRAY[i] = CHAR_STRING.substring(i, i + 1);
new project proposal: XML based glue language/component assembly UPDATE
hi folks, i just seperated the container engine from my project, so the container would be now ready to be included to the sandbox. the container package is now de.molimo.container. the project package is: http://sourceforge.net/projects/webzap the new stuff is in the cvs - just checkout HEAD. i think this is really a very interessting thing for component assembly, so hopefully some people are interessted. you may contact for any reasons concerning the project (marriage proposals are not included - although beautiful women may try...) more information about the project below... cheers, marcus -Ursprüngliche Nachricht- Von: Marcus Schießer [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 20. Januar 2004 15:48 An: '[EMAIL PROTECTED]' Betreff: new project proposal: XML based glue language/component assembly hi folks, noel bergman from the incubator mailing list gave me the hint, that my project would fit to the commons project. i wrote a versatile container for software components that could be embedded in different frameworks. i am using this right now as a container for web components (container embedded in a servlet engine). but the project could also be seen as an XML based glue language for component assembly, therefore noel thought the commons project would fit. to get a community for the project, i would very much like to donate my project to yours, so hopefully you are interessted. For more information about the project consult the web site under: www.unc.de/webzap.html. please keep in mind, that webzap is not the container/glue language itself, but is using the container (needs to be extracted from that project). there is also a paper available which explains the technology of the container: http://www.unc.de/downloads/webzap_paper_preview.pdf don't hesitate to contact me for any comments. any help is appreciated, really ;) cheers, marcus the message from noel: Marcus, If this is a relatively small set of code performing XML directed assembly, it might be worth presenting it to [EMAIL PROTECTED] for inclusion within the sandbox. The code does sound useful, and there may be enough folks interested in it (plus the two current developers you mentioned to me). If there is interest in Jakarta Commons, and I think there might be, then it should not take too long to pass it through the Incubator to Jakarta Commons. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema SimplestBean.java
rdonkin 2004/01/31 07:37:21 Added: betwixt/src/test/org/apache/commons/betwixt/schema Tag: REFACTORING-BRANCH_2004-01-13 SimplestBean.java Log: Bean used for testing schema generation. Revision ChangesPath No revision No revision 1.1.2.1 +80 -0 jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema/Attic/SimplestBean.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/schema TestSchemaTranscriber.java
rdonkin 2004/01/31 07:38:09
Modified:betwixt/src/java/org/apache/commons/betwixt/schema Tag:
REFACTORING-BRANCH_2004-01-13 Attribute.java
ComplexType.java Element.java Schema.java
SimpleType.java
betwixt/src/test/org/apache/commons/betwixt/schema Tag:
REFACTORING-BRANCH_2004-01-13
TestSchemaTranscriber.java
Log:
Added support for creation of models for very simple schema.
Revision ChangesPath
No revision
No revision
1.1.2.2 +12 -4
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema/Attic/Attribute.java
Index: Attribute.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema/Attic/Attribute.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- Attribute.java18 Jan 2004 12:34:21 - 1.1.2.1
+++ Attribute.java31 Jan 2004 15:38:09 - 1.1.2.2
@@ -119,6 +119,10 @@
type = string;
}
+public int hashCode() {
+return 0;
+}
+
public boolean equals(Object obj) {
boolean result = false;
if (obj instanceof Attribute) {
@@ -148,4 +152,8 @@
return result;
}
+public String toString() {
+return xsd:attribute name=' + name + ' type=' + type + '/;
+}
+
}
1.1.2.3 +33 -6
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema/Attic/ComplexType.java
Index: ComplexType.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema/Attic/ComplexType.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- ComplexType.java 19 Jan 2004 21:19:36 - 1.1.2.2
+++ ComplexType.java 31 Jan 2004 15:38:09 - 1.1.2.3
@@ -62,6 +62,7 @@
package org.apache.commons.betwixt.schema;
import java.util.ArrayList;
+import java.util.Iterator;
import java.util.List;
import org.apache.commons.betwixt.AttributeDescriptor;
@@ -90,7 +91,7 @@
* @param elementDescriptor
*/
public ComplexType(ElementDescriptor elementDescriptor) {
-setName(elementDescriptor.getClass().getName());
+setName(elementDescriptor.getPropertyType().getName());
AttributeDescriptor[] attributeDescriptors =
elementDescriptor.getAttributeDescriptors();
for (int i=0,length=attributeDescriptors.length; ilength ; i++) {
//TODO: need to think about computing schema types from descriptors
@@ -98,7 +99,11 @@
attributes.add(new Attribute(attributeDescriptors[i]));
}
-
+ElementDescriptor[] elementDescriptors =
elementDescriptor.getElementDescriptors();
+//TODO: add support for referenced complex classes
+for (int i=0,length=elementDescriptors.length; ilength ; i++) {
+elements.add(new Element(elementDescriptors[i]));
+}
}
/**
@@ -161,6 +166,10 @@
return result;
}
+public int hashCode() {
+return 0;
+}
+
/**
* Null safe equals method
* @param one
@@ -178,5 +187,23 @@
}
return result;
+ }
+
+ public String toString() {
+ StringBuffer buffer = new StringBuffer();
+ buffer.append(xsd:complexType name=');
+ buffer.append(name);
+ buffer.append(');
+ buffer.append(xsd:sequence);
+ for (Iterator it=elements.iterator(); it.hasNext();) {
+buffer.append(it.next());
+ }
+ buffer.append(/xsd:sequence);
+
+ for (Iterator it=attributes.iterator(); it.hasNext();) {
+buffer.append(it.next());
+ }
+ buffer.append(/xsd:complexType);
+ return buffer.toString();
}
}
1.1.2.2 +25 -5
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema/Attic/Element.java
Index: Element.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/schema/Attic/Element.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- Element.java 18 Jan 2004 12:35:57 - 1.1.2.1
+++ Element.java 31 Jan 2004 15:38:09 - 1.1.2.2
@@ -88,7 +88,7 @@
}
public Element(ElementDescriptor elementDescriptor) {
-
+
[math] Re: Straw man release plan
Hello, cut/ 2. Use Mark's magical maven release-generator to cut a 1.0-B1 release including everything currently in CVS other than the /experimental tree. (Confidence intervals, the Bootstrap and Multiple Regression will have to wait until 1.1.) As I understand, math is now in a freezed state and it is better not to submit any new code (except of that, which is needed to have 1.0 ready obviously)? I have some bootstrap and standard error code ready, but I guess it's better to wait with submission until 1.0 will be out. Piotr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Re: Straw man release plan
Piotr Kochan'ski wrote: Hello, cut/ 2. Use Mark's magical maven release-generator to cut a 1.0-B1 release including everything currently in CVS other than the /experimental tree. (Confidence intervals, the Bootstrap and Multiple Regression will have to wait until 1.1.) As I understand, math is now in a freezed state and it is better not to submit any new code (except of that, which is needed to have 1.0 ready obviously)? Frozen is a bit strong. My preference would be to hold off on confidence intervals and the bootstrap until we get 1.0 out. I suppose we could add the bootstrap by itself, but I think it would be better to add it as part of a more general solution for resampling-based inference (incl non-parametric conf. intervals) and that will require some discussion. Thinking about how this will eventually work, it has occurred to me that EmpiricalDistribution could be used to digest / represent bootstrap distributions. Since we want the interface for EmpiricalDistribution to be complete for 1.0, we need to make sure that bootstrap data can be loaded into EmpiricalDistribution conveniently (if this makes sense), so I have been thinking about adding load() methods to EmpiricalDistribution that take double[] arrays and streams as values, as well as an addValue() method. Does this make sense? I would also appreciate any comments / patches on how to improve the EmpiricalDistribution interface or EmpiricalDistributionImpl. If refactoring or even holding this from the release are in order, I want to make sure that we do it. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] Contextes and Attribute-Property Transparency
Quoting Manfred Wolff [EMAIL PROTECTED]:
Hi all.
I have a question about the context implementation of the commons-chain
project.
I think it is a good way to have JavaBean Properties in a context like:
private User user;
with get()- and set()- Methods like
public User getUser() ... and so one
So you have type-safeness.
Agreed. You'll see that pattern used in specialized Context implementations
that are used in specific scenarios, such as the WebContext that is designed
for use in web applications, and has built in properties to return things like
a Map of request parameters.
What is the benefit of Attribute-Property Transparency (I don't hear
this concept before). You get the attributes via
User user = (User) context.get(getUser());
where getUser() in this case returns a string to have access to the
propery. The benefit is to avoid having fixed strings like
User user = (User) context.get(user);
Now you have the handicap, that you must cast the value into the real
type and all benefit of having JavaBean properties are away. The other
way I would prefer.
Regardless having JavaBean properties or some untyped values in the
Map: Every values will store in the same Map. Than you have a nice
possibility to clone contextes in an easy way.
Example:
class myContext extends Context {
private String userString = user;
// --- Property User
private User user;
public User getUser() {
return (User) get(userString);
}
public void setUser(User user) {
put(userString, user);
}
}
Perhaps somebody can me more explain about the benefits of the current
implementation.
One of the popular recent themes in discussions about software architecture is
decomposing complex things into little things, and factoring them for reuse.
The transparency supports reusability, if you wish to take advantage of it.
Let's assume you are trying to combine a bunch of sets of Command
implementations from separate third party libraries into a single chain. If
each of those sets of Commands were programmed to the simple
org.apache.commons.chain.Context API, and rely on transparency to get and set
their values, your Command will operate correctly with *any* implementation of
Context. On the other hand, if you program your Commands to use your own
specialized Context implementation, then the only other Command implementations
you can interoperate with are those who use (or subclass) that same Context
implementation.
From a design perspective, it's not a totally either-or decision ... it's quite
reasonable to use both styles, and/or to create inheritance hierarchies of
Context implementations that add some typesafe properties along the way. If
you know your Commands will only be used in the Context of a particular
application, that makes sense for the reasons that you've identified. But as I
design my Commands, I'm also keeping my mind open to easy interoperation with
other Commands, and being conservative about the Context implementation that I
depend on is one of the mechanisms to help this.
Craig McClanahan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Getting started questions
Hi,
Yesterday, I had contacted the mailing lists saying I was interested in
helping out with the Commons Math project. I received a helpful
response from Mark Diggory. However, I now have some quick questions.
(Please forgive me if the answer is already somewhere obvious.)
I love Eclipse, which also seems to be the preferred IDE for the
project. I already figured out how to check out the CVS HEAD as a new
Eclipse project. I also disabled the project's standard build
configuration, and switched to using the Math build.xml file with Ant
inside Eclipse. However, Eclipse still flags many things as errors -
all related to package declarations or finding classes. Does anybody
know how to turn off these errors? Or better yet, does anybody know how
to get Eclipse to not assume that the src/{ experimental | java |
test}/ directories should be part of the package?
Also, how does one set up a project to build with Maven? I have Maven
installed, but I only checked out the Commons Math code from CVS. The
project.xml file appears to want a project.xml file in the parent
directory, so I am assuming that file is part of Jakarta Commons in
general. So what additional modules should I be checking out? All of
Commons? Is there a way to just check out the general stuff and the
Commons Math stuff, without checking out all of the other projects? (I
am kind of new to CVS as well, so maybe this is an ignorant
question...)
Thanks for any help you guys can provide!
Brent Redeker
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Array concat?
I looked at this last night but in my usage I usually don't want the
arrayStart{ and arrayEnd }
I'm sorry I'm a bit lost. Which methods are you referring to?
(Normally, I'm sending parameters to other (non-java) components; flash
movies, form fields.)
IMO it would be nice to complete the String::split/Array::join
complementary
methods, but if it's not meant to be... that's ok too.
I think we all want to make [lang] as useful as possible for all. I should
have prefixed one of my reply indicating that I wanted to talk only about
the concat/addAll topic. So, I'll go back and look at your previous
posts...
I did inspect the ToStringBuilder and ToStringStyle(s) further tonight
(nice!) It's a really smart bit of functionality, I'd not looked closely
at
previously. If ArrayUtils doesn't end up with a join(), at least I found
some cool stuff in the process.
ArrayUtils has a join method now in CVS HEAD, which I think we will rename
to addAll but I think I might be confusing your join with ours. That is, you
are really talking about a kind of toString and I am talking about an
addAll. Names are important! ;-)
Gary
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
Sent: Friday, January 30, 2004 8:13 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [lang] Array concat?
Hello Tim,
We already have ArrayUtils.toString() methods. Would these suit
your needs?
Gary
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/ lang ArrayUtils.java
Hi Stephen, Well I guess we'll just agree to disagree ;-) From my POV the simplest layout is best, the one that required my (small) brain the least cycles to figure out, which to me is AB, rather than paging up and down and - god forbid - think. Good point WRT deltas b/w versions as far as raw text but would not JDiff handle such cases? Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, January 31, 2004 01:57 To: Jakarta Commons Developers List Subject: Re: cvs commit: jakarta- commons/lang/src/java/org/apache/commons/lang ArrayUtils.java -1 An arbitrary layout based on the alphabet is unsuitable. A related methods together is much better. Hashcode should be near Equals. Contains should be near IndexOf and LastIndexOf.. Also, this change makes it impossible to determine what really changed between versions. I want 2.0 of lang and 3.0 of collections to represent that fresh start where they are actively maintained (added to/bug fixes), rather than actively developed (refactored/added to/bug fixes). Stephen - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 30, 2004 2:12 AM Subject: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang ArrayUtils.java ggregory2004/01/29 18:12:22 Modified:lang/src/java/org/apache/commons/lang ArrayUtils.java Log: Sort members (Eclipse defaults). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Array concat?
Janek Bogucki wrote: concat is the best choice because join implies the introduction of a delimiter between the two arrays which is not the outcome, while append implies the extension of an existing object somehow and arrays don't get extended. To me, concat does hint at the production of a new object. I disagree that join implies a delimiter. concat is a good name also, but I'm +1 for join. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting started questions
Hi,
I love Eclipse, which also seems to be the preferred IDE for the
project. I already figured out how to check out the CVS HEAD as a new
Eclipse project. I also disabled the project's standard build
configuration, and switched to using the Math build.xml file with Ant
inside Eclipse. However, Eclipse still flags many things as errors - all
related to package declarations or finding classes. Does anybody know
how to turn off these errors? Or better yet, does anybody know how to
get Eclipse to not assume that the src/{ experimental | java | test}/
directories should be part of the package?
You can configure this directories as source directory by rightclicking
on your project and going to Properties-Build Path-Source-Add Folder
and then add all the folders containing project sources.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting started questions
Thank you very much for that answer, Michael. I hadn't tried that,
because I didn't know if that would mess anything else up
I also realized I forgot the [math] prefix on my original email - sorry
about that, everyone.
On Jan 31, 2004, at 12:56 PM, Michael Gloegl wrote:
Hi,
I love Eclipse, which also seems to be the preferred IDE for the
project. I already figured out how to check out the CVS HEAD as a new
Eclipse project. I also disabled the project's standard build
configuration, and switched to using the Math build.xml file with Ant
inside Eclipse. However, Eclipse still flags many things as errors -
all related to package declarations or finding classes. Does anybody
know how to turn off these errors? Or better yet, does anybody know
how to get Eclipse to not assume that the src/{ experimental | java |
test}/ directories should be part of the package?
You can configure this directories as source directory by
rightclicking on your project and going to Properties-Build
Path-Source-Add Folder and then add all the folders containing
project sources.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang ArrayUtils.java
ggregory2004/01/31 12:12:16
Modified:lang/src/test/org/apache/commons/lang ArrayUtilsTest.java
lang/src/java/org/apache/commons/lang ArrayUtils.java
Log:
Renamed ArrayUtils.join(Object[],Object[]) to addAll.
Revision ChangesPath
1.23 +9 -9
jakarta-commons/lang/src/test/org/apache/commons/lang/ArrayUtilsTest.java
Index: ArrayUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/ArrayUtilsTest.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- ArrayUtilsTest.java 30 Jan 2004 01:39:57 - 1.22
+++ ArrayUtilsTest.java 31 Jan 2004 20:12:15 - 1.23
@@ -116,35 +116,35 @@
}
public void testJoin() {
-assertNull(ArrayUtils.join(null, null));
+assertNull(ArrayUtils.addAll(null, null));
Object[] joinedArray;
String[] stringArray1 = new String[]{a, b, c};
String[] stringArray2 = new String[]{1, 2, 3};
-joinedArray = ArrayUtils.join(stringArray1, null);
+joinedArray = ArrayUtils.addAll(stringArray1, null);
assertArraysEquals(stringArray1, joinedArray);
assertArraysEquals(new String[]{a, b, c}, joinedArray);
assertEquals(String.class, joinedArray.getClass().getComponentType());
-joinedArray = ArrayUtils.join(null, stringArray2);
+joinedArray = ArrayUtils.addAll(null, stringArray2);
assertArraysEquals(stringArray2, joinedArray);
assertArraysEquals(new String[]{1, 2, 3}, joinedArray);
assertEquals(String.class, joinedArray.getClass().getComponentType());
-joinedArray = ArrayUtils.join(stringArray1, stringArray2);
+joinedArray = ArrayUtils.addAll(stringArray1, stringArray2);
assertArraysEquals(new String[]{a, b, c, 1, 2, 3}, joinedArray);
assertEquals(String.class, joinedArray.getClass().getComponentType());
-joinedArray = ArrayUtils.join(ArrayUtils.EMPTY_STRING_ARRAY, null);
+joinedArray = ArrayUtils.addAll(ArrayUtils.EMPTY_STRING_ARRAY, null);
assertArraysEquals(ArrayUtils.EMPTY_STRING_ARRAY, joinedArray);
assertArraysEquals(new String[]{}, joinedArray);
assertEquals(String.class, joinedArray.getClass().getComponentType());
-joinedArray = ArrayUtils.join(null, ArrayUtils.EMPTY_STRING_ARRAY);
+joinedArray = ArrayUtils.addAll(null, ArrayUtils.EMPTY_STRING_ARRAY);
assertArraysEquals(ArrayUtils.EMPTY_STRING_ARRAY, joinedArray);
assertArraysEquals(new String[]{}, joinedArray);
assertEquals(String.class, joinedArray.getClass().getComponentType());
-joinedArray = ArrayUtils.join(ArrayUtils.EMPTY_STRING_ARRAY,
ArrayUtils.EMPTY_STRING_ARRAY);
+joinedArray = ArrayUtils.addAll(ArrayUtils.EMPTY_STRING_ARRAY,
ArrayUtils.EMPTY_STRING_ARRAY);
assertArraysEquals(ArrayUtils.EMPTY_STRING_ARRAY, joinedArray);
assertArraysEquals(new String[]{}, joinedArray);
assertEquals(String.class, joinedArray.getClass().getComponentType());
String[] stringArrayNull = new String []{null};
-joinedArray = ArrayUtils.join(stringArrayNull, stringArrayNull);
+joinedArray = ArrayUtils.addAll(stringArrayNull, stringArrayNull);
assertArraysEquals(new String[]{null, null}, joinedArray);
assertEquals(String.class, joinedArray.getClass().getComponentType());
}
1.39 +15 -15
jakarta-commons/lang/src/java/org/apache/commons/lang/ArrayUtils.java
Index: ArrayUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/ArrayUtils.java,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- ArrayUtils.java 31 Jan 2004 09:57:39 - 1.38
+++ ArrayUtils.java 31 Jan 2004 20:12:16 - 1.39
@@ -2753,26 +2753,26 @@
}
/**
- * pJoins the elements of the provided arrays into a single new array./p
- * pThe new array contains all of the element of the first array followed
- * by all of the elements from the second array./p
+ * pAdds all the elements of the provided arrays into a new array./p
+ * pThe new array contains all of the element of codearray1/code followed
+ * by all of the elements codearray2/code./p
*
* pre
- * ArrayUtils.join(null, null) = null
- * ArrayUtils.join(array1, null) = array1
- * ArrayUtils.join(null, array2) = array2
- * ArrayUtils.join([], []) = []
- * ArrayUtils.join([null], [null]) = [null, null]
- * ArrayUtils.join([a, b, c], [1, 2, 3]) = [a, b, c, 1,
2, 3]
+ *
RE: [lang] Array concat?
I agree with Stephen. It is now so in CVS HEAD. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Friday, January 30, 2004 15:16 To: Jakarta Commons Developers List Subject: Re: [lang] Array concat? I believe that the collections like names will be best in the long run. Thus: add(Object[], Object) add(Object[], int, Object) addAll(Object[], Object[]) Stephen From: Gary Gregory [EMAIL PROTECTED] I've committed to HEAD three new ArrayUtils methods and unit tests: add(Object[], Object) add(Object[], int, Object) join(Object[], Object[]) Please comment on method names or impl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/ lang ArrayUtils.java
On Sat, 31 Jan 2004, Gary Gregory wrote: Hi Stephen, Well I guess we'll just agree to disagree ;-) Perhaps, but a veto is still a veto. Also, given that you're using Eclipse, is really doesn't matter what order the methods are in, because you can navigate to them so easily anyway. -- Martin Cooper From my POV the simplest layout is best, the one that required my (small) brain the least cycles to figure out, which to me is AB, rather than paging up and down and - god forbid - think. Good point WRT deltas b/w versions as far as raw text but would not JDiff handle such cases? Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, January 31, 2004 01:57 To: Jakarta Commons Developers List Subject: Re: cvs commit: jakarta- commons/lang/src/java/org/apache/commons/lang ArrayUtils.java -1 An arbitrary layout based on the alphabet is unsuitable. A related methods together is much better. Hashcode should be near Equals. Contains should be near IndexOf and LastIndexOf.. Also, this change makes it impossible to determine what really changed between versions. I want 2.0 of lang and 3.0 of collections to represent that fresh start where they are actively maintained (added to/bug fixes), rather than actively developed (refactored/added to/bug fixes). Stephen - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 30, 2004 2:12 AM Subject: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang ArrayUtils.java ggregory2004/01/29 18:12:22 Modified:lang/src/java/org/apache/commons/lang ArrayUtils.java Log: Sort members (Eclipse defaults). - 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]
[math] Re: Getting started questions
Brent Redeker wrote: Hi, Yesterday, I had contacted the mailing lists saying I was interested in helping out with the Commons Math project. I received a helpful response from Mark Diggory. However, I now have some quick questions. (Please forgive me if the answer is already somewhere obvious.) I love Eclipse, which also seems to be the preferred IDE for the project. There is no dependency on Eclipse. I already figured out how to check out the CVS HEAD as a new Eclipse project. I also disabled the project's standard build configuration, and switched to using the Math build.xml file with Ant inside Eclipse. However, Eclipse still flags many things as errors - all related to package declarations or finding classes. Does anybody know how to turn off these errors? Most likely what Eclipse is complaining about is missing external dependencies. I am not an Eclipse expert (actually just switched over from NetBeans a few weeks ago), but what I do is use Project Properties - Java Build Path - Libraries - Add External Jars to add the jars including the missing class definitions. I symlink the .maven/repository so the Eclipse directory browser can see the jars and just link directly to the jars in the local maven repo (once you get the maven build working, they will be there). The dependencies are enumerated in project.xml. I don't know if this is the best way to do it but it works4me. Also, how does one set up a project to build with Maven? I have Maven installed, but I only checked out the Commons Math code from CVS. The project.xml file appears to want a project.xml file in the parent directory, so I am assuming that file is part of Jakarta Commons in general. So what additional modules should I be checking out? All of Commons? Is there a way to just check out the general stuff and the Commons Math stuff, without checking out all of the other projects? (I am kind of new to CVS as well, so maybe this is an ignorant question...) You are correct, for math's maven build to work, you need to have jakarta-commons/project.xml and you need your math checkout to be inside the jakarta-commons directory. If you don't want to co the entire jakarta-commons module, you can just co jakarta-commons/project.xml (see the full command here: http://jakarta.apache.org/site/cvsindex.html), then cd to jakarta-commons and co math from there, or you could even just create the jakarta-commons directory manually and grab the file from http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/project.xml. You will also need jakarta-commons/xdocs to build the web site. I don't know how to get Eclipse to do all of this. I just use the command line and point Eclipse at the directories. Hope this helps. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang][collections] Project stage
I wonder if it would be better to simply state the status of the project without the use of a classification system. Things seem so fluid and dynamic around here. For example: http://maven.apache.org/status.html Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, January 31, 2004 02:17 To: Jakarta Commons Developers List Subject: [lang][collections] Project stage I wanted to see if my own mental classification fitted with others on lang and collections. I am kindof splitting stages of a project into categories like these: Experimemtation - where new ideas are tried Initial development - leading up to a 1.0 release Active development - adding and refactoring now you've used it Active maintanance - adding, but not refactoring Passive maintainance - responding to problems, rather than seeking to add new Asleep - Finished with, various reasons Whether this coresponds with any proper management scheme I don't know, but I reckon most if not all commons components could be classified using it. To do so might be useful to our users. I believe that [lang] is in Active maintainance since 2.0. I believe that [collections] went straight from Active development at 2.1 to Passive maintainance immediately after the 2.1 release which caused problems. Hence the last 6 months back in Active development have annoyed some. Collections 3.0 should represent the move to Active maintainance (ie. I hope we get a 3.1 at some point in the next 6 months). If people would find a classification like this useful, I could add it to the commons website, but I guess it might be controversial. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] CharUtils
I added a CharUtils class to lang today as it seemed to be a gap. I think I got a reasonable selection of methods in there, but people can look and see. We might also want to consider a ByteUtils. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/ lang ArrayUtils.java
From: Martin Cooper [EMAIL PROTECTED] On Sat, 31 Jan 2004, Gary Gregory wrote: Well I guess we'll just agree to disagree ;-) Perhaps, but a veto is still a veto. Gary could argue for it and try to convince me, but as I felt he'd fail, I shortened things a little ;-) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/ lang ArrayUtils.java
It does not matter /that/ much to me and I just wanted to record my opinion, that is all, no biggie. I still would like to know if JDiff can figure out changes without being confused by method order changes. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, January 31, 2004 13:27 To: Jakarta Commons Developers List Subject: Re: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/ lang ArrayUtils.java From: Martin Cooper [EMAIL PROTECTED] On Sat, 31 Jan 2004, Gary Gregory wrote: Well I guess we'll just agree to disagree ;-) Perhaps, but a veto is still a veto. Gary could argue for it and try to convince me, but as I felt he'd fail, I shortened things a little ;-) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22442] - EL parser misinterprets arithmetic operators as EL functions
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=22442. 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=22442 EL parser misinterprets arithmetic operators as EL functions --- Additional Comments From [EMAIL PROTECTED] 2004-01-31 21:51 --- Jan, Is this really a bug? I created a test case (see attachments) and it worked on JSTL 1.1/Tomcat 5.0.16. Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22442] - EL parser misinterprets arithmetic operators as EL functions
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=22442. 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=22442 EL parser misinterprets arithmetic operators as EL functions --- Additional Comments From [EMAIL PROTECTED] 2004-01-31 21:52 --- Created an attachment (id=10170) JSP page using JSTL 1.1 testing the bug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22442] - EL parser misinterprets arithmetic operators as EL functions
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=22442. 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=22442 EL parser misinterprets arithmetic operators as EL functions --- Additional Comments From [EMAIL PROTECTED] 2004-01-31 21:52 --- Output of the test case: 7 + 5 = 12 (3 + 4) + 5 = 12 7 + (2 + 3) = 12 7 div 5 = 1.4 (3 + 4) div 5 = 1.4 7 div (2 + 3) = 1.4 7 div(2 + 3) = 1.4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting started questions
Brent Redeker wrote:
I love Eclipse, which also seems to be the preferred IDE for the
project. I already figured out how to check out the CVS HEAD as a new
Eclipse project. I also disabled the project's standard build
configuration, and switched to using the Math build.xml file with Ant
inside Eclipse. However, Eclipse still flags many things as errors -
all related to package declarations or finding classes. Does anybody
know how to turn off these errors? Or better yet, does anybody know
how to get Eclipse to not assume that the src/{ experimental | java |
test}/ directories should be part of the package?
Am I the only person here that uses NetBeans?
EKMacAdie
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting started questions
Eric MacAdie wrote: Am I the only person here that uses NetBeans? EKMacAdie No. I am a netbeans fan too. I do think eclipse integrates well with maven though... so I am hoping maven and NB will play well together soon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Re: Getting started questions
On Jan 31, 2004, at 2:43 PM, Phil Steitz wrote: Brent Redeker wrote: Hi, Yesterday, I had contacted the mailing lists saying I was interested in helping out with the Commons Math project. I received a helpful response from Mark Diggory. However, I now have some quick questions. (Please forgive me if the answer is already somewhere obvious.) I love Eclipse, which also seems to be the preferred IDE for the project. There is no dependency on Eclipse. You are correct - but I already use it and it seems to be what several others are using. So it just seemed to be a logical choice. I already figured out how to check out the CVS HEAD as a new Eclipse project. I also disabled the project's standard build configuration, and switched to using the Math build.xml file with Ant inside Eclipse. However, Eclipse still flags many things as errors - all related to package declarations or finding classes. Does anybody know how to turn off these errors? Most likely what Eclipse is complaining about is missing external dependencies. I am not an Eclipse expert (actually just switched over from NetBeans a few weeks ago), but what I do is use Project Properties - Java Build Path - Libraries - Add External Jars to add the jars including the missing class definitions. I symlink the .maven/repository so the Eclipse directory browser can see the jars and just link directly to the jars in the local maven repo (once you get the maven build working, they will be there). The dependencies are enumerated in project.xml. I don't know if this is the best way to do it but it works4me. Actually, my problem was that I was using a default Eclipse project, and the source directory was just set to the project directory. But inside that was the src/ directory, then java/ (or experimental or test), and THEN the actual Java package directory hierarchy. This made Eclipse think the declared packages were at odds with the actual directory structure. Michael Gloegl answered this in an earlier reply (when I mistakenly omitted the [math] from my subject line) - I just had to explicitly define the source directories for Eclipse. As to your suggestion of the Add External Jars, so far I had not run into problems, since Ant was automatically fetching the necessary jars for me. However, it sounds like I'm best off getting Maven working; then I'll just try your system. Also, how does one set up a project to build with Maven? I have Maven installed, but I only checked out the Commons Math code from CVS. The project.xml file appears to want a project.xml file in the parent directory, so I am assuming that file is part of Jakarta Commons in general. So what additional modules should I be checking out? All of Commons? Is there a way to just check out the general stuff and the Commons Math stuff, without checking out all of the other projects? (I am kind of new to CVS as well, so maybe this is an ignorant question...) You are correct, for math's maven build to work, you need to have jakarta-commons/project.xml and you need your math checkout to be inside the jakarta-commons directory. If you don't want to co the entire jakarta-commons module, you can just co jakarta-commons/project.xml (see the full command here: http://jakarta.apache.org/site/cvsindex.html), then cd to jakarta-commons and co math from there, or you could even just create the jakarta-commons directory manually and grab the file from http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/ project.xml. You will also need jakarta-commons/xdocs to build the web site. Ah ha! I kind of suspected I'd have to something like that. I just wasn't sure exactly what stuff I'd all actually need. Thanks for the heads-up on needing jakarta-commons/xdocs, too. I don't know how to get Eclipse to do all of this. I just use the command line and point Eclipse at the directories. Hope this helps. Phil It sure did help, Phil, thanks a lot for your time. Hope my newbie-ness isn't too exasperating. Brent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26515] - IE 5.2 on MacOsx throws Exception in multipart form data sending
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=26515. 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=26515 IE 5.2 on MacOsx throws Exception in multipart form data sending [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|struts- |commons- |[EMAIL PROTECTED] |[EMAIL PROTECTED] Product|Struts |Commons Version|1.1 Final |1.0 Final --- Additional Comments From [EMAIL PROTECTED] 2004-01-31 23:37 --- I can confirm this behavior, but the exception is thrown byorg.apache.struts.upload.CommonsMultipartRequestHandler so I'm changing the product/ component fields to indicate that this isn't a Struts problem, it's a commons-fileupload problem. For what it's worth, Mozilla Firebird/0.7 works, as does Safari 1.1.1 My version of MSIE/OS X which manifests the problem is 5.2.3 (5815.1) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/dbutils/src/java/org/apache/commons/dbutils QueryRunner.java
dgraham 2004/01/31 16:16:35
Modified:dbutils/src/java/org/apache/commons/dbutils QueryRunner.java
Log:
Improved error handling in query() method. It was possible for the
Statement to not get closed if the ResultSet threw an SQLException
during its close. So, close Statement in finally block to ensure it gets
called.
Revision ChangesPath
1.8 +10 -6
jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/QueryRunner.java
Index: QueryRunner.java
===
RCS file:
/home/cvs/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/QueryRunner.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- QueryRunner.java 11 Jan 2004 22:30:38 - 1.7
+++ QueryRunner.java 1 Feb 2004 00:16:35 - 1.8
@@ -208,8 +208,11 @@
this.rethrow(e, sql, params);
} finally {
-DbUtils.close(rs);
-DbUtils.close(stmt);
+try {
+DbUtils.close(rs);
+} finally {
+DbUtils.close(stmt);
+}
}
return result;
@@ -430,7 +433,8 @@
/**
* Executes the given INSERT, UPDATE, or DELETE SQL statement. The
* codeConnection/code is retrieved from the codeDataSource/code
- * set in the constructor.
+ * set in the constructor. This codeConnection/code must be in
+ * auto-commit mode or the update will not be saved.
*
* @param sql The SQL statement to execute.
* @param params Initializes the PreparedStatement's IN (i.e. '?')
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator Field.java Validator.java Form.java ValidatorAction.java
dgraham 2004/01/31 18:25:08
Modified:validator/src/share/org/apache/commons/validator Field.java
Validator.java Form.java ValidatorAction.java
Log:
Refactored Validator class to place methods closer to the data required to
run them. Now ValidatorActions know how to execute their validation
method, Forms know how to validate a set of their Fields, and Fields
can run the validations configured on them.
Revision ChangesPath
1.30 +168 -5
jakarta-commons/validator/src/share/org/apache/commons/validator/Field.java
Index: Field.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/Field.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- Field.java17 Jan 2004 17:35:27 - 1.29
+++ Field.java1 Feb 2004 02:25:08 - 1.30
@@ -62,6 +62,7 @@
package org.apache.commons.validator;
import java.io.Serializable;
+import java.lang.reflect.InvocationTargetException;
import java.util.ArrayList;
import java.util.Collection;
import java.util.Collections;
@@ -71,16 +72,15 @@
import java.util.Map;
import java.util.StringTokenizer;
+import org.apache.commons.beanutils.PropertyUtils;
import org.apache.commons.collections.FastHashMap;
import org.apache.commons.validator.util.ValidatorUtils;
/**
- * p
* This contains the list of pluggable validators to run on a field and any
* message information and variables to perform the validations and generate
* error messages. Instances of this class are configured with a
* lt;fieldgt; xml element.
- * /p
*
* @see org.apache.commons.validator.Form
*/
@@ -787,6 +787,169 @@
}
return results.toString();
+}
+
+/**
+ * Returns an indexed property from the object we're validating.
+ *
+ * @param bean The bean to extract the indexed values from.
+ * @throws ValidatorException If there's an error looking up the property
+ * or, the property found is not indexed.
+ */
+Object[] getIndexedProperty(Object bean) throws ValidatorException {
+Object indexedProperty = null;
+
+try {
+indexedProperty =
+PropertyUtils.getProperty(bean, this.getIndexedListProperty());
+
+} catch(IllegalAccessException e) {
+throw new ValidatorException(e.getMessage());
+} catch(InvocationTargetException e) {
+throw new ValidatorException(e.getMessage());
+} catch(NoSuchMethodException e) {
+throw new ValidatorException(e.getMessage());
+}
+
+if (indexedProperty instanceof Collection) {
+return ((Collection) indexedProperty).toArray();
+
+} else if (indexedProperty.getClass().isArray()) {
+return (Object[]) indexedProperty;
+
+} else {
+throw new ValidatorException(this.getKey() + is not indexed);
+}
+
+}
+
+/**
+ * Executes the given ValidatorAction and all ValidatorActions that it
+ * depends on.
+ * @return true if the validation succeeded.
+ */
+private boolean validateForRule(
+ValidatorAction va,
+ValidatorResults results,
+Map actions,
+Map params,
+int pos)
+throws ValidatorException {
+
+ValidatorResult result = results.getValidatorResult(this.getKey());
+if (result != null result.containsAction(va.getName())) {
+return result.isValid(va.getName());
+}
+
+if (!this.runDependentValidators(va, results, actions, params, pos)) {
+return false;
+}
+
+return va.executeValidationMethod(this, params, results, pos);
+}
+
+/**
+ * Calls all of the validators that this validator depends on.
+ * TODO ValidatorAction should know how to run its own dependencies.
+ * @param va Run dependent validators for this action.
+ * @param results
+ * @param actions
+ * @param pos
+ * @return true if all of the dependent validations passed.
+ * @throws ValidatorException
+ */
+private boolean runDependentValidators(
+ValidatorAction va,
+ValidatorResults results,
+Map actions,
+Map params,
+int pos)
+throws ValidatorException {
+
+List dependentValidators = va.getDependencyList();
+
+if (dependentValidators.isEmpty()) {
+return true;
+}
+
+Iterator iter = dependentValidators.iterator();
+while (iter.hasNext()) {
+String depend = (String) iter.next();
+
+ValidatorAction
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator/util Flags.java
dgraham 2004/01/31 18:40:22 Modified:validator/src/share/org/apache/commons/validator/util Flags.java Log: javadoc changes only. Revision ChangesPath 1.7 +10 -4 jakarta-commons/validator/src/share/org/apache/commons/validator/util/Flags.java Index: Flags.java === RCS file: /home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/util/Flags.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- Flags.java17 Jan 2004 17:32:28 - 1.6 +++ Flags.java1 Feb 2004 02:40:22 - 1.7 @@ -69,7 +69,13 @@ * Flag 1 = 1br/ * Flag 2 = 2br/ * Flag 3 = 4br/ - * Flag 4 = 8br/ + * Flag 4 = 8br/br/ + * or using shift operator to make numbering easier:br/ + * Flag 1 = 1 lt;lt; 0br/ + * Flag 2 = 1 lt;lt; 1br/ + * Flag 3 = 1 lt;lt; 2br/ + * Flag 4 = 1 lt;lt; 3br/ + * * p * There cannot be a flag with a value of 3 because that represents Flag 1 * and Flag 2 both being on/true. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26515] - IE 5.2 on MacOsx throws Exception in multipart form data sending
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=26515. 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=26515 IE 5.2 on MacOsx throws Exception in multipart form data sending [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-02-01 02:40 --- *** This bug has been marked as a duplicate of 23229 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23229] - File Upload Not Compatible With IE 5.2.3 MacOS X
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=23229. 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=23229 File Upload Not Compatible With IE 5.2.3 MacOS X [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-02-01 02:40 --- *** Bug 26515 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator CreditCardValidator.java UrlValidator.java
dgraham 2004/01/31 18:41:25 Modified:validator/src/share/org/apache/commons/validator CreditCardValidator.java UrlValidator.java Log: Use left shift operator for constants to make numbering easier. Revision ChangesPath 1.15 +7 -7 jakarta-commons/validator/src/share/org/apache/commons/validator/CreditCardValidator.java Index: CreditCardValidator.java === RCS file: /home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/CreditCardValidator.java,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- CreditCardValidator.java 17 Jan 2004 19:22:02 - 1.14 +++ CreditCardValidator.java 1 Feb 2004 02:41:25 - 1.15 @@ -104,22 +104,22 @@ /** * Option specifying that American Express cards are allowed. */ -public static final int AMEX = 1; +public static final int AMEX = 1 0; /** * Option specifying that Visa cards are allowed. */ -public static final int VISA = 2; +public static final int VISA = 1 1; /** * Option specifying that Mastercard cards are allowed. */ -public static final int MASTERCARD = 4; +public static final int MASTERCARD = 1 2; /** * Option specifying that Discover cards are allowed. */ -public static final int DISCOVER = 8; +public static final int DISCOVER = 1 3; /** * The CreditCardTypes that are allowed to pass validation. 1.18 +6 -6 jakarta-commons/validator/src/share/org/apache/commons/validator/UrlValidator.java Index: UrlValidator.java === RCS file: /home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/UrlValidator.java,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- UrlValidator.java 11 Jan 2004 23:30:20 - 1.17 +++ UrlValidator.java 1 Feb 2004 02:41:25 - 1.18 @@ -120,17 +120,17 @@ * Allows all validly formatted schemes to pass validation instead of supplying a * set of valid schemes. */ -public static final int ALLOW_ALL_SCHEMES = 1; +public static final int ALLOW_ALL_SCHEMES = 1 0; /** * Allow two slashes in the path component of the URL. */ -public static final int ALLOW_2_SLASHES = 2; +public static final int ALLOW_2_SLASHES = 1 1; /** * Enabling this options disallows any URL fragments. */ -public static final int NO_FRAGMENTS = 4; +public static final int NO_FRAGMENTS = 1 2; private static final String ALPHA_CHARS = a-zA-Z; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator package.html
dgraham 2004/01/31 19:09:20 Modified:validator/src/share/org/apache/commons/validator package.html Log: Remove dependencies and point to Maven generated dependency page. Update examples to latest API. Revision ChangesPath 1.3 +238 -272 jakarta-commons/validator/src/share/org/apache/commons/validator/package.html Index: package.html === RCS file: /home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/package.html,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- package.html 22 Aug 2003 02:32:11 - 1.2 +++ package.html 1 Feb 2004 03:09:20 - 1.3 @@ -1,272 +1,238 @@ -html -head - titlePackage Documentation for org.apache.commons.validator/title -/head -body bgcolor=white -The Validator package provides validation for JavaBeans based on an xml file. -brbr -a name=doc.Description/a -div align=center -a href=#doc.Depend[Dependencies]/a -a href=#doc.Intro[Introduction]/a -a href=#doc.Overview[Overview]/a -a href=#doc.Resources[Resources]/a -a href=#doc.Usage[Usage Example]/a -/div - -a name=doc.Depend/a -h3External Dependencies/h3 - -ul - li -a href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-beanutils; -Beanutils Package (Jakarta Commons)/a, version 1.0 or later - /li - li -a href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-collections; -Collections Package (Jakarta Commons)/a, version 1.0 or later - /li - li -a href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester; -Digester Package (Jakarta Commons)/a, version 1.0 or later - /li - li -a href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging; -Logging Package (Jakarta Commons)/a, version 1.0 or later - /li - liAn xml parser conforming to -a href=http://www.megginson.com/SAX/;SAX 2.0/a for the Commons Digester - /li - liOptionally, an XML parser conforming to -a href=http://java.sun.com/products/xml;JAXP -/a, version 1.1 or later (the first one to support SAX 2.0) - for the Commons Digester - /li - -/ul - -a name=doc.Intro/a -h3Introduction/h3 - -pA common issue when receiving data either electronically or from -user input is verifying the integrity of the data. This work is -repetitive and becomes even more complicated when different sets -of validation rules need to be applied to the same set of data based -on locale for example. Error messages may also vary by locale. -This package attempts to address some of these issues and -speed development and maintenance of validation rules. -/p - -pIn order to use the Validator, the following basic steps are required:/p -ul - liCreate a new instance of the - codeorg.apache.commons.validator.Validator/code class. Currently - Validator instances may be safely reused if the current ValidatorResources - are the same, as long as - you have completed any previous validation, and you do not try to utilize - a particular Validator instance from more than one thread at a time./li - liAdd any a href=#doc.Resourcesresources/a - needed to perform the validations. Such as the JavaBean to validate./li - liCall the validate method on codeorg.apache.commons.validator.Validator/code./li -/ul - -a name=doc.Overview/a -h3Overview/h3 -p - The Commons Validator is a basic validation framework that - lets you define validation rules for a JavaBean in an xml file. - Validators, the validation definition, can also be defined in - the xml file. An example of a validator would be defining - what method and class will be called to perform the validation - for a required field. Validation rules can be grouped together - based on locale and a JavaBean/Form that the rules are associated - with. The framework has basic support for user defined constants - which can be used in some field attributes. -/p -p - Validation rules can be defined in an xml file which keeps - them abstracted from JavaBean you are validating. The - property reference to a field supports nested properties - using the Jakarta Commons BeanUtils - (http://jakarta.apache.org/commons/beanutils.html) package. - Error messages and the arguments for error messages can be - associated with a fields validation. -/p - -a name=doc.Resources/a -h3Resources/h3 -p - After a Validator instance is created, instances of - classes can be added to it to be passed into - validation methods by calling the addResource - method. Below is a list of reserved keys (class names). -/p - -table width=100% border=1 cellspacing=5 - tr -
Re: Httpclient won't run in JUnit
Michael,
I confirm that the problem is perfectly reproducible with Sun JDK 1.2.2
(simple logger used per default) and Sun JDK 1.4.2 (JDK logger used per
default). However, what I discovered is that the problem occurred only
when using SwingUI. The same code runs without a hitch using TextUI.
I understand it's a small comfort to you, but the problem does not seem
to be caused by HttpClient. Try approaching JUnit people to see if they
know of any compatibility issues between JUnit's SwingUI and
commons-logging
Oleg
On Sat, 2004-01-31 at 03:24, Michael Czeiszperger wrote:
On Jan 29, 2004, at 5:10 PM, Michael Becke wrote:
Looks like a class loader problem. My guess is that commons-logging
is being loaded by more than one class loader.
I figured that since HttpClient uses JUnit for its test suite that
HttpClient had to be compatible with JUnit. Here's the most simple
JUnit example showing that the latest versions of HttpClient does not
run with JUnit. The example does nothing but start JUnit with the
latest versions of HttpClient and commons logging and no other
libraries involved:
import org.apache.commons.httpclient.*;
import org.apache.commons.httpclient.methods.*;
import junit.framework.*;
/**
* Simple example showing problem with running HttpClient code within
JUnit
*/
public class HttpClientJunitBug extends TestCase
{
public HttpClientJunitBug(String s)
{
super(s);
}
public void testSimple()
{
org.apache.commons.httpclient.HttpClient client = new
org.apache.commons.httpclient.HttpClient();
assertTrue( client != null );
}
}
promptjavac HttpClientJunitBut.java
promptjava -cp
junit.jar:commons-httpclient-2.0-rc2.jar:commons-logging-api.jar:.
junit.swingui.TestRunner HttpClientJunitBug
The result is:
java.lang.ExceptionInInitializerError
Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Class
org.apache.comons.logging.impl.Jdk14Logger does not implement Log
I thought maybe someone who runs the HttpClient test suite regularly
would be able to spot my mistake easily. (Hopefully!)
Thanks,
Michael Czeiszperger
czei at webperformanceinc dot com
Web Performance, Inc.
919-845-7601
-
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: Re: access denied exception
Dave,
The best thing you can do is to familiarise yourself with the Java
security and make this decision for yourself. Security settings tend to
be highly application specific depending upon the type of risks the
application needs be able to deal with. What may be perfectly suitable
for one type applications, may be completely inappropriate for others
Apparently your application does not have permission to enumerate JSSE
providers. For more details please refer to
http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html#SecurityPermission
Oleg
On Sat, 2004-01-31 at 07:46, D Alvarado wrote:
Thanks kindly for the reponse. Just one small
follow-up question. What am I granting
permission to access what?
Much thanks - Dave
Begin Original Message
From: Roland Weber [EMAIL PROTECTED]
Sent: Fri, 30 Jan 2004 09:18:40 +0100
To: Commons HttpClient Project
[EMAIL PROTECTED]
Subject: Re: access denied exception
Hello,
this looks like a Java2 security problem. Two
options:
Hack: Disable Java2 security.
Clean: grant your application the necessary
permissions
in the java.policy file
The file should be in ${JAVA_HOME}/jre/lib/security/
I hope someone else can come up with the exact
permission entries required for the HTTP Client.
best regards,
Roland
D Alvarado [EMAIL PROTECTED]
30.01.2004 06:36
Please respond to Commons HttpClient Project
To:
[EMAIL PROTECTED]
cc:
Subject:access denied exception
Hi, I was hoping someone could help me with this
exception. I'm trying to POST some data to a
remote site using https. The code is almost
directly from jakarta:
// Create an instance of HttpClient.
HttpClient client = new HttpClient();
client.getState().setCookiePolicy(CookiePolicy.COMPATIBILITY);
// Create a method instance.
PostMethod method = new
PostMethod(https://www.thirdparty.com;);
method.setRequestBody(data);
// Execute the method.
int statusCode = -1;
int attempt = 0;
// We will retry up to 3 times.
while (statusCode == -1 attempt 3) {
try {
// execute the method.
statusCode =
client.executeMethod(method);
} catch (HttpRecoverableException
e) {
System.err.println(A
recoverable exception occurred, retrying. +
e.getMessage());
} catch (IOException e) {
System.err.println(Failed to download file.);
e.printStackTrace();
}
}
// Check that we didn't run out of retries.
if (statusCode == -1) {
System.err.println(Failed to
recover from exception.);
}
I am running WebLogic 5.1 sp12, with the lastest
version of JSSE. But the above code generates
the following exception:
java.security.AccessControlException: access
denied (java.security.SecurityPermission
getProperty.ssl.SocketFactory.provider)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at
java.security.Security.getProperty(Security.java:879)
at javax.net.ssl.SSLSocketFactory$1.run(DashoA6275)
at
java.security.AccessController.doPrivileged(Native
Method)
at javax.net.ssl.SSLSocketFactory.a(DashoA6275)
at
javax.net.ssl.SSLSocketFactory.getDefault(DashoA6275)
at
org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(SSLProtocolSocketFactory.java:112)
at
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:663)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:661)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529)
at
jsp_servlet._ma._thinkwell._student.__tw_student_redirect._jspService(__tw_student_redirect.java:238)
at lycea.ui.LyceaJspServlet.service(Unknown Source)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:120)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:138)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:945)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:909)
at
weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:269)
at
weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:392)
at
weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:274)
at
weblogic.kernel.ExecuteThread.run(ExecuteThread.java:130)
Any thoughts? Thanks for your time, Dave
Care2 make the world greener!
Think twice before eating farmed salmon. Find out
why:
[Bugzilla] Commons HttpClient as a top level Bugzilla project
Good day, I am approaching you on behalf of the Jakarta Commons HttpClient project We are wondering if it would be possible to promote Jakarta Commons HttpClient to a top level project in Bugzilla. We would like to be able to set release versions and milestones specific to HttpClient, which is not possible as long as HttpClient remains a sub-component of jakarta-commmons. Please let us know if that's feasible Cheers, Oleg Kalnichevski On Thu, 2004-01-22 at 21:28, Oleg Kalnichevski wrote: Good day, Following the proposal to migrate Jakarta Commons projects from Bugzilla to JIRA posted to the Jakarta commons-dev list, we would like to have a few points clarified, before the final decision can be made whether Jakarta Commons HttpClient project stays with Bugzilla or migrates (kindly requests to be migrated) to JIRA. * Do you actually encourage migration from Bugzilla to JIRA? Will it make the task of to administering and supporting projects' infrastructure (issue tracking in the first place) easier for you? * Can existing bug reports (including closed ones) be migrated to JIRA in their entirety, if at all? What kind of data would not be migrated automatically? Would existing user accounts be preserved? * We (HttpClient committers contributors) have been in fact quite satisfied with Bugzilla so far. It has served us well. The only thing we have found constraining is the release management (versions, milestones, etc). As an alternative to migration to JIRA would it be possible to promote HttpClient from a component of Jakarta-commons project to a full fledged top level project with its own set of versions and milestones? HttpClient has already got its own mailing list. HttpClient related content constitutes 20-30% Bugzilla entries for the Jakarta-commons project. I believe this might be the best option, as least as far as we are concerned. I am just not sure it is technically feasible. Cheers, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Httpclient won't run in JUnit
On Jan 31, 2004, at 6:26 AM, Oleg Kalnichevski wrote: I confirm that the problem is perfectly reproducible with Sun JDK 1.2.2 (simple logger used per default) and Sun JDK 1.4.2 (JDK logger used per default). However, what I discovered is that the problem occurred only when using SwingUI. The same code runs without a hitch using TextUI. I understand it's a small comfort to you, but the problem does not seem to be caused by HttpClient. Try approaching JUnit people to see if they know of any compatibility issues between JUnit's SwingUI and commons-logging Thank you very much for taking the time to look at this, I really appreciate it. It does seem that the problem is probably in JUnit, so I'll focus attention in that area. Warm regards, Michael Czeiszperger czei at webperformanceinc dot com Web Performance, Inc. 919-845-7601 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bugzilla] Commons HttpClient as a top level Bugzilla project
Hi Martin, In all honesty the idea of moving HttpClient out of Jakarta Commons to become a full-fledged Jakarta project has been discussed a while ago on HttpClient developer's list. However, at that time we were not sure if HttpClient merited such a promotion. The decision to offload HttpClient related mail traffic predates most (if not all) current contributors and committers. I personally am not aware of the rationale behind it and I do not know if HttpClient was initially meant to be a Jakarta level project, but simply was not mature enough. Anyways, a request for promotion to Jakarta level may be a very political move. Certainly, we would feel honoured to be considered, but to some HttpClient may be just a utility component and as such appropriately placed in Jakarta commons. On the other hand, based on the mail traffic, Bugzilla content HttpClient has been generating, the size of the community HttpCleint has got, I believe we have long outgrown Jakarta Commons. Martin, how would you advise up to go about this issue? Who shall we approach? Michael, since this is no longer just a Bugzilla issue, I think you, being our project lead, should take over from here Cheers, Oleg On Sat, 2004-01-31 at 22:07, Martin Cooper wrote: To be honest, I think you need to seriously consider moving HttpClient out of Jakarta Commons, either to a full Jakarta project or to a TLP. Already, HttpClient has its own mailing list, and as a result, it has become its own world, with little relation to the rest of Jakarta Commons except in name. If HttpClient has its own mailing list, its own Bugzilla category, and its own separate community, there doesn't seem to be much reason to stay within Jakarta Commons, whereas I see good reasons for it to move out. -- Martin Cooper On Sat, 31 Jan 2004, Oleg Kalnichevski wrote: Good day, I am approaching you on behalf of the Jakarta Commons HttpClient project We are wondering if it would be possible to promote Jakarta Commons HttpClient to a top level project in Bugzilla. We would like to be able to set release versions and milestones specific to HttpClient, which is not possible as long as HttpClient remains a sub-component of jakarta-commmons. Please let us know if that's feasible Cheers, Oleg Kalnichevski On Thu, 2004-01-22 at 21:28, Oleg Kalnichevski wrote: Good day, Following the proposal to migrate Jakarta Commons projects from Bugzilla to JIRA posted to the Jakarta commons-dev list, we would like to have a few points clarified, before the final decision can be made whether Jakarta Commons HttpClient project stays with Bugzilla or migrates (kindly requests to be migrated) to JIRA. * Do you actually encourage migration from Bugzilla to JIRA? Will it make the task of to administering and supporting projects' infrastructure (issue tracking in the first place) easier for you? * Can existing bug reports (including closed ones) be migrated to JIRA in their entirety, if at all? What kind of data would not be migrated automatically? Would existing user accounts be preserved? * We (HttpClient committers contributors) have been in fact quite satisfied with Bugzilla so far. It has served us well. The only thing we have found constraining is the release management (versions, milestones, etc). As an alternative to migration to JIRA would it be possible to promote HttpClient from a component of Jakarta-commons project to a full fledged top level project with its own set of versions and milestones? HttpClient has already got its own mailing list. HttpClient related content constitutes 20-30% Bugzilla entries for the Jakarta-commons project. I believe this might be the best option, as least as far as we are concerned. I am just not sure it is technically feasible. Cheers, Oleg - 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: [Bugzilla] Commons HttpClient as a top level Bugzilla project
Hello Martin, Oleg, On Jan 31, 2004, at 7:01 PM, Martin Cooper wrote: Moving out of Commons and up to your own Jakarta project is internal to Jakarta, so what I would suggest is this: 1) Discuss it and make sure you have agreement within the HttpClient community. You probably should have a vote at some point, unless it's apparent from the outset that everyone is in favour. 2) Write up a proposal, and send it to the Jakarta PMC. It might also be a good idea to CC the commons-dev list, to let the folks there know what's going on. I doubt very much that there will be any dissent on the PMC, since at that point it will be a community decision. 3) Once the PMC is happy, we can get you set up as your own Jakarta project. There are folks on the PMC who should be able to take care of most, if not all, of the details. Anything else you can collate into a list to send to infrastructure@ at that point. These sound like a reasonable set of steps. Let's start this discussion on httpclient dev and see if the HttpClient community is ready to make the move. I think the concept of a project lead is peculiar to the HttpClient component. (IIRC, it was introduced by Jeff Dever quite some time ago, and I guess it stuck.) Obviously, if that's how you'd like to handle it, that's fine with me. ;-) I would assume that Michael is on the PMC, but if not, then you'll need your PMC members to handle any discussion on that list. Though I am considered the HttpClient project lead, this mostly just means that I handle the releases. HttpClient is still managed via consensus. As far as the PMC goes, I am not a member. I do not know if any of the other regular HttpClient committers are either. We may need someone to represent us, if the time comes. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Promote HttpClient out of commons?
Hello All, There has been some discussion lately of promoting HttpClient out of commons, making it a regular Jakarta project. Before any such move is made we would need to come to a consensus, and vote, within the HttpClient community. At this point I would like to encourage everyone to put in their 2 cents. What does everyone think? In particular I would like to hear from all the regular committers, contributors, and users. How do you think this move would effect HttpClient's visibility, community, and organization? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
