cvs commit: jakarta-commons-sandbox/configuration project.properties
epugh 2003/06/06 23:23:32
Modified:configuration project.properties
Log:
Tweak how the documentation site is generated to include date and version.
Revision ChangesPath
1.6 +5 -0 jakarta-commons-sandbox/configuration/project.properties
Index: project.properties
===
RCS file: /home/cvs/jakarta-commons-sandbox/configuration/project.properties,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- project.properties28 Feb 2003 20:22:09 - 1.5
+++ project.properties7 Jun 2003 06:23:32 - 1.6
@@ -2,6 +2,11 @@
# P R O J E C T P R O P E R T I E S
# ---
+# display the date on the site
+maven.xdoc.date = left
+# Display the version the web site is documenting
+maven.xdoc.version = ${pom.currentVersion}
+
compile.debug = on
compile.optimize = off
compile.deprecation = off
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/configuration/xdocs overview.xml
epugh 2003/06/06 23:40:41 Modified:configuration/xdocs overview.xml Log: Enhanced documentation on using ConfigurationFactory. Revision ChangesPath 1.3 +69 -0 jakarta-commons-sandbox/configuration/xdocs/overview.xml Index: overview.xml === RCS file: /home/cvs/jakarta-commons-sandbox/configuration/xdocs/overview.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- overview.xml 2 Jun 2003 18:18:49 - 1.2 +++ overview.xml 7 Jun 2003 06:40:41 - 1.3 @@ -87,6 +87,75 @@ /p /subsection /section +section name=Configuration Details + p + Configuration is done by taking the configuration XML file and using included Digester rules, + parsing the individual configurations. Make sure to include the various dependencies required for + each type of configuration! If you have an XML file, you'll need dom4j.jar for instance! + /p + subsection name=Classic Properties File +source +![CDATA[ + properties className=org.apache.commons.configuration.PropertiesConfiguration fileName=conf/test.properties/ +]] +/source +p + This configuration file is very simple. You just need to specify the path to the property file. + /p + /subsection + subsection name=XML Properties File +source +![CDATA[ + dom4j className=org.apache.commons.configuration.DOM4JConfiguration fileName=conf/test.xml/ +]] +/source +p +The configuration is very similar to the classic properties file. However, the xml file must be in a specific +format. Currently there is no DTD. +/p +source +![CDATA[ +baseElement + elementvalue/element + element2 +subelement + subsubelementI'm complex!/subsubelement +/subelement + /element2 + test + short8/short + /test +/baseElement +]] +/source +p +In the above example, the root element is ignored. So to get the value 8, you would request from your +Configuration object the key test.short. The root element can be called anything. +/p + /subsection + subsection name=JNDI Properties File +source +![CDATA[ + jndi className=org.apache.commons.configuration.JNDIConfiguration prefix=java:comp/env/ +]] +/source +p +This configuration is very useful for setting environment specific settings like mail servers! The +prefix tells the ConfigurationFactory what the root will be to look up your configuration settings. To +enter a value under the key test.short you would add this to your web.xml. +/p +source +![CDATA[ +env-entry +env-entry-nametest/short/env-entry-name +env-entry-value80/env-entry-value +env-entry-typejava.lang.String/env-entry-type +/env-entry + +]] +/source + /subsection +/section /body /document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20570] New: - [math] t-distribution
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=20570. 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=20570 [math] t-distribution Summary: [math] t-distribution Product: Commons Version: 1.0 Alpha Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Sandbox AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Adds Student's t-distribution to the distribution framework. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20570] - [math] t-distribution
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=20570. 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=20570 [math] t-distribution --- Additional Comments From [EMAIL PROTECTED] 2003-06-07 07:00 --- Created an attachment (id=6686) patch file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] Please Update Site with New docs
Hi all, Not sure who does this, and I'm not sure if I have the permissions, but could some update the Configuration site? There have been quite a few changes to docs and I am going to call for a vote to promote Configuration out of sandbox, so I'd like to get the latest and greatest site docs up. Sincerely, Eric Pugh
DO NOT REPLY [Bug 20523] - Model FileUpload model to mimic javax.servlet.Request
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=20523. 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=20523 Model FileUpload model to mimic javax.servlet.Request --- Additional Comments From [EMAIL PROTECTED] 2003-06-07 08:16 --- Created an attachment (id=6687) Proposed changes to FileUploadBase.java - not 100% compatible with ServletRequest - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20523] - Model FileUpload model to mimic javax.servlet.Request
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=20523. 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=20523 Model FileUpload model to mimic javax.servlet.Request --- Additional Comments From [EMAIL PROTECTED] 2003-06-07 08:19 --- The patch submitted is not 100% compatible with ServletRequest. Exceptions: - getParameter(String name) returns an Object that needs to be cast to the appropriate type (either String or FileItem). - getParameterValues(String name) returns an Array of Objects that need to be cast to the appropriate type (either String or FileItem). - getParameterMap() returns a Map containing ArrayList's as values instead of Arrays - each element of each ArrayList containing either a String or a FileItem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20523] - Model FileUpload model to mimic javax.servlet.Request
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=20523. 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=20523 Model FileUpload model to mimic javax.servlet.Request --- Additional Comments From [EMAIL PROTECTED] 2003-06-07 09:13 --- Created an attachment (id=6688) More compatible patch with ServletRequest - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20523] - Model FileUpload model to mimic javax.servlet.Request
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=20523. 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=20523 Model FileUpload model to mimic javax.servlet.Request --- Additional Comments From [EMAIL PROTECTED] 2003-06-07 09:17 --- New patch is more compatible with ServletRequest: - getParameterMap() now returns a Map such that the values are Object[], rather than an ArrayList. Although still not 100% compatible with Servlet.getParameterMap() (that returns a String[]), it's closer - returning an array instead of an ArrayList. Another possibility is to not add FileItems to the Map - this would make the methods 100% compatible, but would prevent people from being able to retrieve FileItem's by getParameter(). A different solution to that MIGHT be to put something of interest in a String value for FileItems, rather than a FileItem (perhaps the locally stored filename, if it is on disk? Or maybe the result of getName()?) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP] Build Failure - commons-jxpath
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-06-07/commons-jxpath.html
Buildfile: build.xml
check_available:
init:
[echo] jxpath 20030607
[echo] junit.jar = /home/rubys/jakarta/dist/junit/junit.jar
[echo] jaxp.jaxp.jar =
/home/rubys/jakarta/xml-xerces2/java/build/xmlParserAPIs.jar
[echo] jaxp.xslt.jar =
/home/rubys/jakarta/xml-xalan/java/build/xalan-unbundled.jar
[echo] servlet.jar = ${servlet.jar}
[echo] commons-beanutils.jar = ${commons-beanutils.jar}
[echo] commons-collections.jar = ${commons-collections.jar}
[echo] commons-logging.jar = ${commons-logging.jar}
check.junit:
check.jaxp.jaxp:
check.jaxp.xslt:
check.servlet:
prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/jxpath/target
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/jxpath/target/classes
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/jxpath/target/conf
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/jxpath/target/tests
static:
[copy] Copying 1 file to /home/rubys/jakarta/jakarta-commons/jxpath/target/conf
[copy] Replacing: @name@ - jxpath
[copy] Replacing: @version@ - 20030607
compile:
[javac] Compiling 153 source files to
/home/rubys/jakarta/jakarta-commons/jxpath/target/classes
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNamespaceIterator.java:110:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] Element parent = element.getParent();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:511:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] return ((Element) node).getParent();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:514:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] return ((Text) node).getParent();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:517:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] return ((CDATA) node).getParent();
[javac]^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:520:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] return ((ProcessingInstruction) node).getParent();
[javac]^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:523:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] return ((Comment) node).getParent();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:667:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] Element parent = ((Element) node).getParent();
[javac]^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:692:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] parent = ((Text) node).getParent();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:695:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] parent = ((CDATA) node).getParent();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom/JDOMNodePointer.java:715:
incompatible types
[javac] found : org.jdom.Parent
[javac] required: org.jdom.Element
[javac] Element parent = ((ProcessingInstruction) node).getParent();
[javac
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/distribution TDistributionImpl.java TDistribution.java DistributionFactory.java DistributionFactoryImpl.java
mdiggory2003/06/07 06:57:54
Modified:math/src/test/org/apache/commons/math/stat/distribution
DistributionFactoryImplTest.java
math/src/java/org/apache/commons/math/stat/distribution
DistributionFactory.java
DistributionFactoryImpl.java
Added: math/src/java/org/apache/commons/math/special Beta.java
math/src/test/org/apache/commons/math/stat/distribution
TDistributionTest.java
math/src/java/org/apache/commons/math/stat/distribution
TDistributionImpl.java TDistribution.java
Log:
PR: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20570
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
1.1
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/special/Beta.java
Index: Beta.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
*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 Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/
package org.apache.commons.math.special;
/**
* This is a utility class that provides computation methods related to the
* Gamma family of functions.
*
* @author Brent Worden
*/
public class Beta {
/** Maximum allowed numerical error. */
private static final double DEFAULT_EPSILON = 10e-9;
/**
* Default constructor. Prohibit instantiation.
*/
private Beta() {
super();
}
/**
* p
* Returns the regularized beta function I(x, a, b).
* /p
*
* @param x ???
* @param a ???
* @param b ???
* @return the regularized beta function I(x, a, b)
*/
public static double regularizedBeta(double x, double a, double b) {
return regularizedBeta(x, a, b, DEFAULT_EPSILON, Integer.MAX_VALUE);
}
/**
* p
* Returns the regularized beta function I(x, a, b).
* /p
*
* @param x ???
* @param a ???
* @param b ???
* @return the regularized beta function I(x, a, b)
*/
public static double regularizedBeta(double x, double a, double b, double
epsilon) {
return regularizedBeta(x, a, b, epsilon, Integer.MAX_VALUE);
DO NOT REPLY [Bug 20570] - [math] t-distribution
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=20570. 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=20570 [math] t-distribution --- Additional Comments From [EMAIL PROTECTED] 2003-06-07 14:02 --- patched and unit tested, looks good. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20570] - [math] t-distribution
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=20570. 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=20570 [math] t-distribution [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20579] New: - org.apache.commons.validator.GenericValidator.isEmail validator fails for address toto@web.de./de
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=20579. 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=20579 org.apache.commons.validator.GenericValidator.isEmail validator fails for address [EMAIL PROTECTED]/de Summary: org.apache.commons.validator.GenericValidator.isEmail validator fails for address [EMAIL PROTECTED]/de Product: Commons Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Validator AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] [EMAIL PROTECTED]/de should not be accepted as a valid email address but the validator returns true (I guess it comes from the / that is the regexp delim) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections][lang] submission: NotifyingCollections (observable) / o.a.c.l.event
From: Neil O'Toole [EMAIL PROTECTED] - Decorators for Collection, List, and Set (NotifyingCollection, NotifyingList, NotifyingSet). I would like our end solution to cover the Bag, SortedSet and SortedBag interfaces too. - Two types of notification: post-modification (or 'historical') notification, and pre-modification (or 'vetoable') notification. Pre-modification events can be vetoed before the actual modification occurs (similar to the bean VetoableChangeListener). My first reaction was that this was covered by Predicated collections that validate the object being added, but this gives more details. - Pluggable events: NotifyingCollections uses a pluggable event factory, ... A default event package is provided, in the org.apache.commons.collections.notifying.detailed package. This detailed event package is a quite heavyweight event system that provides detailed information on modifications to the collection. We should supply a simple implementation too. I think that this has the basis to be a good implementation. Some comments: 1) I dislike that a new instance of the event factory has to be created for each collection. The factory should be capable of being shared. This can be done by passing the init() parameters to each of the other methods. 2) The event dispatch sometimes assumes too much. For example the List addAll() method validates the index as being in range, but the LazyList implementation expects out of range indices. The modCount in the iterators could face the same problem. 3) Similar to (2), the boolean result flag cannot be relied on to give accurate results as to whether the collection has changed. 4) What if I want vetos to have no effect, rather than throw an exception. 5) It is quite hard to get info out about events. Typecasting is always needed. 6) There are a lot of classes to get your head around - its very OO. (2) - (5) give me pause to think about an alternative design... See separate thread. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] Notifying/Observable design choices
Three possible designs (so far):
Proposal #1 (Heuer/MailingList)
public boolean addAll(int index, Collection coll) {
int oldSize = backingList.size();
boolean returnVal = backingList.addAll(index, coll);
int newSize = backingList.size();
if (returnVal) {
CollectionChangeEvent e = new
CollectionChangeEvent(this,oldSize,newSize,index,coll.size(),null,coll,true)
;
support.fireElementsAdded(e);
}
return returnVal;
}
- One Event class.
- Event data chosen by us (so less flexible).
- Should handle all collections, but iterators will not be fail-fast.
- Should give reasonable performance.
- Relies on accurate result boolean.
- Relatively few classes
Proposal #2 (O'Toole):
-
public boolean addAll(int index, Collection c){
this.throwIfIndexOutOfBoundsExclusive(index);
ModifyingCollectionEvent event =
this.listEventFactory.createAddAllEvent(index, c);
this.doFireVetoableEvent(event); // can throw a
CollectionModificationVetoedException
boolean result = backingList.addAll(index, c);
if (result){
this.incrementModCount();
this.doFirePostModificationEvent(event);
}
return result;
}
- Event implementation class chosen by factory.
- Event data is theoretically flexible, but limited in practice. In
particular, the post-event cannot contain a copy of the state of the
collection, or the size before the change occurred (ie. you can't replicate
proposal #1)
- Unsuited to certain collections (eg. LazyList)
- Should give reasonable performance.
- Relies on accurate result boolean.
- Exception thrown from vetoed pre-events.
- Quite a lot of classes and concepts
Propsal #3 (Colebourne - merged from #1 and #2):
--
public boolean addAll(int index, Collection c){
if (preAddAll(index, c)) {
result = backingList.addAll(index, c);
postAddAll(index, c, result);
}
return result;
}
- Event implementation class chosen by subclass.
- Event data can be chosen by subclass.
- Should handle all collections, but iterators will not be fail-fast
(although subclass could include coding for that...).
- Will perform as per how you write the subclass. (Faster or slower)
- Subclass can choose whether to believe boolean result.
- Subclass can choose whether to use Listener pattern, or something else
(eg. call a static method)
- Choice of exception or ignore for vetoed pre-events.
- Relatively few classes, but subclasses may get have more classes
#3 explanation:
The class gets changed into an abstract one, with a real implementation or
two supplied in [collections]. Thus, AbstractNotifyingList would have the
method above, with NotifyingList as a subclass, managing event creation and
dispatch (using convenience methods from the abstract class.
Any comments, views or opinions on the three designs???
I guess I believe that #3 is the best compromise between #1 and #2 I can
think of (both #1 and #2 can be built using #3).
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20523] - Model FileUpload model to mimic javax.servlet.Request
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=20523. 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=20523 Model FileUpload model to mimic javax.servlet.Request --- Additional Comments From [EMAIL PROTECTED] 2003-06-07 17:35 --- Created an attachment (id=6692) Separated access for FileItems from Parameters - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20523] - Model FileUpload model to mimic javax.servlet.Request
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=20523. 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=20523 Model FileUpload model to mimic javax.servlet.Request --- Additional Comments From [EMAIL PROTECTED] 2003-06-07 17:39 --- Attachment 6692: Third option for modeling ServletRequest. Rather than getParemeter et al returning FileItems as well, separated access to FileItems by using equivalent getFileItem(name), getFileItems(name), getFileItemNames(), getFileItemMap() methods. Using this model, the data types returned by getParameter(name), etc., are 100% compatible with ServletRequest. Using this is now ALMOST a drop-in replacement for ServletRequest. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/configuration/xdocs tasks.xml
henning 2003/06/07 10:57:17 Modified:configuration/xdocs tasks.xml Log: Adding some todo items to the task list Revision ChangesPath 1.2 +17 -1 jakarta-commons-sandbox/configuration/xdocs/tasks.xml Index: tasks.xml === RCS file: /home/cvs/jakarta-commons-sandbox/configuration/xdocs/tasks.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- tasks.xml 2 Jun 2003 18:01:01 - 1.1 +++ tasks.xml 7 Jun 2003 17:57:17 - 1.2 @@ -14,7 +14,23 @@ /p subsection name=High priority - + ul +liUsing XML based digester rules will probably blow this bugger +apart. You do need a factory from an inner class of the +Configuration factory to get the base Path right; even if +the test with the rule configuration file works, I'm pretty +sure that the resulting rule set will not read configuration +files if you're not running from the current (.) directory +as base path. This needs more thinking and checking./li + +liI'm also 99% sure that using XML based Digester rules and +Namespace awareness in the configuration file can't be used +together. As far as I can see, the namespace awareness must +be set/reset before the rules are added. In the case of the +DigestLoader (using a DigesterRules() URI), the rules are +already added when configureNamespace() is called on the +digester. This might even be a bug in the Digester itself. + /li /subsection subsection name=Medium priority - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/configuration/src/test/org/apache/commons/configuration TestConfigurationFactory.java
henning 2003/06/07 10:57:29
Modified:configuration project.xml
configuration/src/java/org/apache/commons/configuration
ConfigurationFactory.java
CompositeConfiguration.java
configuration/src/test/org/apache/commons/configuration
TestConfigurationFactory.java
Log:
While hunting for some obscure Turbine configuration load bug, I
stumbled across the ConfigurationFactory... poor thingie.
- added lots of javadocs
- cleaned up the init logics (Eric you can trust void xxx(Foo foo) to
really keep the same object in foo. ;-) )
- clean up the digester setup, replaced the non-working setBasePath
with a factory creation which sets the BasePath right even before
the configuration file itself is loaded
- add two tiny inner classes to allow setting of the base path from
the factory itself
- make sure that getBasePath never returns null
- replaced class names in strings by class.getName() so that typos
are caught at compile time.
I'm 99% sure that setting the RuleNamespace will blow this bugger
apart. You do need a factory from an inner class of the Configuration
factory to get the base Path right; even if the test with the rule
configuration file works, I'm pretty sure that the resulting rule set
will not read configuration files if you're not running from the
current (.) directory as base path.
I'm also 99% sure that the RuleNamespace and Namespace awareness in the
configuration file can't be used together. As far as I can see, the
namespace awareness must be set/reset before the rules are added. In
the case of the DigestLoader (using a DigesterRules() URI), the rules
are already added when configureNamespace() is called on the digester.
I added the last two point to the tasks list in the docs.
Revision ChangesPath
1.26 +2 -2 jakarta-commons-sandbox/configuration/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/configuration/project.xml,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- project.xml 3 Jun 2003 14:15:23 - 1.25
+++ project.xml 7 Jun 2003 17:57:28 - 1.26
@@ -10,7 +10,7 @@
pomVersion3/pomVersion
namecommons-configuration/name
idcommons-configuration/id
- currentVersion1.0-dev-3.20030603.101200/currentVersion
+ currentVersion1.0-dev-3.20030607.194155/currentVersion
organization
nameApache Software Foundation/name
urlhttp://jakarta.apache.org//url
1.4 +175 -47
jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/ConfigurationFactory.java
Index: ConfigurationFactory.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/ConfigurationFactory.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ConfigurationFactory.java 24 Mar 2003 07:23:47 - 1.3
+++ ConfigurationFactory.java 7 Jun 2003 17:57:29 - 1.4
@@ -59,11 +59,18 @@
import java.io.InputStream;
import java.net.URL;
+import org.apache.commons.digester.AbstractObjectCreationFactory;
+import org.apache.commons.digester.ObjectCreationFactory;
import org.apache.commons.digester.Digester;
import org.apache.commons.digester.ObjectParamRule;
import org.apache.commons.digester.xmlrules.DigesterLoader;
+
+import org.apache.commons.lang.StringUtils;
+
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
+
+import org.xml.sax.Attributes;
import org.xml.sax.SAXException;
/**
@@ -73,8 +80,8 @@
* digester rules to use. It is also namespace aware, by providing a
* digesterRuleNamespaceURI.
*
-
* @author a href=mailto:[EMAIL PROTECTED]Eric Pugh/a
+ * @author a href=mailto:[EMAIL PROTECTED]Henning P. Schmiedehausen/a
* @version $Id$
*/
public class ConfigurationFactory
@@ -94,30 +101,57 @@
/** The digester namespace to parse */
private String digesterRuleNamespaceURI;
+/**
+ * C'tor
+ */
public ConfigurationFactory()
-{}
+{
+}
+
+/**
+ * C'tor with ConfigurationFile Name passed
+ *
+ * @param configurationFileName The path to the configuration file
+ */
+public ConfigurationFactory(String configurationFileName)
+{
+this.configurationFileName = configurationFileName;
+}
+/**
+ * Return the configuration provided by this factory. It
+ * loads the configuration file which is a XML description of
+ * the actual configurations to load. It can contain various
+ *
cvs commit: jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration BasePathConfiguration.java BaseConfiguration.java BasePropertiesConfiguration.java ConfigurationFactory.java DOM4JConfiguration.java PropertiesConfiguration.java XMLConfiguration.java
henning 2003/06/07 11:24:00
Modified:configuration/src/java/org/apache/commons/configuration
BaseConfiguration.java
BasePropertiesConfiguration.java
ConfigurationFactory.java DOM4JConfiguration.java
PropertiesConfiguration.java XMLConfiguration.java
Added: configuration/src/java/org/apache/commons/configuration
BasePathConfiguration.java
Log:
Add a layer class which adds the setBasePath/getBasePath method to all
of the file based methods. This simplifies the ConfigurationFactory to
have only one inner class for all path based configuration objects.
Revision ChangesPath
1.12 +3 -2
jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/BaseConfiguration.java
Index: BaseConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/BaseConfiguration.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- BaseConfiguration.java18 Mar 2003 21:41:56 - 1.11
+++ BaseConfiguration.java7 Jun 2003 18:24:00 - 1.12
@@ -113,7 +113,8 @@
* Empty constructor. You must add all the values to this configuration.
*/
public BaseConfiguration()
-{}
+{
+}
/**
* Add a property to the configuration. If it already exists then the value
1.6 +2 -2
jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/BasePropertiesConfiguration.java
Index: BasePropertiesConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/BasePropertiesConfiguration.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- BasePropertiesConfiguration.java 7 Feb 2003 00:21:50 - 1.5
+++ BasePropertiesConfiguration.java 7 Jun 2003 18:24:00 - 1.6
@@ -159,7 +159,7 @@
* @version $Id$
*/
public abstract class BasePropertiesConfiguration
-extends BaseConfiguration
+extends BasePathConfiguration
{
/** Allow file inclusion or not */
private boolean includesAllowed = false;
1.5 +17 -38
jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/ConfigurationFactory.java
Index: ConfigurationFactory.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/ConfigurationFactory.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ConfigurationFactory.java 7 Jun 2003 17:57:29 - 1.4
+++ ConfigurationFactory.java 7 Jun 2003 18:24:00 - 1.5
@@ -213,8 +213,8 @@
protected void initDefaultDigesterRules(Digester digester)
{
// Properties and DOM4J need a base path. Supply it with inner classes
-setupDigesterInstance(digester, configuration/properties, new
PropertiesConfigurationFactory());
-setupDigesterInstance(digester, configuration/dom4j, new
DOM4JConfigurationFactory());
+setupDigesterInstance(digester, configuration/properties, new
BasePathConfigurationFactory(PropertiesConfiguration.class));
+setupDigesterInstance(digester, configuration/dom4j, new
BasePathConfigurationFactory(DOM4JConfiguration.class));
// JNDI can be instantiated directly.
setupDigesterInstance(digester, configuration/jndi,
JNDIConfiguration.class);
@@ -318,61 +318,40 @@
/**
* A tiny inner class that allows the Configuration Factory to
- * let the digester construct PropertiesConfiguration objects
+ * let the digester construct BasePathConfiguration objects
* that already have the correct base Path set.
*
*/
-public class PropertiesConfigurationFactory
+public class BasePathConfigurationFactory
extends AbstractObjectCreationFactory
implements ObjectCreationFactory
{
+/** Actual class to use. */
+private Class clazz;
+
/**
* C'tor
- */
-public PropertiesConfigurationFactory()
-{
-}
-
-/**
- * Gets called by the digester. We ignore the attributes
*
- * @param attributes ignored
- */
-public Object createObject(Attributes attributes)
-{
-PropertiesConfiguration pc = new PropertiesConfiguration();
-pc.setBasePath(getBasePath());
-return pc;
-}
-
Re: [math] Complex dilemmas
--- Phil Steitz [EMAIL PROTECTED] wrote: Al Chou wrote: One question that comes to mind is: What problems does having complex mathematics solve? Basically I am wondering whether we should consider how or even if real-world users would employ these facilities before going through the exercise of getting them right. This is a very good question and one that we should *always* ask. I have to confess that I have used my implementation only for mathematical applications. I know that there are direct engineering applications, but I frankly do not know how common they are in the real world. It is also troubling that the VNI implementation started out as the reference implementation for a JSR that never went anywhere and it is clear from this: http://java.sun.com/people/darcy/complex-proposal.html#general which dates back to dec 2000, that Sun has looked carefully at providing direct support in the language, but concluded that it is not worth the effort. Given that it will be a fair amount of work to get a numerically sound C9x compliant implementation together (what I have now does not implement the transcendental functions at all and does not comply fully with C9x), I propose that we drop this from our goals for initial release. If people really want direct support for complex numbers, we can bring them in to a subsequent release. I think removing complex mathematics from the scope of the initial release is the right thing to do. Including it will delay the release, and unless we find we have mathematical/scientific/engineering users out there who really need it, I don't think most of our audience would even notice if we included it. Al = Albert Davidson Chou Get answers to Mac questions at http://www.Mac-Mgrs.org/ . __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator CreditCardValidator.java
dgraham 2003/06/07 11:31:18
Modified:validator/src/share/org/apache/commons/validator
CreditCardValidator.java
Log:
Refactored prefix checking into card specific methods.
Revision ChangesPath
1.5 +73 -47
jakarta-commons/validator/src/share/org/apache/commons/validator/CreditCardValidator.java
Index: CreditCardValidator.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/CreditCardValidator.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- CreditCardValidator.java 1 May 2003 02:15:16 - 1.4
+++ CreditCardValidator.java 7 Jun 2003 18:31:18 - 1.5
@@ -77,10 +77,10 @@
*/
public class CreditCardValidator {
- private static final String AX_PREFIX = 34,37,;
- private static final String VS_PREFIX = 4;
- private static final String MC_PREFIX = 51,52,53,54,55,;
- private static final String DS_PREFIX = 6011;
+ private static final String AMEX_PREFIX = 34,37,;
+ private static final String VISA_PREFIX = 4;
+ private static final String MASTERCARD_PREFIX = 51,52,53,54,55,;
+ private static final String DISCOVER_PREFIX = 6011;
/**
* Singleton instance of this class.
@@ -104,13 +104,26 @@
/**
* Checks if the field is a valid credit card number.
- *
- * @param value The value validation is being performed on.
+ * @param card The card number to validate.
*/
- public boolean isValid(String value) {
- return (
- this.validateCreditCardLuhnCheck(value)
- this.validateCreditCardPrefixCheck(value));
+ public boolean isValid(String card) {
+ if (card.length() 13) {
+ return false;
+ }
+
+ if (!this.luhnCheck(card)) {
+ return false;
+ }
+
+ if (this.isVisa(card)
+ || this.isAmex(card)
+ || this.isMastercard(card)
+ || this.isDiscover(card)) {
+
+ return true;
+ }
+
+ return false;
}
/**
@@ -118,7 +131,7 @@
*
* @param cardNumber Credit Card Number.
*/
- protected boolean validateCreditCardLuhnCheck(String cardNumber) {
+ protected boolean luhnCheck(String cardNumber) {
// number must be validated as 0..9 numeric first!!
int digits = cardNumber.length();
int oddoeven = digits 1;
@@ -131,6 +144,7 @@
} catch (NumberFormatException e) {
return false;
}
+
if (((count 1) ^ oddoeven) == 0) { // not
digit *= 2;
if (digit 9) {
@@ -139,6 +153,7 @@
}
sum += digit;
}
+
if (sum == 0) {
return false;
}
@@ -152,47 +167,58 @@
/**
* Checks for a valid credit card number.
- *
- * @param cardNumber Credit Card Number.
+ * @param card Credit Card Number.
+ * @deprecated This will be removed in a future release.
*/
- protected boolean validateCreditCardPrefixCheck(String cardNumber) {
+ protected boolean isValidPrefix(String card) {
- int length = cardNumber.length();
- if (length 13) {
+ if (card.length() 13) {
return false;
}
- int cardType = 0;
+ return (
+ this.isVisa(card)
+ || this.isAmex(card)
+ || this.isMastercard(card)
+ || this.isDiscover(card));
+ }
- final String prefix2 = cardNumber.substring(0, 2) + ,;
+ /**
+ * Returns true if the card is American Express.
+ */
+ private boolean isAmex(String card) {
+ String prefix2 = card.substring(0, 2) + ,;
- if (AX_PREFIX.indexOf(prefix2) != -1) {
- cardType = 3;
- }
- if (cardNumber.substring(0, 1).equals(VS_PREFIX)) {
- cardType = 4;
- }
- if (MC_PREFIX.indexOf(prefix2) != -1) {
- cardType = 5;
- }
- if (cardNumber.substring(0, 4).equals(DS_PREFIX)) {
- cardType = 6;
- }
+ return ((AMEX_PREFIX.indexOf(prefix2) != -1) (card.length() ==
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator CreditCardValidator.java GenericValidator.java
dgraham 2003/06/07 12:13:21
Modified:validator/src/share/org/apache/commons/validator
CreditCardValidator.java GenericValidator.java
Log:
Added validation options to CreditCardValidator to allow only
certain card types to pass validation. This required
CreditCardValidator to not be a Singleton.
Currently the options are passed into the constructor (like UrlValidator) but we may
need to consider passing the options into the isValid() method
so that one CreditCardValidator instance can be used to
validate with different options.
This still needs a unit test.
PR# 20557
Revision ChangesPath
1.6 +62 -20
jakarta-commons/validator/src/share/org/apache/commons/validator/CreditCardValidator.java
Index: CreditCardValidator.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/CreditCardValidator.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- CreditCardValidator.java 7 Jun 2003 18:31:18 - 1.5
+++ CreditCardValidator.java 7 Jun 2003 19:13:21 - 1.6
@@ -61,13 +61,18 @@
package org.apache.commons.validator;
+import org.apache.commons.validator.util.Flags;
+
/**
* pPerform credit card validations./p
* p
- * This class is a Singleton; you can retrieve the instance via the getInstance()
method.
+ * By default, all supported card types are allowed. You can specify which cards
+ * should pass validation by configuring the validation options. For example,br/
+ * codeCreditCardValidator ccv = new CreditCardValidator(CreditCardValidator.AMEX
+ CreditCardValidator.VISA);/code
+ * configures the validator to only pass American Express and Visa cards.
* /p
- * Reference Sean M. Burke's script at
- * http://www.ling.nwu.edu/~sburke/pub/luhn_lib.pl
+ * Reference Sean M. Burke's
+ * a href=http://www.ling.nwu.edu/~sburke/pub/luhn_lib.pl;script/a.
*
* @author David Winterfeldt
* @author James Turner
@@ -83,23 +88,52 @@
private static final String DISCOVER_PREFIX = 6011;
/**
- * Singleton instance of this class.
+ * Option specifying that American Express cards are allowed.
+ */
+ public static final int AMEX = 1;
+
+ /**
+ * Option specifying that Visa cards are allowed.
+ */
+ public static final int VISA = 2;
+
+ /**
+ * Option specifying that Mastercard cards are allowed.
+ */
+ public static final int MASTERCARD = 4;
+
+ /**
+ * Option specifying that Discover cards are allowed.
+ */
+ public static final int DISCOVER = 8;
+
+ /**
+ * The default validation options allow all supported card types.
+ */
+ private static final Flags defaultOptions =
+ new Flags(AMEX + VISA + MASTERCARD + DISCOVER);
+
+ /**
+ * The current set of validation options.
*/
- private static final CreditCardValidator instance =
- new CreditCardValidator();
+ private Flags options = null;
/**
- * Returns the Singleton instance of this validator.
+ * Create a new CreditCardValidator with default options.
*/
- public static CreditCardValidator getInstance() {
- return instance;
+ public CreditCardValidator() {
+ super();
+ this.options = defaultOptions;
}
/**
- * Protected constructor for subclasses to use.
+ * Create a new CreditCardValidator with the specified options. Pass in
+ * CreditCardValidator.VISA + CreditCardValidator.AMEX to specify that those
are the
+ * only valid card types.
*/
- protected CreditCardValidator() {
+ public CreditCardValidator(int options) {
super();
+ this.options = new Flags(options);
}
/**
@@ -115,12 +149,20 @@
return false;
}
- if (this.isVisa(card)
- || this.isAmex(card)
- || this.isMastercard(card)
- || this.isDiscover(card)) {
+ if (this.isVisa(card)) {
+ return this.options.isOn(VISA);
+ }
+
+ if (this.isAmex(card)) {
+ return this.options.isOn(AMEX);
+ }
+
+ if (this.isMastercard(card)) {
+ return this.options.isOn(MASTERCARD);
+ }
- return true;
+ if (this.isDiscover(card)) {
+ return this.options.isOn(DISCOVER);
}
return false;
1.24 +17 -17
Re: [math] proposed ordering for task list, scope of initial release
--- Phil Steitz [EMAIL PROTECTED] wrote: [deletia] OK, long-winded disclaimer aside, here is how I see the task list ordered: * The RealMatrixImpl class is missing some key method implementations. The critical thing is solution of linear systems. We need to implement a numerically sound solution algorithm. This will enable inverse() and also support general linear regression. -- I think that Brent is working on this. * Improve numerical accuracy of Univariate and BivariateRegression statistical computations. Encapsulate basic double[] |- double mean, variance, min, max computations using improved formulas and add these to MathUtils. (probably should add float[], int[], long[] versions as well.) Then refactor all univariate implementations that use stored values (including UnivariateImpl with finite window) to use the improved versions. -- Mark? I am chasing down the TAS reference to document the source of the _NR_ formula, which I will add to the docs if someone else does the implementation. I was starting to code the updating (storage-less) variance formula, based on the Stanford article you cited, as a patch. I believe the storage-using corrected two-pass algorithm is pretty trivial to code once we feel we're on solid ground with the reference to cite. * Define full package structure and develop user's guide following the package structure. I have started work on the user's guide, but found this impossible without the package structure defined. I will post a separate message summarizing what has been proposed up to now and making a recommendation. * t-test statistic needs to be added and we should probably add the capability of actually performing t- and chi-square tests at fixed significance levels (.1, .05, .01, .001). -- This is virtually done, just need to define a nice, convenient interface for doing one- and two-tailed tests. Thanks to Brent, we can actually support user-supplied significance levels (next item) * numerical approximation of the t- and chi-square distributions to enable user-supplied significance levels. See above. Someone just needs to put a fork in this. Tim? Brent? * *new* add support for F distribution and F test, so that we can report signinficance level of correlation coefficient in bivariate regression / signinficance of model. I will do this if no one else wants to. * Framework and implementation strategie(s) for finding roots or real-valued functions of one (real) variable. Here again -- largely done. I would prefer to wait until J gets back and let him submit his framework and R. Brent's algorithm. Then our Brent's implementation and usage can be integrated (actually not much to do, from the looks of the current code) and I will add my bean equations stuff (in progress). I may have time to submit my Ridders' method implementation using J.'s framework before he returns 2 days hence. Should I bother to try, or should I wait until he submits his code as a patch via Bugzilla? * Extend distribution framework to support discrete distributions and implement binomial and hypergeometric distributions. I will do this if no one else wants to. If someone else does it, you should make sure to use the log binomials in computations. * Exponential growth and decay (set up for financial applications) I think this is just going to be a matter of finding the right formulas to add to MathUtils. I don't want to get carried away with financial computations, but some simple, commonly used formulas would be a nice addition to the package. We should also be thinking about other things to add to MathUtils -- religiously adhering to th guiding principles, of course. Al's sign() is an excellent example of the kind of thing that we should be adding, IMHO. Thanks for the compliment! I think I finally understand what you mean with the exponential stuff: compount interest calculation, for the most part, with continuous compounding requiring the exponential. * Polynomial Interpolation -- let Al tell us what to do here. Even better, let Al do it (he he). I actually did some research last night (I told myself I was going to bed early, hah) on rational function interpolation, trying to find a primary source for the algorithm rather than again rely on a secondary source in the form of NR. I guess I'll continue along this path, as I really want a clean room implementation of it for my own use. I'd feel better using rational functions rather than polynomials for their generally larger radius of convergence. Al = Albert Davidson Chou Get answers to Mac questions at http://www.Mac-Mgrs.org/ . __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
DO NOT REPLY [Bug 20557] - Improved CreditCard validation and minor refactoring
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=20557. 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=20557 Improved CreditCard validation and minor refactoring [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|commons-|struts- |[EMAIL PROTECTED] |[EMAIL PROTECTED] Component|Validator |Validator Framework Product|Commons |Struts Version|unspecified |1.1 RC1 --- Additional Comments From [EMAIL PROTECTED] 2003-06-07 19:19 --- I refactored CreditCardValidator and added validation options to specify valid card types. We still need a unit test for CreditCardValidator though. Moving to Struts to consider adding support for this new feature... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Notifying/Observable design choices
I haven't been involved in the discussion, but on first glance, I give
Proposal #3 a +1... since it seems to allow for flexibility in event
data, exception handling, and performance by creating subclasses.
On Sat, 2003-06-07 at 10:07, Stephen Colebourne wrote:
Three possible designs (so far):
Proposal #1 (Heuer/MailingList)
public boolean addAll(int index, Collection coll) {
int oldSize = backingList.size();
boolean returnVal = backingList.addAll(index, coll);
int newSize = backingList.size();
if (returnVal) {
CollectionChangeEvent e = new
CollectionChangeEvent(this,oldSize,newSize,index,coll.size(),null,coll,true)
;
support.fireElementsAdded(e);
}
return returnVal;
}
- One Event class.
- Event data chosen by us (so less flexible).
- Should handle all collections, but iterators will not be fail-fast.
- Should give reasonable performance.
- Relies on accurate result boolean.
- Relatively few classes
Proposal #2 (O'Toole):
-
public boolean addAll(int index, Collection c){
this.throwIfIndexOutOfBoundsExclusive(index);
ModifyingCollectionEvent event =
this.listEventFactory.createAddAllEvent(index, c);
this.doFireVetoableEvent(event); // can throw a
CollectionModificationVetoedException
boolean result = backingList.addAll(index, c);
if (result){
this.incrementModCount();
this.doFirePostModificationEvent(event);
}
return result;
}
- Event implementation class chosen by factory.
- Event data is theoretically flexible, but limited in practice. In
particular, the post-event cannot contain a copy of the state of the
collection, or the size before the change occurred (ie. you can't replicate
proposal #1)
- Unsuited to certain collections (eg. LazyList)
- Should give reasonable performance.
- Relies on accurate result boolean.
- Exception thrown from vetoed pre-events.
- Quite a lot of classes and concepts
Propsal #3 (Colebourne - merged from #1 and #2):
--
public boolean addAll(int index, Collection c){
if (preAddAll(index, c)) {
result = backingList.addAll(index, c);
postAddAll(index, c, result);
}
return result;
}
- Event implementation class chosen by subclass.
- Event data can be chosen by subclass.
- Should handle all collections, but iterators will not be fail-fast
(although subclass could include coding for that...).
- Will perform as per how you write the subclass. (Faster or slower)
- Subclass can choose whether to believe boolean result.
- Subclass can choose whether to use Listener pattern, or something else
(eg. call a static method)
- Choice of exception or ignore for vetoed pre-events.
- Relatively few classes, but subclasses may get have more classes
#3 explanation:
The class gets changed into an abstract one, with a real implementation or
two supplied in [collections]. Thus, AbstractNotifyingList would have the
method above, with NotifyingList as a subclass, managing event creation and
dispatch (using convenience methods from the abstract class.
Any comments, views or opinions on the three designs???
I guess I believe that #3 is the best compromise between #1 and #2 I can
think of (both #1 and #2 can be built using #3).
Stephen
-
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/share/org/apache/commons/validator Field.java
dgraham 2003/06/07 12:25:59 Modified:validator/src/share/org/apache/commons/validator Field.java Log: Somewhere along the way hArg0 was moved to private instead of protected, so move it back. Revision ChangesPath 1.16 +5 -6 jakarta-commons/validator/src/share/org/apache/commons/validator/Field.java Index: Field.java === RCS file: /home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/Field.java,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- Field.java29 May 2003 03:04:33 - 1.15 +++ Field.java7 Jun 2003 19:25:58 - 1.16 @@ -149,7 +149,7 @@ /** * @deprecated This variable is no longer used, use args instead. */ -private FastHashMap hArg0 = new FastHashMap(); +protected FastHashMap hArg0 = new FastHashMap(); /** * @deprecated This variable is no longer used, use args instead. @@ -165,7 +165,6 @@ * @deprecated This variable is no longer used, use args instead. */ protected FastHashMap hArg3 = new FastHashMap(); - /** * Gets the page value that the Field is associated with for - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/configuration/xdocs tasks.xml
henning 2003/06/07 12:30:44
Modified:configuration/src/java/org/apache/commons/configuration
BasePathConfiguration.java
BasePropertiesConfiguration.java
ClassPropertiesConfiguration.java
CompositeConfiguration.java
ConfigurationFactory.java ConfigurationUtils.java
DOM4JConfiguration.java JNDIConfiguration.java
configuration/src/test-cactus/org/apache/commons/configuration
TestJNDIAndCompositeConfiguration.java
configuration/xdocs tasks.xml
Log:
Style fixes.
Revision ChangesPath
1.2 +7 -5
jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/BasePathConfiguration.java
Index: BasePathConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/BasePathConfiguration.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- BasePathConfiguration.java7 Jun 2003 18:24:00 - 1.1
+++ BasePathConfiguration.java7 Jun 2003 19:30:43 - 1.2
@@ -70,11 +70,12 @@
* synthetic PropertyConfiguration has been created which
* is not loaded from a file
*/
-protected String basePath = null;
+private String basePath = null;
/**
* Returns the Base path from which this Configuration Factory operates.
- * This is never null. If you set the BasePath to null, then . is returned.
+ * This is never null. If you set the BasePath to null, then .
+ * is returned.
*
* @return The base Path of this configuration factory.
*/
@@ -84,8 +85,9 @@
}
/**
- * Sets the basePath for all file references from this Configuration Factory.
- * If you pass null in, this is interpreted as current directory.
+ * Sets the basePath for all file references from this Configuration
+ * Factory. If you pass null in, this is interpreted as current
+ * directory.
*
* @param basePath The new basePath to set.
*/
1.7 +4 -4
jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/BasePropertiesConfiguration.java
Index: BasePropertiesConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/BasePropertiesConfiguration.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- BasePropertiesConfiguration.java 7 Jun 2003 18:24:00 - 1.6
+++ BasePropertiesConfiguration.java 7 Jun 2003 19:30:43 - 1.7
@@ -142,7 +142,7 @@
* # properties can reference other properties
* base.prop = /base
* first.prop = ${base.prop}/first
- * second.prop = ${first.prop}/second
+ * second.prop = ${first.prop}/second
* /pre
*
* @author a href=mailto:[EMAIL PROTECTED]Stefano Mazzocchi/a
@@ -279,7 +279,7 @@
out.writeComment(written by PropertiesConfiguration);
out.writeComment(new Date().toString());
-for (Iterator i = this.getKeys(); i.hasNext(); )
+for (Iterator i = this.getKeys(); i.hasNext();)
{
String key = (String) i.next();
String value = StringUtils.join(this.getStringArray(key), , );
@@ -316,7 +316,7 @@
* statement or not. Base rule is, that objects created by the empty
* C'tor can not have included files.
*
- * @param boolean includesAllowed True if Includes are allowed.
+ * @param includesAllowed includesAllowed True if Includes are allowed.
*/
protected void setIncludesAllowed(boolean includesAllowed)
{
1.3 +3 -3
jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/ClassPropertiesConfiguration.java
Index: ClassPropertiesConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/ClassPropertiesConfiguration.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ClassPropertiesConfiguration.java 7 Jan 2003 22:53:36 - 1.2
+++ ClassPropertiesConfiguration.java 7 Jun 2003 19:30:43 - 1.3
@@ -78,10 +78,10 @@
implements Configuration
{
/** Base class, which is used to load all relative class references */
-protected Class baseClass = null;
+private Class baseClass = null;
/** Class Loader which we will use to load the resources */
-protected
Re: [math] proposed ordering for task list, scope of initial release
Al Chou wrote: [deletia]**2 * Improve numerical accuracy of Univariate and BivariateRegression statistical computations. Encapsulate basic double[] |- double mean, variance, min, max computations using improved formulas and add these to MathUtils. (probably should add float[], int[], long[] versions as well.) Then refactor all univariate implementations that use stored values (including UnivariateImpl with finite window) to use the improved versions. -- Mark? I am chasing down the TAS reference to document the source of the _NR_ formula, which I will add to the docs if someone else does the implementation. I was starting to code the updating (storage-less) variance formula, based on the Stanford article you cited, as a patch. I believe the storage-using corrected two-pass algorithm is pretty trivial to code once we feel we're on solid ground with the reference to cite. Yes. I just wanted to propose the refactoring. * Framework and implementation strategie(s) for finding roots or real-valued functions of one (real) variable. Here again -- largely done. I would prefer to wait until J gets back and let him submit his framework and R. Brent's algorithm. Then our Brent's implementation and usage can be integrated (actually not much to do, from the looks of the current code) and I will add my bean equations stuff (in progress). I may have time to submit my Ridders' method implementation using J.'s framework before he returns 2 days hence. Should I bother to try, or should I wait until he submits his code as a patch via Bugzilla? I doubt that J would mind if someone else were to submit the framework (including his @author of course) from his post to the list. You could combine his classes and yours into one patch and submit it if you have time to do this before he gets back. * Polynomial Interpolation -- let Al tell us what to do here. Even better, let Al do it (he he). I actually did some research last night (I told myself I was going to bed early, hah) on rational function interpolation, trying to find a primary source for the algorithm rather than again rely on a secondary source in the form of NR. I guess I'll continue along this path, as I really want a clean room implementation of it for my own use. I'd feel better using rational functions rather than polynomials for their generally larger radius of convergence. Thanks for looking into this. If you think rational functions are better, go for it. One more thing to think about is splines. A natural spline implementation might be easier to document/understand from users' perspective. We might want to eventually support both (and maybe even polynomial interpolation). Phil Al = Albert Davidson Chou Get answers to Mac questions at http://www.Mac-Mgrs.org/ . __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - 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: [math] proposed ordering for task list, scope of initial release
* Improve numerical accuracy of Univariate and BivariateRegression statistical computations. Encapsulate basic double[] |- double mean, variance, min, max computations using improved formulas and add these to MathUtils. (probably should add float[], int[], long[] versions as well.) Then refactor all univariate implementations that use stored values (including UnivariateImpl with finite window) to use the improved versions. -- Mark? I am chasing down the TAS reference to document the source of the _NR_ formula, which I will add to the docs if someone else does the implementation. I was starting to code the updating (storage-less) variance formula, based on the Stanford article you cited, as a patch. I believe the storage-using corrected two-pass algorithm is pretty trivial to code once we feel we're on solid ground with the reference to cite. OK. I finally got hold of the American Statistician article (had to resort to the old trundle down to local university library method) and found lots of good stuff in it -- including a reference to Hanson's recursive formula (from Stanford paper) and some empirical and theoretical results confirming that NR 14.1.8 is about the best that you can do for the stored case. There is a refinement mentioned in which pairwise summation is used (essentially splitting the sample in two and computing the recursive sums in parallel); but the value of this only kicks in for large n. I propose that we use NR 14.1.8 as is for all stored computations. Here is good text for the reference: Based on the icorrected two-pass algorithm/i for computing the sample variance, as described in Algorithms for Computing the Sample Variance: Analysis and Recommendations,Tony F Chan, Gene H. Golub and Randall J. LeVeque, iThe American Statitistician/i, 1983, Vol 37, No. 3. (Eq. (1.7) on page 243.) The empirical investigation that the authors do uses the following trick that I have thought about using to investigate the precision in our stuff: implement an algorithm using both floats and doubles and use the double computations to assess stability of the algorithm implemented using floats. Might want to play with this a little. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator Field.java
dgraham 2003/06/07 22:29:27
Modified:validator/src/share/org/apache/commons/validator Field.java
Log:
Changed toString() method.
Revision ChangesPath
1.17 +26 -26
jakarta-commons/validator/src/share/org/apache/commons/validator/Field.java
Index: Field.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/Field.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- Field.java7 Jun 2003 19:25:58 - 1.16
+++ Field.java8 Jun 2003 05:29:27 - 1.17
@@ -720,29 +720,29 @@
* Returns a string representation of the object.
*/
public String toString() {
- StringBuffer results = new StringBuffer();
-
- results.append(\t\tkey= + key+ \n);
- results.append(\t\tproperty= + property+ \n);
- results.append(\t\tindexedProperty= + indexedProperty+ \n);
- results.append(\t\tindexedListProperty= + indexedListProperty+ \n);
- results.append(\t\tdepends= + depends+ \n);
- results.append(\t\tpage= + page+ \n);
- results.append(\t\tfieldOrder= + fieldOrder+ \n);
-
- if (hVars != null) {
- results.append(\t\tVars:\n);
- for (Iterator i = hVars.keySet().iterator(); i.hasNext(); ) {
- Object key = i.next();
- results.append(\t\t\t);
- results.append(key);
- results.append(=);
- results.append(hVars.get(key));
- results.append(\n);
-}
+ StringBuffer results = new StringBuffer();
+
+ results.append(\t\tkey = + key + \n);
+ results.append(\t\tproperty = + property + \n);
+ results.append(\t\tindexedProperty = + indexedProperty + \n);
+ results.append(\t\tindexedListProperty = + indexedListProperty + \n);
+ results.append(\t\tdepends = + depends + \n);
+ results.append(\t\tpage = + page + \n);
+ results.append(\t\tfieldOrder = + fieldOrder + \n);
+
+ if (hVars != null) {
+ results.append(\t\tVars:\n);
+ for (Iterator i = hVars.keySet().iterator(); i.hasNext();) {
+ Object key = i.next();
+ results.append(\t\t\t);
+ results.append(key);
+ results.append(=);
+ results.append(hVars.get(key));
+ results.append(\n);
+ }
}
-
- return results.toString();
+
+ return results.toString();
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
