cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/strategy ObjectStringConverter.java
rdonkin 2003/08/15 23:28:42
Modified:betwixt/src/java/org/apache/commons/betwixt/strategy
ObjectStringConverter.java
Log:
Improved java docs
Revision ChangesPath
1.2 +17 -5
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/strategy/ObjectStringConverter.java
Index: ObjectStringConverter.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/strategy/ObjectStringConverter.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ObjectStringConverter.java31 Jul 2003 21:37:25 - 1.1
+++ ObjectStringConverter.java16 Aug 2003 06:28:42 - 1.2
@@ -66,7 +66,19 @@
import org.apache.commons.betwixt.expression.Context;
/**
- * Strategy class allows custom string lt;-gt; object conversion implementations.
+ * pStrategy class for string lt;-gt; object conversions.
+ * Implementations of this interface are used by Betwixt to perform
+ * string lt;-gt; object conversions.
+ * This performs only the most basic conversions.
+ * Most applications will use a subclass.
+ * /p
+ * pIt is strongly recommended that (in order to support round tripping)
+ * that codeobjectToString/code and codestringToObject/code
+ * are inverse functions.
+ * In other words, given the same flavour, context and type the applying
+ * objectToString to the result of stringToObject should be equal to the
+ * original input.
+ * /p
*/
public class ObjectStringConverter implements Serializable {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt DeltaBean.java
rdonkin 2003/08/15 23:29:36
Added: betwixt/src/test/org/apache/commons/betwixt DeltaBean.java
Log:
New bean for testing (not used yet but didn't want to forget to commit it when it is
Revision ChangesPath
1.1
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/DeltaBean.java
Index: DeltaBean.java
===
/*
* $Header:
/home/cvs/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/DeltaBean.java,v
1.1 2003/08/16 06:29:36 rdonkin Exp $
* $Revision: 1.1 $
* $Date: 2003/08/16 06:29:36 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2002 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* $Id: DeltaBean.java,v 1.1 2003/08/16 06:29:36 rdonkin Exp $
*/
package org.apache.commons.betwixt;
/** pA simple bean that demonstrates conversions of primitives and objects./p
*
* @author Robert Burrell Donkin
* @version $Revision: 1.1 $
*/
public class DeltaBean {
private java.sql.Date sqlDate;
private java.sql.Time sqlTime;
private java.sql.Timestamp sqlTimestamp;
private java.util.Date utilDate;
private String name;
private Float objFloat;
private float primitiveFloat;
public DeltaBean() {
}
public DeltaBean(
java.sql.Date sqlDate,
java.sql.Time sqlTime,
java.sql.Timestamp sqlTimestamp,
java.util.Date utilDate,
String name,
Float objFloat,
float primitiveFloat) {
setSqlDate(sqlDate);
setSqlTime(sqlTime);
setSqlTimestamp(sqlTimestamp);
setUtilDate(utilDate);
setName(name);
setObjFloat(objFloat);
setPrimitiveFloat(primitiveFloat);
}
public java.sql.Date getSqlDate() {
return sqlDate;
}
public void setSqlDate(java.sql.Date sqlDate) {
this.sqlDate = sqlDate;
}
public java.sql.Time getSqlTime() {
return sqlTime;
}
public void setSqlTime(java.sql.Time sqlTime) {
this.sqlTime = sqlTime;
}
public java.sql.Timestamp getSqlTimestamp()
cvs commit: jakarta-commons/betwixt/xdocs/guide binding.xml
rdonkin 2003/08/15 23:30:24 Modified:betwixt/xdocs tasks.xml betwixt/xdocs/guide binding.xml Log: Added pluggable Object-String conversion strategy documentation Revision ChangesPath 1.20 +14 -0 jakarta-commons/betwixt/xdocs/tasks.xml Index: tasks.xml === RCS file: /home/cvs/jakarta-commons/betwixt/xdocs/tasks.xml,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- tasks.xml 29 Jul 2003 21:33:31 - 1.19 +++ tasks.xml 16 Aug 2003 06:30:24 - 1.20 @@ -236,6 +236,15 @@ strongSupport for converting output strings/strong ConvertUtils is now called to convert output strings (as well as input ones). /li +li +strongRefactored Object lt;-gt; String Conversion/strong +This process has been factored out into a separate pluggable Strategy class +(codeObjectStringConverter/code). A pure codeConvertUtils/code implementation +has been created (codeConvertUtilsObjectStringConverter/code). The default implementation +(codeDefaultsObjectStringConverter/code) delegates most conversions to codeConvertUtils/code +but contains a special case that allows the default setting to round trip java.util.Date's +without breaking compatibility. +/li /ul /subsection /section @@ -352,6 +361,11 @@ codeConvertUtils/code from commons-beanutils is now called to performt the object to string conversions. It is possible that in some circumstances, this change may effect the output. +/li +li +strongcodeConvertUtils/code conversion now ignored (by default) for java.util.Date/strong +If you use a custom codeConvertUtils/code java.util.Date converter then see +a href='guide/binding.html#Converting Dates (And Other Objects)'the guide/a. /li /ul /subsection 1.2 +87 -6 jakarta-commons/betwixt/xdocs/guide/binding.xml Index: binding.xml === RCS file: /home/cvs/jakarta-commons/betwixt/xdocs/guide/binding.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- binding.xml 14 Aug 2003 21:25:26 - 1.1 +++ binding.xml 16 Aug 2003 06:30:24 - 1.2 @@ -339,16 +339,97 @@ property is specified then the bean can be written and then read back. /p /subsection +/section -subsection name='Using ConvertUtils To Customize Conversion Of Primitives' -p +section name='Converting Objects And Primitives To Strings (And Back Again)' + +subsection name='Using ConvertUtils To Customize Conversion Of Primitives' +p codeConvertUtils/code is part of a href='http://jakarta.apache.org/commons/beanutils.html'commons-beanutils/a -and it can be used to flexibly convert strings to objects and back again. Betwixt uses ConvertUtils to +and it can be used to flexibly convert strings to objects and back again. By default, Betwixt uses ConvertUtils to perform these conversions and so standard codeConvertUtils/code methods can be called to customize these conversions. -/p -/subsection - +/p +/subsection +subsection name='Converting Dates (And Other Objects)' +p +There are numerous situations when read beans from xml or writing beans to xml that String to Object +or Object to String conversions are required. Betwixt uses a emStrategy/em class to allow a convenient +default which will work well for most basic users whilst allowing advanced users to fully hook in and +customize this process. +/p +p +The default strategy uses codeConvertUtils/code from +a href='http://jakarta.apache.org/commons/beanutils.html'commons-beanutils/a to perform these conversions. +This is a powerful component that allows flexible customization of the conversion process. +/p +p +There is one exception to this rule. If the class is a codejava.util.Date/code - or a subclass of codejava.util.Date/code which is not a subclass of codejava.sql.Date/code, codejava.sql.Time/code or codejava.sql.Timestamp/code - then this is converted to and from a string following this pattern: +codepre +EEE MMM dd HH:mm:ss zzz +/pre/code +(using the SimpleDateFormat notation). Observent readers will realise that this is the same pattern +that is returned by codejava.util.Date.toString/code - and that's why this pattern was chosen. +It provides a good default for casual users. +/p +p
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang ObjectUtils.java
scolebourne2003/08/16 02:50:59 Modified:lang/src/java/org/apache/commons/lang ObjectUtils.java Log: Javadoc Revision ChangesPath 1.18 +2 -2 jakarta-commons/lang/src/java/org/apache/commons/lang/ObjectUtils.java Index: ObjectUtils.java === RCS file: /home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/ObjectUtils.java,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- ObjectUtils.java 13 Aug 2003 23:30:58 - 1.17 +++ ObjectUtils.java 16 Aug 2003 09:50:59 - 1.18 @@ -231,7 +231,7 @@ /** * pGets the codetoString/code of an codeObject/code returning - * an empty string () if codenull/code input./p + * a specified text if codenull/code input./p * * pre * ObjectUtils.toString(null, null) = null - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang StringUtils.java
scolebourne2003/08/16 03:36:00
Modified:lang/src/java/org/apache/commons/lang StringUtils.java
Log:
uncapitaliseAllWords was not in 1.0.1, so it should not be in 2.0 as deprecated
Revision ChangesPath
1.100 +1 -17
jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java
Index: StringUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v
retrieving revision 1.99
retrieving revision 1.100
diff -u -r1.99 -r1.100
--- StringUtils.java 14 Aug 2003 02:20:48 - 1.99
+++ StringUtils.java 16 Aug 2003 10:36:00 - 1.100
@@ -3644,22 +3644,6 @@
return buffer.toString();
}
-/**
- * pUncapitalizes all the whitespace separated words in a String.
- * Only the first letter of each word is changed./p
- *
- * pWhitespace is defined by [EMAIL PROTECTED] Character#isWhitespace(char)}.
- * A codenull/code input String returns codenull/code./p
- *
- * @param str the String to uncapitalize, may be null
- * @return uncapitalized String, codenull/code if null String input
- * @deprecated Use the standardly named [EMAIL PROTECTED]
#uncapitalizeAllWords(String)}.
- * Method will be removed in Commons Lang 3.0.
- */
-public static String uncapitaliseAllWords(String str) {
-return uncapitalizeAllWords(str);
-}
-
// Count matches
//---
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[lang] Words - for 2.0
In examining the release, I found I need to annoy everyone again. WordWrapUtils is broken. The algorithm relies on a newLineChars parameter that is used for two purposes. 1) Splitting the input string 2) Adding newlines to the output string This is a new class, so it should either be pulled (preferred) or fixed (not preferred, as there are various issues) --- Related issue - WordWrapUtils is too specific a name. I propose: 1) changing it to WordUtils (or StringWordUtils) 2) moving capitalizeAllWords to WordUtils 3) moving uncapitalizeAllWords to WordUtils 4) moving swapCase to WordUtils This would help reduce the size of StringUtils, and provide much better functional grouping. There is lots we can do with words. (Of course you could argue for a separate [text] project, but I doubt there is that much.) I would like to do this for 2.0, as otherwise users of capitaliseAllWords will have to change twice. However we could say that is a small group of people and postpone the change to 2.1. Opinions? 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 StringEscapeUtils.java CharSet.java package.html ArrayUtils.java
scolebourne2003/08/16 04:04:46
Modified:lang/src/java/org/apache/commons/lang StringEscapeUtils.java
CharSet.java package.html ArrayUtils.java
Log:
Javadoc changes
bug 22480, from Pete Gieser
Revision ChangesPath
1.24 +4 -1
jakarta-commons/lang/src/java/org/apache/commons/lang/StringEscapeUtils.java
Index: StringEscapeUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/StringEscapeUtils.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- StringEscapeUtils.java1 Aug 2003 20:45:17 - 1.23
+++ StringEscapeUtils.java16 Aug 2003 11:04:46 - 1.24
@@ -72,6 +72,7 @@
* @author a href=[EMAIL PROTECTED]Sean Brown/a
* @author a href=mailto:[EMAIL PROTECTED]Gary Gregory/a
* @author Phil Steitz
+ * @author Pete Gieser
* @since 2.0
* @version $Id$
*/
@@ -308,6 +309,7 @@
* @param out the codeWriter/code used to output unescaped characters
* @param str the codeString/code to unescape, may be null
* @throws IllegalArgumentException if the Writer is codenull/code
+ * @throws IOException if error occurs on undelying Writer
*/
public static void unescapeJava(Writer out, String str) throws IOException {
if (out == null) {
@@ -422,6 +424,7 @@
* @param out the codeWriter/code used to output unescaped characters
* @param str the codeString/code to unescape, may be null
* @throws IllegalArgumentException if the Writer is codenull/code
+ * @throws IOException if error occurs on undelying Writer
*/
public static void unescapeJavaScript(Writer out, String str) throws
IOException {
unescapeJava(out, str);
1.15 +21 -19
jakarta-commons/lang/src/java/org/apache/commons/lang/CharSet.java
Index: CharSet.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/CharSet.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- CharSet.java 7 Aug 2003 21:12:19 - 1.14
+++ CharSet.java 16 Aug 2003 11:04:46 - 1.15
@@ -62,12 +62,13 @@
/**
* pA set of characters./p
- *
+ *
* pThis class is immutable, but subclasses may not be./p
*
* @author Henri Yandell
* @author Stephen Colebourne
* @author Phil Steitz
+ * @author Pete Gieser
* @since 1.0
* @version $Id$
*/
@@ -75,7 +76,7 @@
/** Serialization lock, Lang version 2.0. */
private static final long serialVersionUID = 5947847346149275958L;
-
+
/** A CharSet defining no characters. */
public static final CharSet EMPTY = new CharSet((String) null);
/** A CharSet defining ASCII alphabetic characters a-zA-Z. */
@@ -86,7 +87,7 @@
public static final CharSet ASCII_ALPHA_UPPER = new CharSet(A-Z);
/** A CharSet defining ASCII alphabetic characters 0-9. */
public static final CharSet ASCII_NUMERIC = new CharSet(0-9);
-
+
/**
* A Map of the common cases used in the factory.
* Subclasses can add more common patterns if desired.
@@ -101,14 +102,14 @@
COMMON.put(A-Z, ASCII_ALPHA_UPPER);
COMMON.put(0-9, ASCII_NUMERIC);
}
-
+
/** The set of CharRange objects. */
private Set set = new HashSet();
//---
/**
* pFactory method to create a new CharSet using a special syntax./p
- *
+ *
* ul
* licodenull/code or empty string ()
* - set containing no characters/li
@@ -121,7 +122,7 @@
* liCombinations, such as abe-g
* - set containing all the characters from the individual sets/li
* /ul
- *
+ *
* pThe matching order is:/p
* ol
* liNegated multi character range, such as ^a-e
@@ -131,7 +132,7 @@
* /ol
* pMatching works left to right. Once a match is found the
* search starts again from the next character./p
- *
+ *
* pIf the same range is defined twice using the same syntax, only
* one range will be kept.
* Thus, a-ca-c creates only one range of a-c./p
@@ -144,8 +145,9 @@
* pThe set of characters represented is the union of the specified
ranges./p
*
* pAll CharSet objects returned by this method will be immutable./p
- *
+ *
* @param setStr the String describing the set, may be null
+ * @return a CharSet instance
*/
public static CharSet getInstance(String setStr) {
Object set = COMMON.get(setStr);
@@ -170,6 +172,7 @@
DO NOT REPLY [Bug 22480] - [lang] Patch for javadocs
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=22480. 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=22480 [lang] Patch for javadocs --- Additional Comments From [EMAIL PROTECTED] 2003-08-16 14:21 --- I understand your perspective and agree that it was too large. I guess I was trying to get it all in before 2.0, but perhaps that was optimistic. I don't remember the instance of a changed method name. But I do remember running the lang tests numerous times and never got an failure. Did I change the test too? As for the other minor errors, did the tests not cover them? Anyway, lesson learned. I will be more proactive asking about things on the list before making changes. Thanks for looking at it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22480] - [lang] Patch for javadocs
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=22480. 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=22480 [lang] Patch for javadocs --- Additional Comments From [EMAIL PROTECTED] 2003-08-16 14:44 --- The changed method name was in ToStringStyle (isShortClassName). The 'other errors' referred to a couple of places in the new javadoc that didn't describe the classes functionality accurately. Can't remember where. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Words - for 2.0
Stephen Colebourne wrote: WordWrapUtils is broken. ... This is a new class, so it should either be pulled (preferred) or fixed (not preferred, as there are various issues) I have an implementation of Unicode TR14 for word wrapping almost ready. There are some fine points still to resolve though (Some width issues for east asean characters and how to handle combining markers. Well taking this into account the current class is even more broken.) Preparing the tables from the report was painful, I feel like a hero now. I'd vote for pulling the class and move it elsewhere. ... This would help reduce the size of StringUtils, and provide much better functional grouping. There is lots we can do with words. (Of course you could argue for a separate [text] project, but I doubt there is that much.) Other features for [text] - parsing text into words - spell checking - character normalization (well, there is icu4j) - glyph shaping - hyphenation - word inflection - morphological analysis, grammatical analysis - various tools for handling data necessary for the tasks above I can contribute some code for most of the above. FOP would be the first user of a commons hyphenation component and and will probably also take advantage of character normalization in the long term. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Words - for 2.0
On Sat, 16 Aug 2003, Stephen Colebourne wrote: In examining the release, I found I need to annoy everyone again. *aarggh* :) WordWrapUtils is broken. No no no. It's a feature. The algorithm relies on a newLineChars parameter that is used for two purposes. 1) Splitting the input string 2) Adding newlines to the output string This is a new class, so it should either be pulled (preferred) or fixed (not preferred, as there are various issues) +1 to pulled out for consideration for 2.1/other. Related issue - WordWrapUtils is too specific a name. I propose: 1) changing it to WordUtils (or StringWordUtils) +1 on WordUtils. More generic. 2) moving capitalizeAllWords to WordUtils 3) moving uncapitalizeAllWords to WordUtils 4) moving swapCase to WordUtils +1 for 2.1/3.0. This would help reduce the size of StringUtils, and provide much better functional grouping. There is lots we can do with words. (Of course you could argue for a separate [text] project, but I doubt there is that much.) -1 to [text] taking the above until [text] is ready for 1.0. I am +1 for a [text], in the same way I'm +1 for [math], but I don't want us to deprecate our methods until [math] releases at 1.0 with our methods included. I would like to do this for 2.0, as otherwise users of capitaliseAllWords will have to change twice. However we could say that is a small group of people and postpone the change to 2.1. Opinions? There are going to be changes on the new features before 2.1/3.0, and it's going to be a year probably until we have a 3.0 out [though 2.0.1 or 2.1 might be quicker]. I may be being lazy, but I don't think that going with WordUtils right now would affect too many people and we don't really have enough knowledge right now to get it right for 2.0. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[docs] extra menus for mavenised components
one of the problems with the current commons website is that most mavenized components do not carry links back into jakarta-commons. i think that a major reason for this is that these have to maintained separately for each component and can easily become out-of-date. i've been playing around today and would like to offer a (partial) solution. it's possible to declare the menu entries as entities in a DTD. this DTD can include these from xml fragment files. the information would be moved from the project.xml into fragments and referenced from a DTD. (yes, i know that XInclude's are much better but it would involve extra overhead and extra learning for people. this way means that the existing process can be retained.) anyway, in practice this means that by adding a DTD definition to the top of a navigation.xml, mavenized components will be able to choose to include menus from the jakarta commons main menu. ever time that the documentation is rebuilt, the most up to date versions will be grabbed and used - zero maintenance for the component. unless some folks come up with some good reasons not to do this, i'll move the menus from the project.xml into xml fragment files sometime soon. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Words - for 2.0
So, not too aarggh then, just pull WordWrapUtils ;-)) (The other stuff this morning was all javadoc except for ToStringStyle where a method rename took place with deprecation) Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, August 16, 2003 5:56 PM Subject: Re: [lang] Words - for 2.0 On Sat, 16 Aug 2003, Stephen Colebourne wrote: In examining the release, I found I need to annoy everyone again. *aarggh* :) WordWrapUtils is broken. No no no. It's a feature. The algorithm relies on a newLineChars parameter that is used for two purposes. 1) Splitting the input string 2) Adding newlines to the output string This is a new class, so it should either be pulled (preferred) or fixed (not preferred, as there are various issues) +1 to pulled out for consideration for 2.1/other. Related issue - WordWrapUtils is too specific a name. I propose: 1) changing it to WordUtils (or StringWordUtils) +1 on WordUtils. More generic. 2) moving capitalizeAllWords to WordUtils 3) moving uncapitalizeAllWords to WordUtils 4) moving swapCase to WordUtils +1 for 2.1/3.0. This would help reduce the size of StringUtils, and provide much better functional grouping. There is lots we can do with words. (Of course you could argue for a separate [text] project, but I doubt there is that much.) -1 to [text] taking the above until [text] is ready for 1.0. I am +1 for a [text], in the same way I'm +1 for [math], but I don't want us to deprecate our methods until [math] releases at 1.0 with our methods included. I would like to do this for 2.0, as otherwise users of capitaliseAllWords will have to change twice. However we could say that is a small group of people and postpone the change to 2.1. Opinions? There are going to be changes on the new features before 2.1/3.0, and it's going to be a year probably until we have a 3.0 out [though 2.0.1 or 2.1 might be quicker]. I may be being lazy, but I don't think that going with WordUtils right now would affect too many people and we don't really have enough knowledge right now to get it right for 2.0. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22464] - [math] binomail distribution patch
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=22464. 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=22464 [math] binomail distribution patch [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-16 17:09 --- Patch applied, compiled, unit tested and committed. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] JLink for Mathematica and Generic API's
Hey guys, Have any of you checked out JLink for mathematica? This is a very interesting JNI bridge for Mathematica. I find it kinda interesting because they use a Functor pattern in the Eval class of this package. http://www.wolfram.com/solutions/mathlink/jlink/ I'm also looking at the Omegahat Project for intersting usage that may relate back to our library in our future: http://www.omegahat.org/ Specifically, this is an interesting XML Markup for Statistics that R and Matlab currently provide. http://www.omegahat.org/StatDataML/ I also notice theres support for this in Octave www.octave.org as well. I know this is actually outside of the scope of development for commons math. But, I think its interesting to see where all these projects are going in terms of Java development, cross language interaction and the exposure of their api's. One interest to me is defining a subset of functionality across all these applications that can also applies to commons math. I'm interested in the possibility of a specification/api that can be used to define statistical/mathematical evaluations in java. A generic api that one could write an evaluation in which could be executed against any provider, similar in nature to JAXP or JNDI. -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22464] - [math] binomail distribution patch
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=22464. 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=22464 [math] binomail distribution patch --- Additional Comments From [EMAIL PROTECTED] 2003-08-16 17:24 --- Just a heads up. Maybe we should make it a practice to take ownership of these tickets when we work on them so that others do not attempt the same. I attempted to commit this patch during / just after your commit and got all kinds of conflict errors. If its status had changed ownership eariler I would not have gone through the process while you were working on it too. :-) -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Words - for 2.0
Stephen Colebourne wrote: So, not too aarggh then, just pull WordWrapUtils ;-)) +1. I agree with Hen's views on WordUtils. Phil (The other stuff this morning was all javadoc except for ToStringStyle where a method rename took place with deprecation) Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, August 16, 2003 5:56 PM Subject: Re: [lang] Words - for 2.0 On Sat, 16 Aug 2003, Stephen Colebourne wrote: In examining the release, I found I need to annoy everyone again. *aarggh* :) WordWrapUtils is broken. No no no. It's a feature. The algorithm relies on a newLineChars parameter that is used for two purposes. 1) Splitting the input string 2) Adding newlines to the output string This is a new class, so it should either be pulled (preferred) or fixed (not preferred, as there are various issues) +1 to pulled out for consideration for 2.1/other. Related issue - WordWrapUtils is too specific a name. I propose: 1) changing it to WordUtils (or StringWordUtils) +1 on WordUtils. More generic. 2) moving capitalizeAllWords to WordUtils 3) moving uncapitalizeAllWords to WordUtils 4) moving swapCase to WordUtils +1 for 2.1/3.0. This would help reduce the size of StringUtils, and provide much better functional grouping. There is lots we can do with words. (Of course you could argue for a separate [text] project, but I doubt there is that much.) -1 to [text] taking the above until [text] is ready for 1.0. I am +1 for a [text], in the same way I'm +1 for [math], but I don't want us to deprecate our methods until [math] releases at 1.0 with our methods included. I would like to do this for 2.0, as otherwise users of capitaliseAllWords will have to change twice. However we could say that is a small group of people and postpone the change to 2.1. Opinions? There are going to be changes on the new features before 2.1/3.0, and it's going to be a year probably until we have a 3.0 out [though 2.0.1 or 2.1 might be quicker]. I may be being lazy, but I don't think that going with WordUtils right now would affect too many people and we don't really have enough knowledge right now to get it right for 2.0. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester SetPropertiesRule.java
craigmcc2003/08/16 11:02:56
Modified:digester/src/java/org/apache/commons/digester
SetPropertiesRule.java
Log:
Avoid an NPE when debugging is enabled and there is no top object
on the Digester stack.
PR: Bugzilla #22131
Reported By: r1akhil at ibm.com
Revision ChangesPath
1.12 +12 -6
jakarta-commons/digester/src/java/org/apache/commons/digester/SetPropertiesRule.java
Index: SetPropertiesRule.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/SetPropertiesRule.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- SetPropertiesRule.java16 Apr 2003 11:23:50 - 1.11
+++ SetPropertiesRule.java16 Aug 2003 18:02:56 - 1.12
@@ -253,8 +253,14 @@
// Populate the corresponding properties of the top object
Object top = digester.peek();
if (digester.log.isDebugEnabled()) {
-digester.log.debug([SetPropertiesRule]{ + digester.match +
-} Set + top.getClass().getName() + properties);
+if (top != null) {
+digester.log.debug([SetPropertiesRule]{ + digester.match +
+ } Set + top.getClass().getName() +
+properties);
+} else {
+digester.log.debug([SetPropertiesRule]{ + digester.match +
+ } Set NULL properties);
+}
}
BeanUtils.populate(top, values);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22131] - setting the log level to debug throws NPE
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=22131. 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=22131 setting the log level to debug throws NPE [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-16 18:05 --- Fixed in nightly build 20030817. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docs] extra menus for mavenised components
+1 for this. Do you have a url example of what change we can expect to see to a mavenised project? Hen On Sat, 16 Aug 2003, robert burrell donkin wrote: one of the problems with the current commons website is that most mavenized components do not carry links back into jakarta-commons. i think that a major reason for this is that these have to maintained separately for each component and can easily become out-of-date. i've been playing around today and would like to offer a (partial) solution. it's possible to declare the menu entries as entities in a DTD. this DTD can include these from xml fragment files. the information would be moved from the project.xml into fragments and referenced from a DTD. (yes, i know that XInclude's are much better but it would involve extra overhead and extra learning for people. this way means that the existing process can be retained.) anyway, in practice this means that by adding a DTD definition to the top of a navigation.xml, mavenized components will be able to choose to include menus from the jakarta commons main menu. ever time that the documentation is rebuilt, the most up to date versions will be grabbed and used - zero maintenance for the component. unless some folks come up with some good reasons not to do this, i'll move the menus from the project.xml into xml fragment files sometime soon. - robert - 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-sandbox/math/src/test/org/apache/commons/math/stat/distribution BinomialDistributionTest.java DistributionFactoryImplTest.java
pietsch 2003/08/16 10:06:15
Modified:math/src/java/org/apache/commons/math/stat/distribution
DistributionFactory.java
DistributionFactoryImpl.java
math/src/test/org/apache/commons/math/stat/distribution
DistributionFactoryImplTest.java
Added: math/src/java/org/apache/commons/math/stat/distribution
AbstractDiscreteDistribution.java
BinomialDistribution.java
BinomialDistributionImpl.java
DiscreteDistribution.java
math/src/test/org/apache/commons/math/stat/distribution
BinomialDistributionTest.java
Log:
Added classes for binominal distribution and some infrastructure for other
discrete distributions.
Contributed by Brent Worden ([EMAIL PROTECTED])
Revision ChangesPath
1.10 +14 -2
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/distribution/DistributionFactory.java
Index: DistributionFactory.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/distribution/DistributionFactory.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- DistributionFactory.java 30 Jul 2003 21:58:11 - 1.9
+++ DistributionFactory.java 16 Aug 2003 17:06:15 - 1.10
@@ -57,7 +57,9 @@
* This factory provids the means to create common statistical distributions.
* The following distributions are supported:
* ul
+ * liBinomial/li
* liChi-Squared/li
+ * liExponential/li
* liF/li
* liGamma/li
* liStudent's t/li
@@ -89,7 +91,17 @@
public static DistributionFactory newInstance() {
return new DistributionFactoryImpl();
}
-
+
+/**
+ * Create a binomial distribution with the given number of trials and
+ * probability of success.
+ * @param numberOfTrials the number of trials.
+ * @param probabilityOfSuccess the probability of success.
+ * @return a new binomial distribution.
+ */
+public abstract BinomialDistribution createBinomailDistribution(
+int numberOfTrials, double probabilityOfSuccess);
+
/**
* Create a new chi-square distribution with the given degrees of freedom.
* @param degreesOfFreedom degrees of freedom.
1.8 +14 -1
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/distribution/DistributionFactoryImpl.java
Index: DistributionFactoryImpl.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/distribution/DistributionFactoryImpl.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- DistributionFactoryImpl.java 9 Jul 2003 20:03:23 - 1.7
+++ DistributionFactoryImpl.java 16 Aug 2003 17:06:15 - 1.8
@@ -122,4 +122,17 @@
return new ExponentialDistributionImpl(mean);
}
+/**
+ * Create a binomial distribution with the given number of trials and
+ * probability of success.
+ * @param numberOfTrials the number of trials.
+ * @param probabilityOfSuccess the probability of success.
+ * @return a new binomial distribution.
+ */
+public BinomialDistribution createBinomailDistribution(
+int numberOfTrials, double probabilityOfSuccess) {
+return new BinomialDistributionImpl(numberOfTrials,
+probabilityOfSuccess);
+}
+
}
1.1
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/distribution/AbstractDiscreteDistribution.java
Index: AbstractDiscreteDistribution.java
===
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
Re: [lang] Words - for 2.0
I'd just woken up :) I've emailed Henning [who originally asked for WordWrapUtils to be released] so that he can react. Shall I build an RC3 with the new javadoc and WordWrapUtils removed? Hen On Sat, 16 Aug 2003, Stephen Colebourne wrote: So, not too aarggh then, just pull WordWrapUtils ;-)) (The other stuff this morning was all javadoc except for ToStringStyle where a method rename took place with deprecation) Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, August 16, 2003 5:56 PM Subject: Re: [lang] Words - for 2.0 On Sat, 16 Aug 2003, Stephen Colebourne wrote: In examining the release, I found I need to annoy everyone again. *aarggh* :) WordWrapUtils is broken. No no no. It's a feature. The algorithm relies on a newLineChars parameter that is used for two purposes. 1) Splitting the input string 2) Adding newlines to the output string This is a new class, so it should either be pulled (preferred) or fixed (not preferred, as there are various issues) +1 to pulled out for consideration for 2.1/other. Related issue - WordWrapUtils is too specific a name. I propose: 1) changing it to WordUtils (or StringWordUtils) +1 on WordUtils. More generic. 2) moving capitalizeAllWords to WordUtils 3) moving uncapitalizeAllWords to WordUtils 4) moving swapCase to WordUtils +1 for 2.1/3.0. This would help reduce the size of StringUtils, and provide much better functional grouping. There is lots we can do with words. (Of course you could argue for a separate [text] project, but I doubt there is that much.) -1 to [text] taking the above until [text] is ready for 1.0. I am +1 for a [text], in the same way I'm +1 for [math], but I don't want us to deprecate our methods until [math] releases at 1.0 with our methods included. I would like to do this for 2.0, as otherwise users of capitaliseAllWords will have to change twice. However we could say that is a small group of people and postpone the change to 2.1. Opinions? There are going to be changes on the new features before 2.1/3.0, and it's going to be a year probably until we have a 3.0 out [though 2.0.1 or 2.1 might be quicker]. I may be being lazy, but I don't think that going with WordUtils right now would affect too many people and we don't really have enough knowledge right now to get it right for 2.0. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester/xmlrules DigesterRuleParser.java FromXmlRuleSet.java
craigmcc2003/08/16 11:18:26
Modified:digester/src/java/org/apache/commons/digester
FactoryCreateRule.java SetPropertiesRule.java
SetPropertyRule.java
digester/src/java/org/apache/commons/digester/rss
Channel.java
digester/src/java/org/apache/commons/digester/xmlrules
DigesterRuleParser.java FromXmlRuleSet.java
Log:
Cosmetic changes only, no functionality changes:
* Cleaned up Javadoc generation warnings under JDK 1.4.2.
* A few miscellaneous typos and 80 column comments
Revision ChangesPath
1.13 +11 -9
jakarta-commons/digester/src/java/org/apache/commons/digester/FactoryCreateRule.java
Index: FactoryCreateRule.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/FactoryCreateRule.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- FactoryCreateRule.java16 Apr 2003 11:23:50 - 1.12
+++ FactoryCreateRule.java16 Aug 2003 18:18:26 - 1.13
@@ -275,7 +275,8 @@
* then be used to create an object and push it on the stack.
*
* @param className Java class name of the object creation factory class
- * @param ignoreCreateException if true, exceptions thrown by the object
creation factory
+ * @param ignoreCreateExceptions if true, exceptions thrown by the object
+ * creation factory
* will be ignored.
*/
public FactoryCreateRule(String className, boolean ignoreCreateExceptions) {
@@ -291,7 +292,8 @@
* then be used to create an object and push it on the stack.
*
* @param clazz Java class name of the object creation factory class
- * @param ignoreCreateException if true, exceptions thrown by the object
creation factory
+ * @param ignoreCreateExceptions if true, exceptions thrown by the
+ * object creation factory
* will be ignored.
*/
public FactoryCreateRule(Class clazz, boolean ignoreCreateExceptions) {
@@ -310,8 +312,8 @@
* @param className Default Java class name of the factory class
* @param attributeName Attribute name which, if present, contains an
* override of the class name of the object creation factory to create.
- * @param ignoreCreateException if true, exceptions thrown by the object
creation factory
- * will be ignored.
+ * @param ignoreCreateExceptions if true, exceptions thrown by the object
+ * creation factory will be ignored.
*/
public FactoryCreateRule(
String className,
@@ -334,8 +336,8 @@
* @param clazz Default Java class name of the factory class
* @param attributeName Attribute name which, if present, contains an
* override of the class name of the object creation factory to create.
- * @param ignoreCreateException if true, exceptions thrown by the object
creation factory
- * will be ignored.
+ * @param ignoreCreateExceptions if true, exceptions thrown by the object
+ * creation factory will be ignored.
*/
public FactoryCreateRule(
Class clazz,
@@ -352,8 +354,8 @@
* [EMAIL PROTECTED] ObjectCreationFactory}.
*
* @param creationFactory called on to create the object.
- * @param ignoreCreateException if true, exceptions thrown by the object
creation factory
- * will be ignored.
+ * @param ignoreCreateExceptions if true, exceptions thrown by the object
+ * creation factory will be ignored.
*/
public FactoryCreateRule(
ObjectCreationFactory creationFactory,
1.13 +5 -6
jakarta-commons/digester/src/java/org/apache/commons/digester/SetPropertiesRule.java
Index: SetPropertiesRule.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/SetPropertiesRule.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- SetPropertiesRule.java16 Aug 2003 18:02:56 - 1.12
+++ SetPropertiesRule.java16 Aug 2003 18:18:26 - 1.13
@@ -165,7 +165,7 @@
* /pre/code
*
* @param attributeNames names of attributes to map
- * @param proeprtyNames names of properties mapped to
+ * @param propertyNames names of properties mapped to
*/
public SetPropertiesRule(String[] attributeNames, String[] propertyNames) {
// create local copies
@@ -198,7 +198,6 @@
/**
* Process the beginning of this element.
*
- * @param context The associated context
* @param attributes The
cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging/impl AvalonLogger.java SimpleLog.java
craigmcc2003/08/16 11:21:50
Modified:logging/src/java/org/apache/commons/logging/impl
AvalonLogger.java SimpleLog.java
Log:
Cosmetic changes only - clean up JDK 1.4.2 javadoc generation warnings.
Revision ChangesPath
1.3 +5 -5
jakarta-commons/logging/src/java/org/apache/commons/logging/impl/AvalonLogger.java
Index: AvalonLogger.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/AvalonLogger.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- AvalonLogger.java 14 May 2003 11:12:58 - 1.2
+++ AvalonLogger.java 16 Aug 2003 18:21:50 - 1.3
@@ -84,7 +84,7 @@
}
/**
- * @param logger the avalon logger implementation to delegate to
+ * @param name the name of the avalon logger implementation to delegate to
*/
public AvalonLogger(String name) {
if (defaultLogger == null)
1.11 +5 -5
jakarta-commons/logging/src/java/org/apache/commons/logging/impl/SimpleLog.java
Index: SimpleLog.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/SimpleLog.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- SimpleLog.java15 Jul 2003 15:47:38 - 1.10
+++ SimpleLog.java16 Aug 2003 18:21:50 - 1.11
@@ -271,7 +271,7 @@
/**
* p Set logging level. /p
*
- * @param level new logging level
+ * @param currentLogLevel new logging level
*/
public void setLevel(int currentLogLevel) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Words - for 2.0
+1 to RC3 BTW, is there a problem with building with 1.2.2 if our javadoc has been optimised for 1.4? The javadoc compiler has changed. Can the docs be built using 1.4 instead? Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, August 16, 2003 7:14 PM Subject: Re: [lang] Words - for 2.0 I'd just woken up :) I've emailed Henning [who originally asked for WordWrapUtils to be released] so that he can react. Shall I build an RC3 with the new javadoc and WordWrapUtils removed? Hen On Sat, 16 Aug 2003, Stephen Colebourne wrote: So, not too aarggh then, just pull WordWrapUtils ;-)) (The other stuff this morning was all javadoc except for ToStringStyle where a method rename took place with deprecation) Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, August 16, 2003 5:56 PM Subject: Re: [lang] Words - for 2.0 On Sat, 16 Aug 2003, Stephen Colebourne wrote: In examining the release, I found I need to annoy everyone again. *aarggh* :) WordWrapUtils is broken. No no no. It's a feature. The algorithm relies on a newLineChars parameter that is used for two purposes. 1) Splitting the input string 2) Adding newlines to the output string This is a new class, so it should either be pulled (preferred) or fixed (not preferred, as there are various issues) +1 to pulled out for consideration for 2.1/other. Related issue - WordWrapUtils is too specific a name. I propose: 1) changing it to WordUtils (or StringWordUtils) +1 on WordUtils. More generic. 2) moving capitalizeAllWords to WordUtils 3) moving uncapitalizeAllWords to WordUtils 4) moving swapCase to WordUtils +1 for 2.1/3.0. This would help reduce the size of StringUtils, and provide much better functional grouping. There is lots we can do with words. (Of course you could argue for a separate [text] project, but I doubt there is that much.) -1 to [text] taking the above until [text] is ready for 1.0. I am +1 for a [text], in the same way I'm +1 for [math], but I don't want us to deprecate our methods until [math] releases at 1.0 with our methods included. I would like to do this for 2.0, as otherwise users of capitaliseAllWords will have to change twice. However we could say that is a small group of people and postpone the change to 2.1. Opinions? There are going to be changes on the new features before 2.1/3.0, and it's going to be a year probably until we have a 3.0 out [though 2.0.1 or 2.1 might be quicker]. I may be being lazy, but I don't think that going with WordUtils right now would affect too many people and we don't really have enough knowledge right now to get it right for 2.0. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Looking to the next version
Although I'm not a huge maven fan (yet), I am +0.5 this :-) Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] One idea I'd like to throw into the mix for the next version of Lang [or maybe it'd still be 2.0 in this case] is to move to a Maven site and use Maven as our primary build. While we're getting Lang out the door, I thought I'd see what people's reaction is to this. We'd get a proper clover licence and publish that, I imagine JDiff can be integrated in, etc etc. Hen - 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]
File commons
Recently I did some project that included traversing directories, for
files, or directories only. In the process I used cli, so to payback I
want to donate DirectoryIterator to commons-lang project. This is
non-recursive iterator. Can be very useful, and can save a lot of time
when dealing with directories, and files. The file is dependent on java2
(LinkedList used as stack) but it is not difficult for me to change it
to use Stack, or vector, or something from commons-collections. As
example of use there is Prune example witch uses iterator to prune all
empty folders in some given root.
If you like it you can put it in commons. If it's inappropriate to post
things this way, please explain me how to propose things in the future.
Mit freundlichen Gren,
Best Regards,
River
Intertele AG
import java.io.File;
/**
* Simple command line program that prunes empty directories given arbitrary
* path.
* @author codeRiver/code
* @version 1.0
*/
public class Prune {
/**
* Entery point of this program
* @param args command line arguments
*/
public static void main(String[] args) {
if (args.length == 0) {
printUsage();
System.exit(-1);
}
File root = new File(args[0]);
if (root.list() != null root.list().length == 0) {
rmdir(root);
} else {
DirectoryIterator iter = new DirectoryIterator(root,
DirectoryIterator.DIRS_ONLY);
while (iter.hasNext()) {
File dir = iter.nextFile();
System.out.println(Examing: + dir);
String[] children = dir.list();
if (children != null children.length == 0) {
rmdir(dir);
File parent = dir.getParentFile();
while ( (parent.list() != null)
(parent.list().length == 0)) {
rmdir(parent);
if (parent.equals(root)) {
break; // do not pass root;
}
parent = parent.getParentFile();
}
}
}
}
}
private static void rmdir(File dir) {
System.out.print(REMOVING EMPTY DIR: + dir + ... );
if (dir.delete()) {
System.out.println(ok);
} else {
System.out.println(FAILED);
}
}
private static void printUsage() {
System.err.println( Usage:);
System.err.println( java + Prune.class.getName() + dir);
}
}import java.io.File;
import java.io.FileFilter;
import java.util.Iterator;
import java.util.LinkedList;
/**
* Class that give ability to user to iterate through directories. Actualy
* implementation uses files for iteration, but since directory iteration is
* most common usage example of this class name is DirectoryIterator, and not
* FileIterator.
*
* @author codeRiver/code
* @version 1.0
*/
public class DirectoryIterator implements Iterator {
/**
* Convinient implementation of FileFilter interface that accepts files
* and directories.
*/
public static final FileFilter ALL = new FileFilter() {
public boolean accept(File file) {
return true;
}
};
/**
* Implementation of FileFilter interface that accepts only files. This
* implementation is here just for the sake of style, since with that
* filter class is behaving like iterator over
* coderoot.listFiles()/code array.
*/
public static final FileFilter FILES_ONLY = new FileFilter() {
public boolean accept(File file) {
return file.isFile();
}
};
/**
* Implementation of FileFilter interface that accepts only directories.
*/
public static final FileFilter DIRS_ONLY = new FileFilter() {
public boolean accept(File file) {
return file.isDirectory();
}
};
private final File root;
private final LinkedList todo = new LinkedList();
private final FileFilter filter;
private File last = null;
/**
* Create iterator with coderoot/code as starting point of iteration.
* Note that root will never be returned from nextXXX() methods.
* @param root
*/
public DirectoryIterator(File root) {
this(root, ALL);
}
/**
* Create iterator over coderoot/code using codefilter/code
* FileFilter.Note that root will never be returned
* from nextXXX() methods.
* @param root root directory for iteration
* @param filter FileFilter implementation that will
* limit returned objects.
*/
public DirectoryIterator(File root, FileFilter filter) {
if (root == null) {
throw new IllegalArgumentException(root can't be null);
}
if (filter == null) {
filter = ALL;
}
this.root = root;
this.filter =
Re: [lang] Looking to the next version
Henri Yandell wrote: One idea I'd like to throw into the mix for the next version of Lang [or maybe it'd still be 2.0 in this case] is to move to a Maven site and use Maven as our primary build. While we're getting Lang out the door, I thought I'd see what people's reaction is to this. We'd get a proper clover licence and publish that, I imagine JDiff can be integrated in, etc etc. +1 -- especially the clover license bit. I would wait to change over until post 2.0 though, when we can also build out the web site a little better. As a half-measure, we could patch project.xml to make maven work better now. I have a locally modified version that I could diff if we want to do that. Hen - 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]
[io] Re: File commons
This is probably better placed in commons-io, which is slowly winding its way out of the sandbox. Still, sounds very useful. Hen On Sat, 16 Aug 2003, River wrote: Recently I did some project that included traversing directories, for files, or directories only. In the process I used cli, so to payback I want to donate DirectoryIterator to commons-lang project. This is non-recursive iterator. Can be very useful, and can save a lot of time when dealing with directories, and files. The file is dependent on java2 (LinkedList used as stack) but it is not difficult for me to change it to use Stack, or vector, or something from commons-collections. As example of use there is Prune example witch uses iterator to prune all empty folders in some given root. If you like it you can put it in commons. If it's inappropriate to post things this way, please explain me how to propose things in the future. Mit freundlichen Grüßen, Best Regards, River Intertele AG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Looking to the next version
I also thought that the results Henri posted from findbugs (http://www.cs.umd.edu/~pugh/java/bugs/) were very useful. I downloaded the program and have begun to use it, it catches a lot of errors which are easy to miss. I may look into writing a Maven plugin for this, if someone hasn't already. It could be a nice project report to go along with clover, checkstyle, etc. On Sat, 2003-08-16 at 11:29, Stephen Colebourne wrote: Although I'm not a huge maven fan (yet), I am +0.5 this :-) Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] One idea I'd like to throw into the mix for the next version of Lang [or maybe it'd still be 2.0 in this case] is to move to a Maven site and use Maven as our primary build. While we're getting Lang out the door, I thought I'd see what people's reaction is to this. We'd get a proper clover licence and publish that, I imagine JDiff can be integrated in, etc etc. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [io] Re: File commons
Yes, commons-io is better place since classes used are from io package. Sorry for missing [xxx] identifier, it was a slip.. Mit freundlichen Gren, Best Regards, River -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Saturday, August 16, 2003 9:53 PM To: Jakarta Commons Developers List Subject: [io] Re: File commons This is probably better placed in commons-io, which is slowly winding its way out of the sandbox. Still, sounds very useful. Hen On Sat, 16 Aug 2003, River wrote: Recently I did some project that included traversing directories, for files, or directories only. In the process I used cli, so to payback I want to donate DirectoryIterator to commons-lang project. This is non-recursive iterator. Can be very useful, and can save a lot of time when dealing with directories, and files. The file is dependent on java2 (LinkedList used as stack) but it is not difficult for me to change it to use Stack, or vector, or something from commons-collections. As example of use there is Prune example witch uses iterator to prune all empty folders in some given root. If you like it you can put it in commons. If it's inappropriate to post things this way, please explain me how to propose things in the future. Mit freundlichen Gren, Best Regards, River Intertele AG - 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]
[lang] 1.2 vs 1.4 Was: [lang] Words - for 2.0
On Sat, 16 Aug 2003, Stephen Colebourne wrote: +1 to RC3 BTW, is there a problem with building with 1.2.2 if our javadoc has been optimised for 1.4? The javadoc compiler has changed. Can the docs be built using 1.4 instead? Ack. So we want a 1.2 built jar and a 1.4 built javadoc? Maybe I should just go ahead and use 1.4 to distribute. While I could merge a 1.4 and 1.2 set of builds, it wouldn't be something the user could repeat with the -src jar. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Looking to the next version
Matt, Before you get to far, I have written a plugin for Findbugs... I am currently trying to get in touch with the folks running mavenplugins.sf.net to get it added there... I think though people might be on vacation.. At any rate, the findbugs folks are discussing changing the license to asf compatible, whereupon we could put the plugin in the maven core. I am attaching my code, note though it is still pretty raw. Findbugs the next version will have a better classloader. For now now, you have to have all the jars in the lib dir in the plugin. I removed them for the email though.. If you make any improvements, send me a patch file until I can get this up on the maven plugins sourceforge site. Eric Pugh -Original Message- From: __matthewHawthorne [mailto:[EMAIL PROTECTED] Sent: Saturday, August 16, 2003 10:24 PM To: Jakarta Commons Developers List Subject: Re: [lang] Looking to the next version I also thought that the results Henri posted from findbugs (http://www.cs.umd.edu/~pugh/java/bugs/) were very useful. I downloaded the program and have begun to use it, it catches a lot of errors which are easy to miss. I may look into writing a Maven plugin for this, if someone hasn't already. It could be a nice project report to go along with clover, checkstyle, etc. On Sat, 2003-08-16 at 11:29, Stephen Colebourne wrote: Although I'm not a huge maven fan (yet), I am +0.5 this :-) Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] One idea I'd like to throw into the mix for the next version of Lang [or maybe it'd still be 2.0 in this case] is to move to a Maven site and use Maven as our primary build. While we're getting Lang out the door, I thought I'd see what people's reaction is to this. We'd get a proper clover licence and publish that, I imagine JDiff can be integrated in, etc etc. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] findbugs.zip Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/logging/src/test/org/apache/commons/logging/simple - New directory
craigmcc2003/08/16 14:24:39 jakarta-commons/logging/src/test/org/apache/commons/logging/simple - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/logging/src/test/org/apache/commons/logging/simple CustomConfigTestCase.java DecoratedSimpleLog.java DefaultConfigTestCase.java LogRecord.java
craigmcc2003/08/16 14:25:54
Modified:logging build.xml
logging/src/java/org/apache/commons/logging/impl
SimpleLog.java
Added: logging/src/test/org/apache/commons/logging/simple
CustomConfigTestCase.java DecoratedSimpleLog.java
DefaultConfigTestCase.java LogRecord.java
Log:
Make o.a.c.l.impl.SimpleLog Serializable.
Add more comprehensive unit tests for SimpleLog, including the ability
to serialize and deserialize instances.
This work will form the basis for making similar changes to the other
Log implementations (and their corresponding test cases).
Revision ChangesPath
1.39 +33 -5 jakarta-commons/logging/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/logging/build.xml,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- build.xml 22 May 2003 13:55:28 - 1.38
+++ build.xml 16 Aug 2003 21:25:53 - 1.39
@@ -396,15 +396,18 @@
!-- == Unit Test Targets = --
- target name=test depends=compile.tests,test.jdk14,test.log4j,test.avalon
- if=test.entry
+ target name=test
+ depends=compile.tests,test.jdk14,test.log4j,test.simple,test.avalon
+if=test.entry
description=Run all unit test cases
- java classname=${test.runner} fork=yes failonerror=${test.failonerror}
-arg value=${test.entry}/
+ javaclassname=${test.runner} fork=yes
+ failonerror=${test.failonerror}
+arg value=${test.entry}/
classpath refid=test.classpath/
/java
/target
+
target name=test.jdk14 depends=compile.tests if=jdk.1.4.present
description=Run unit tests specific to JDK 1.4 logging
@@ -645,6 +648,31 @@
/java
/target
+
+
+ target name=test.simple depends=compile.tests
+ description=Run unit tests specific to SimpleLog logging
+
+echo message=Default Configuration (SimpleLog Selected)/
+java classname=${test.runner} fork=yes failonerror=${test.failonerror}
+ sysproperty key=org.apache.commons.logging.Log
+ value=org.apache.commons.logging.impl.SimpleLog/
+ arg value=org.apache.commons.logging.simple.DefaultConfigTestCase/
+ classpath refid=test.classpath/
+/java
+
+echo message=Custom Configuration (SimpleLog Selected)/
+java classname=${test.runner} fork=yes failonerror=${test.failonerror}
+ sysproperty key=org.apache.commons.logging.Log
+ value=org.apache.commons.logging.simple.DecoratedSimpleLog/
+ sysproperty key=org.apache.commons.logging.simplelog.defaultlog
+ value=debug/
+ arg value=org.apache.commons.logging.simple.CustomConfigTestCase/
+ classpath refid=test.classpath/
+/java
+
+ /target
+
target name=test.avalon depends=compile.tests if=avalon-framework.present
description=Run unit tests specific to Avalon (Framework) logging
1.12 +6 -5
jakarta-commons/logging/src/java/org/apache/commons/logging/impl/SimpleLog.java
Index: SimpleLog.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/SimpleLog.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- SimpleLog.java16 Aug 2003 18:21:50 - 1.11
+++ SimpleLog.java16 Aug 2003 21:25:54 - 1.12
@@ -63,6 +63,7 @@
package org.apache.commons.logging.impl;
import java.io.InputStream;
+import java.io.Serializable;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.security.AccessController;
@@ -110,7 +111,7 @@
*
* @version $Id$
*/
-public class SimpleLog implements Log {
+public class SimpleLog implements Log, Serializable {
// --- Class Attributes
1.1
jakarta-commons/logging/src/test/org/apache/commons/logging/simple/CustomConfigTestCase.java
Index: CustomConfigTestCase.java
===
/*
* $Header:
/home/cvs/jakarta-commons/logging/src/test/org/apache/commons/logging/simple/CustomConfigTestCase.java,v
1.1 2003/08/16 21:25:54 craigmcc Exp $
* $Revision: 1.1 $
* $Date: 2003/08/16 21:25:54 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms,
commons e-mail
is commons e-mail beeing developed? .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/logging/src/test/org/apache/commons/logging/log4j CustomConfigTestCase.java DefaultConfigTestCase.java
craigmcc2003/08/16 14:58:59
Modified:logging/src/java/org/apache/commons/logging/impl
AvalonLogger.java Jdk14Logger.java Log4JLogger.java
LogKitLogger.java
logging/src/test/org/apache/commons/logging/jdk14
CustomConfigTestCase.java
DefaultConfigTestCase.java
logging/src/test/org/apache/commons/logging/log4j
CustomConfigTestCase.java
DefaultConfigTestCase.java
Log:
Make the remaining non-deprecated Log implementations also implement
Serializable, and enhance the unit tests for JDK 1.4 an Log4J logging
to validate the ability to deserialize and use such instances.
Revision ChangesPath
1.4 +31 -25
jakarta-commons/logging/src/java/org/apache/commons/logging/impl/AvalonLogger.java
Index: AvalonLogger.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/AvalonLogger.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- AvalonLogger.java 16 Aug 2003 18:21:50 - 1.3
+++ AvalonLogger.java 16 Aug 2003 21:58:59 - 1.4
@@ -61,6 +61,7 @@
package org.apache.commons.logging.impl;
+import java.io.Serializable;
import org.apache.avalon.framework.logger.Logger;
import org.apache.commons.logging.Log;
@@ -71,15 +72,17 @@
* @author a href=mailto:[EMAIL PROTECTED]Neeme Praks/a
* @version $Revision$ $Date$
*/
-public class AvalonLogger implements Log {
+public class AvalonLogger implements Log, Serializable {
private static Logger defaultLogger = null;
-private Logger logger = null;
+private transient Logger logger = null;
+private String name = null;
/**
* @param logger the avalon logger implementation to delegate to
*/
public AvalonLogger(Logger logger) {
+this.name = name;
this.logger = logger;
}
@@ -89,13 +92,16 @@
public AvalonLogger(String name) {
if (defaultLogger == null)
throw new NullPointerException(default logger has to be specified if
this constructor is used!);
-this.logger = defaultLogger.getChildLogger(name);
+this.logger = getLogger();
}
/**
* @return avalon logger implementation
*/
public Logger getLogger() {
+if (logger == null) {
+logger = defaultLogger.getChildLogger(name);
+}
return logger;
}
@@ -110,126 +116,126 @@
* @see org.apache.commons.logging.Log#debug(java.lang.Object,
java.lang.Throwable)
*/
public void debug(Object o, Throwable t) {
-if (this.logger.isDebugEnabled()) this.logger.debug(String.valueOf(o), t);
+if (getLogger().isDebugEnabled()) getLogger().debug(String.valueOf(o), t);
}
/**
* @see org.apache.commons.logging.Log#debug(java.lang.Object)
*/
public void debug(Object o) {
-if (this.logger.isDebugEnabled()) this.logger.debug(String.valueOf(o));
+if (getLogger().isDebugEnabled()) getLogger().debug(String.valueOf(o));
}
/**
* @see org.apache.commons.logging.Log#error(java.lang.Object,
java.lang.Throwable)
*/
public void error(Object o, Throwable t) {
-if (this.logger.isErrorEnabled()) this.logger.error(String.valueOf(o), t);
+if (getLogger().isErrorEnabled()) getLogger().error(String.valueOf(o), t);
}
/**
* @see org.apache.commons.logging.Log#error(java.lang.Object)
*/
public void error(Object o) {
-if (this.logger.isErrorEnabled()) this.logger.error(String.valueOf(o));
+if (getLogger().isErrorEnabled()) getLogger().error(String.valueOf(o));
}
/**
* @see org.apache.commons.logging.Log#fatal(java.lang.Object,
java.lang.Throwable)
*/
public void fatal(Object o, Throwable t) {
-if (this.logger.isFatalErrorEnabled())
this.logger.fatalError(String.valueOf(o), t);
+if (getLogger().isFatalErrorEnabled())
getLogger().fatalError(String.valueOf(o), t);
}
/**
* @see org.apache.commons.logging.Log#fatal(java.lang.Object)
*/
public void fatal(Object o) {
-if (this.logger.isFatalErrorEnabled())
this.logger.fatalError(String.valueOf(o));
+if (getLogger().isFatalErrorEnabled())
getLogger().fatalError(String.valueOf(o));
}
/**
* @see org.apache.commons.logging.Log#info(java.lang.Object,
java.lang.Throwable)
*/
public void info(Object o, Throwable t) {
-if (this.logger.isInfoEnabled()) this.logger.info(String.valueOf(o), t);
+if
Re: [lang] 1.2 vs 1.4 Was: [lang] Words - for 2.0
Can we guarantee that the 1.4 built version is bytecode compatable with 1.2? Its not nice whichever way around you do it. How about build under 1.4, then use the jar to run the test cases against under 1.2? Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] On Sat, 16 Aug 2003, Stephen Colebourne wrote: +1 to RC3 BTW, is there a problem with building with 1.2.2 if our javadoc has been optimised for 1.4? The javadoc compiler has changed. Can the docs be built using 1.4 instead? Ack. So we want a 1.2 built jar and a 1.4 built javadoc? Maybe I should just go ahead and use 1.4 to distribute. While I could merge a 1.4 and 1.2 set of builds, it wouldn't be something the user could repeat with the -src jar. Hen - 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/logging/src/java/org/apache/commons/logging/impl Jdk13LumberjackLogger.java LogFactoryImpl.java
craigmcc2003/08/16 15:35:16
Modified:logging build.xml
logging/src/java/org/apache/commons/logging/impl
LogFactoryImpl.java
Added: logging/src/java/org/apache/commons/logging/impl
Jdk13LumberjackLogger.java
Log:
Add support for Lumberjack (a project that supports JSR-47 compatible
logging on a JDK 1.2 or JDK 1.3 system).
PR: Bugzilla #21455.
Submitted By: Vince Eagen vince256 at comcast.net
Revision ChangesPath
1.40 +3 -1 jakarta-commons/logging/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/logging/build.xml,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- build.xml 16 Aug 2003 21:25:53 - 1.39
+++ build.xml 16 Aug 2003 22:35:16 - 1.40
@@ -227,6 +227,8 @@
deprecation=${compile.deprecation}
optimize=${compile.optimize}
classpath refid=compile.classpath/
+ exclude name=org/apache/commons/logging/impl/Jdk13LumberjackLogger.java
+ unless=jdk.1.4.present/
exclude name=org/apache/commons/logging/impl/Jdk14Logger.java
unless=jdk.1.4.present/
exclude name=org/apache/commons/logging/impl/Log4J*.java
1.26 +31 -5
jakarta-commons/logging/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
Index: LogFactoryImpl.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- LogFactoryImpl.java 2 Apr 2003 01:53:04 - 1.25
+++ LogFactoryImpl.java 16 Aug 2003 22:35:16 - 1.26
@@ -369,6 +369,10 @@
logClassName = org.apache.commons.logging.impl.Jdk14Logger;
}
+if ((logClassName == null) isJdk13LumberjackAvailable()) {
+logClassName = org.apache.commons.logging.impl.Jdk13LumberjackLogger;
+}
+
if (logClassName == null) {
logClassName = org.apache.commons.logging.impl.SimpleLog;
}
@@ -478,13 +482,35 @@
/**
- * Is emJDK 1.4 or later/em logging available?
+ * Is emJDK 1.3 with Lumberjack/em logging available?
+ */
+protected boolean isJdk13LumberjackAvailable() {
+
+try {
+loadClass(java.util.logging.Logger);
+loadClass(org.apache.commons.logging.impl.Jdk13LumberjackLogger);
+return (true);
+} catch (Throwable t) {
+return (false);
+}
+
+}
+
+
+/**
+ * Is emJDK 1.4 or later/em logging available? Also checks that
+ * the Throwable class supports codegetStackTrace()/code, which is
+ * required by Jdk14Logger.
*/
protected boolean isJdk14Available() {
try {
loadClass(java.util.logging.Logger);
loadClass(org.apache.commons.logging.impl.Jdk14Logger);
+Class throwable = loadClass(java.lang.Throwable);
+if (throwable.getDeclaredMethod(getStackTrace, null) == null) {
+return (false);
+}
return (true);
} catch (Throwable t) {
return (false);
1.1
jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Jdk13LumberjackLogger.java
Index: Jdk13LumberjackLogger.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Commons, and
DO NOT REPLY [Bug 21455] - exception when logging in JDK 1.3 with Lumberjack
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=21455. 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=21455 exception when logging in JDK 1.3 with Lumberjack [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-16 22:38 --- Added in commons-logging nightly build 20030817. I also made the implementation Serializable in the same manner that the other Log implementations were just enhanced. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale/converters DoubleLocaleConverter.java
craigmcc2003/08/16 15:44:11
Modified:beanutils/src/java/org/apache/commons/beanutils/locale/converters
DoubleLocaleConverter.java
Log:
Make sure that DoubleLocaleConverter always returns a Double, even when
converting a String that contains only an integer value (and the normal
parse would return a Long instead).
PR: Bugzilla #21851
Patch Submitted By: Dejan Predovic (dpredovic at web.de)
Revision ChangesPath
1.4 +16 -3
jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale/converters/DoubleLocaleConverter.java
Index: DoubleLocaleConverter.java
===
RCS file:
/home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale/converters/DoubleLocaleConverter.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- DoubleLocaleConverter.java15 Jan 2003 21:59:43 - 1.3
+++ DoubleLocaleConverter.java16 Aug 2003 22:44:11 - 1.4
@@ -61,6 +61,8 @@
package org.apache.commons.beanutils.locale.converters;
+
+import java.text.ParseException;
import java.util.Locale;
@@ -241,6 +243,17 @@
super(defaultValue, locale, pattern);
}
+
+protected Object parse(Object value, String pattern) throws ParseException {
+Number result = (Number) super.parse(value, pattern);
+if (result instanceof Long) {
+return new Double(result.doubleValue());
+} else {
+return (result);
+}
+}
+
+
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21851] - BeanUtils.populate fails with DoubleLocaleConverter on integer values
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=21851. 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=21851 BeanUtils.populate fails with DoubleLocaleConverter on integer values [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-16 22:47 --- Fixed in nightly build 20030817. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21431] - Wrong PropertyDescriptor found
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=21431. 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=21431 Wrong PropertyDescriptor found [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-08-16 22:55 --- The reason this happens is that java.beans.Introspector follows a BeanInfo search path in order to locate any BeanInfo class that corresponds to a bean, before examining the bean class itself. The default BeanInfo search path includes a package that defines BeanInfo for a class called Component, so this BeanInfo is used for any user class that is also named Component. It would be unreasonable for commons-beanutils to make any changes in the BeanInfo search path that has been set. Therefore, you shoud work around this issue by calling Introspector.setBeanInfoSearchPath() with a list of packages that does not include the standard one (I'd suggest using a zero-length String array so that *no* searching is done), before calling any BeanUtils methods. See the Javadocs for java.beans.Introspector, and the JavaBeans spec, for more information. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] JLink for Mathematica and Generic API's
I know this is actually outside of the scope of development for commons math. But, I think its interesting to see where all these projects are going in terms of Java development, cross language interaction and the exposure of their api's. One interest to me is defining a subset of functionality across all these applications that can also applies to commons math. I'm interested in the possibility of a specification/api that can be used to define statistical/mathematical evaluations in java. A generic api that one could write an evaluation in which could be executed against any provider, similar in nature to JAXP or JNDI. -Mark If you're talking about creating a Service Provider Interface, I whole-heartedly agree. I envision we would follow the existing JAR service provider mechanism (http://java.sun.com/j2se/1.4.1/docs/guide/jar/jar.html#Service%20Provider) and use commons-discovery to enable it. The library, as it stands, wouldn't be too hard to morph into two separate JARs, one for the API and one for the default implementation. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21238] - ConvertUtilsBean should use defaultValue for all converters
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=21238. 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=21238 ConvertUtilsBean should use defaultValue for all converters [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-08-16 22:58 --- Unfortunately, this change would break backwards compatibility for all users that rely on the current default behavior. To work around this issue, you can reregister converters yourself that use the default values you prefer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] 1.2 vs 1.4 Was: [lang] Words - for 2.0
There are known problems with binaries built on JDK 1.4 being run on JDK 1.2. The primary issue is that a JDK 1.4 class may have a more specific signature than a JDK 1.2 method, so the JDK 1.4 compile will use the more specific signature, which isn't there on JDK 1.2. I compile the Apache James builds with JDK 1.3, and our javadocs with JDK 1.4. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20865] - newlines '\n' appearing in strings not converted
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=20865. 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=20865 newlines '\n' appearing in strings not converted [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-08-16 23:10 --- Digester is giving you back exactly what the XML parser is reading. Using \n is not the correct way to encode a newline character in XML; instead, you should be using the #xA escape, or a literal newline character. See the XML Specification for more information. In addition, I personally think it's bad form to use newlines in an attribute value, because it will make the XML document very difficult to read. Text with embedded newlines should appear in the body of a nested element instead. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20249] - When using digester rules xml file, digester connot assign date, int or foalt setter fields type to a bean.
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=20249. 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=20249 When using digester rules xml file, digester connot assign date, int or foalt setter fields type to a bean. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID Summary|When using digester rules |When using digester rules |xml file, digester connot |xml file, digester connot |assign date, int or foalt |assign date, int or foalt |setter fields type to a |setter fields type to a |bean. |bean. --- Additional Comments From [EMAIL PROTECTED] 2003-08-16 23:23 --- When you use the call-method-rule as you are doing, Digester assumes that the parameter type expected by the method is a String. Therefore, to call a method that expects a different type, you have to indicate the expected type. For example, you should change your rule for setId to be like this: call-method-rule pattern=id methodname=setId paramcount=0 paramtypes=java.lang.Long.TYPE/ See the Javadocs for CallMethodRule for more information about parameter types. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] 1.2 vs 1.4 Was: [lang] Words - for 2.0
Stephen Colebourne wrote: Can we guarantee that the 1.4 built version is bytecode compatable with 1.2? Its not nice whichever way around you do it. How about build under 1.4, then use the jar to run the test cases against under 1.2? FWIW, I have done this both ways with current sources -- build w/ 1.4, run tests using 1.2 and vice versa. Both work for me. I also ran 1.4-compiled tests on 1.3 and that worked as well. I did this earlier today thinking that I might see performance differences, but I did not (i.e., the 1.2-compiled code seems to run as fast under 1.4 as the 1.4 compiled version. disclaimer This is based on just 2 runs with each config so is by no means scientific. Also, our unit tests are obviously not performance tests /disclaimer). Phil Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] On Sat, 16 Aug 2003, Stephen Colebourne wrote: +1 to RC3 BTW, is there a problem with building with 1.2.2 if our javadoc has been optimised for 1.4? The javadoc compiler has changed. Can the docs be built using 1.4 instead? Ack. So we want a 1.2 built jar and a 1.4 built javadoc? Maybe I should just go ahead and use 1.4 to distribute. While I could merge a 1.4 and 1.2 set of builds, it wouldn't be something the user could repeat with the -src jar. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging package.html
craigmcc2003/08/16 16:46:31
Modified:logging/src/java/org/apache/commons/logging package.html
Log:
Correct a usage example in the Package Description javadocs.
PR: Bugzilla #18889
Submitted By: Thai Ha (thaiha at psv.com.vn)
Revision ChangesPath
1.11 +1 -1
jakarta-commons/logging/src/java/org/apache/commons/logging/package.html
Index: package.html
===
RCS file:
/home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/package.html,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- package.html 1 May 2003 16:55:29 - 1.10
+++ package.html 16 Aug 2003 23:46:31 - 1.11
@@ -38,7 +38,7 @@
public class Foo {
-static Log log = LogFactory.getLog(this.class);
+static Log log = LogFactory.getLog(Foo.class);
public void foo() {
...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18889] - Wrong sample code in org/apache/commons/logging/package.html (using static and this.class)
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=18889. 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=18889 Wrong sample code in org/apache/commons/logging/package.html (using static and this.class) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-16 23:49 --- Fixed in nightly build 20030817. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] 1.2 vs 1.4 Was: [lang] Words - for 2.0
How about the -target 1.1 flag to the 1.4 compiler? Ant allows us to pass this, and apparantly 1.1 means JDK's 1.1-1.3. So we would javadoc with 1.4 and build with 1.4 for 1.1-1.3. No idea how much of a guarentee that is. Hen On Sat, 16 Aug 2003, Stephen Colebourne wrote: Can we guarantee that the 1.4 built version is bytecode compatable with 1.2? Its not nice whichever way around you do it. How about build under 1.4, then use the jar to run the test cases against under 1.2? Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] On Sat, 16 Aug 2003, Stephen Colebourne wrote: +1 to RC3 BTW, is there a problem with building with 1.2.2 if our javadoc has been optimised for 1.4? The javadoc compiler has changed. Can the docs be built using 1.4 instead? Ack. So we want a 1.2 built jar and a 1.4 built javadoc? Maybe I should just go ahead and use 1.4 to distribute. While I could merge a 1.4 and 1.2 set of builds, it wouldn't be something the user could repeat with the -src jar. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/test/org/apache/commons/validator EmailTest.java
rleland 2003/08/16 21:21:05
Modified:validator/src/test/org/apache/commons/validator
EmailTest.java
Log:
Bug 22124
Add tests so Email validation will fail.
These tests test for all special characters allowed in the users
part of the email. Both serverside java and javascript need to be fixed.
Revision ChangesPath
1.17 +73 -17
jakarta-commons/validator/src/test/org/apache/commons/validator/EmailTest.java
Index: EmailTest.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/test/org/apache/commons/validator/EmailTest.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- EmailTest.java12 Aug 2003 00:29:34 - 1.16
+++ EmailTest.java17 Aug 2003 04:21:05 - 1.17
@@ -7,7 +7,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 1999-2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2000-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -36,7 +36,7 @@
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
- *permission of the Apache Group.
+ *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
@@ -77,6 +77,7 @@
*
* @author David Winterfeldt
* @author David Graham
+ * @author Rob Leland
* @version $Revision$ $Date$
*/
public class EmailTest extends TestCase {
@@ -200,8 +201,12 @@
info.setValue([EMAIL PROTECTED]);
valueTest(info, true);
- info.setValue([EMAIL PROTECTED]);
- valueTest(info, true);
+ info.setValue([EMAIL PROTECTED]);
+ valueTest(info, false);
+ info.setValue([EMAIL PROTECTED]);
+ valueTest(info, false);
+ info.setValue([EMAIL PROTECTED]);
+ valueTest(info, true);
}
@@ -241,15 +246,66 @@
/**
* Tests the email validation with commas.
*/
- public void testEmailWithCommas() throws ValidatorException {
- ValueBean info = new ValueBean();
- info.setValue(joe,[EMAIL PROTECTED]);
- valueTest(info, false);
- info.setValue([EMAIL PROTECTED],che.org);
- valueTest(info, false);
- info.setValue([EMAIL PROTECTED],rg);
- valueTest(info, false);
- }
+
+public void testEmailWithCommas() throws ValidatorException {
+ ValueBean info = new ValueBean();
+ info.setValue([EMAIL PROTECTED],che.org);
+ valueTest(info, false);
+ info.setValue([EMAIL PROTECTED],rg);
+ valueTest(info, false);
+info.setValue([EMAIL PROTECTED],org);
+valueTest(info, false);
+
+}
+
+/**
+ * Write this test according to parts of RFC, as opposed to the type of
character
+ * that is being tested.
+ * According to RFC 1738 a user name can be composed of the following :
+ * *[alpha | digit | $ | - | _ | . | + | ! | * | ' | ( |
) | , | % hex hex | ; | ? | | = ]
+
+ * @throws ValidatorException
+ */
+public void testEmailUserName() throws ValidatorException {
+ ValueBean info = new ValueBean();
+ info.setValue([EMAIL PROTECTED]);
+ valueTest(info, true);
+info.setValue([EMAIL PROTECTED]);
+valueTest(info, true);
+info.setValue([EMAIL PROTECTED]);
+valueTest(info, true);
+info.setValue([EMAIL PROTECTED]);
+valueTest(info, true);
+info.setValue([EMAIL PROTECTED]);
+valueTest(info, true);
+info.setValue([EMAIL PROTECTED]);
+valueTest(info, true);
+info.setValue([EMAIL PROTECTED]);
+valueTest(info, true);
+info.setValue([EMAIL PROTECTED]);
+valueTest(info, true);
+info.setValue(joe'@apache.org);
+valueTest(info, true);
+info.setValue(joe(@apache.org);
+valueTest(info, true);
+info.setValue(joe)@apache.org);
+valueTest(info, true);
+info.setValue(joe,@apache.org);
+valueTest(info, true);
+info.setValue([EMAIL PROTECTED]);
+valueTest(info, true);
+info.setValue(joe;@apache.org);
+valueTest(info, true);
+info.setValue([EMAIL PROTECTED]);
+valueTest(info, true);
+info.setValue(joe@apache.org);
+valueTest(info, true);
+info.setValue([EMAIL PROTECTED]);
+valueTest(info, true);
+
+}
+
+
/**
* Utlity class to
cvs commit: jakarta-commons/validator project.xml
rleland 2003/08/16 21:26:03 Modified:validator project.xml Log: Add package so maven correctly modified package in jars MANAFEST file. Revision ChangesPath 1.13 +8 -4 jakarta-commons/validator/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/validator/project.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- project.xml 17 Aug 2003 02:29:45 - 1.12 +++ project.xml 17 Aug 2003 04:26:03 - 1.13 @@ -4,21 +4,25 @@ extend../project.xml/extend nameValidator/name idcommons-validator/id - currentVersion1.1.0/currentVersion + currentVersion1.1.0-dev/currentVersion inceptionYear2002/inceptionYear gumpRepositoryIdjakarta/gumpRepositoryId + packageorg.apache.commons.validator.*/package + shortDescriptionCommons Validator/shortDescription logo/images/logo.gif/logo description -Commons Validator component. +Commons Validator provides the building blocks for both client side validation +and server side data validation. It may be used standalone on with a framework like +Struts. /description urlhttp://jakarta.apache.org/commons/validator//url issueTrackingUrlhttp://nagoya.apache.org/bugzilla//issueTrackingUrl siteAddressjakarta.apache.org/siteAddress siteDirectory/www/jakarta.apache.org/commons/validator//siteDirectory - distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons/validator//distributionDirectory + distributionDirectoryhttp://jakarta.apache.org/site/binindex.cgi/distributionDirectory developers developer @@ -87,7 +91,7 @@ dependency idcommons-logging/id - version1.0.2/version + version1.0.3/version /dependency dependency - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
