Re: [math] Recent commits to stat, util packages
Phil Steitz wrote:
Sorry, last reply got sent before I was done with it. Pls disregard and try
this
This adds
significant overhead and I do not see the value in it. The cost of the
additional stack operations/object creations is significant. I ran tests
comparing the previous version that does direct computations using the
double[]
arrays to the modified version and found an average of more than 6x
slowdown
using the new implementation. I did not profile memory utilization, but
that is
also a concern. Repeated tests computing the mean of a 1000 doubles 10
times using the old and new implementations averaged 1.5 and 10.2 seconds,
resp. I do not see the need for all of this additional overhead.
If you review the code, you'll find there is no added object creation,
the static Variable objects calculate on double[] just as the
Univariates did, I would have to see more substantial analysis to
believe your claim. All thats going on here are that the Static StatUtil
methods are delegating to individual static instances of
UnivariateStatistics. These are instantiated on JVM startup like all
static objects, calling a method in such an object should not require
any more overhead than having the method coded directly into the static
method.
If there are performance considerations, lets discuss these.
Here is what I added to StatUtils.test
double[] x = new double[1000];
for (int i = 0; i 1000; i++) {
x[i] = (5 - i) * (i - 200);
}
long startTick = 0;
double res = 0;
for (int j = 0; j 10; j++) {
startTick = System.currentTimeMillis();
for (int i = 0; i 10; i++) {
res = OStatUtils.mean(x);
}
System.out.println(old: + (System.currentTimeMillis() - startTick));
startTick = System.currentTimeMillis();
for (int i = 0; i 10; i++) {
res = StatUtils.mean(x);
}
System.out.println(new: + (System.currentTimeMillis() - startTick));
The result was a mean of 10203 for the new and 1531.1 for the old, with
standard deviations 81.1 and 13.4 resp. The overhead is the stack operations
and temp object creations.
Ok, yes, You've got me on this one, I ran these tests and your correct,
the increment method approach (while great for storageless
implementation) does incur the added costs in calculation (specifically
in added divisions that are ocuring). It would have been better for me
to still provide the implementations provided for in the static StatUtil
lib for the double[] based methods.
*the direct evaluation approach here*
public double evaluate(double[] d, int start, int length) {
double accum = 0.0;
for (int i = start; i start + length; i++) {
accum += d[i];
}
return accum / (double) d.length;
}
*takes cycles to calculate than the below incremental approach*
int n = 0;
double m1 = Double.NaN;
public double evaluate(double[] d, int start, int length) {
for (int i = start; i start + length; i++) {
increment(d[i]);
}
return getValue();
}
public double increment(double d) {
if (n 1) {
m1 = 0.0;
}
n++;
m1 += (d - m1) / ((double) n);
return m1;
}
I will add the direct approaches into my implementations I have written
to regain this efficiency. I'll also roll back StatUtils so that it is
not dependent on these limitations in the mean-time.
I doubt (as the numerous discussions over the past week have pointed
out) that what we really want to have in StatUtils is one monolithic
Static class with all the implemented methods present in it. If I have
misinterpreted this opinion in the group, then I'm sure there will be
responses to this.
Well, I for one would prefer to have the simple computational methods in one
place. I would support making the class require instantiation, however, i.e.
making the methods non-static.
Yes, but again is a question of having big flat monolithic classes vs
having extensible implementations that can easily be expanded on. I'm
not particularly thrilled at the idea of being totally locked into such
an interface like Univariate or StatUtils. It is just totally inflexible
and there always too much restriction and argument about what do we want
to put in it vs, not put in it.
There was a great deal of discussion about the benefit of not having the
methods implemented directly in static StatUtils because they could not
be overridden or worked with in an Instantiable form. This approach
frees the implementations up to be overridden and frees up room for
alternate implementations.
As I said above, the simplest way to deal with this is to make the methods
non-static.
Yes, simple, but not very organized, and not as extensible as a
framework like solvers is. You can implement any new solver we could
desire right now without much complaint, but try to implement a new
statistic and blam, all this argument starts up as to whether its
appropriate or not in the Univariate interface. There's not room for
growth here! If I
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat StatUtils.java
mdiggory2003/07/06 00:18:08
Modified:math/src/java/org/apache/commons/math/stat StatUtils.java
Log:
Rolling Back StatUtils to previous version.
Revision ChangesPath
1.12 +172 -104
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/StatUtils.java
Index: StatUtils.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/StatUtils.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- StatUtils.java5 Jul 2003 18:29:35 - 1.11
+++ StatUtils.java6 Jul 2003 07:18:08 - 1.12
@@ -53,21 +53,6 @@
*/
package org.apache.commons.math.stat;
-import org.apache.commons.math.stat.univariate.UnivariateStatistic;
-import org.apache.commons.math.stat.univariate.moment.GeometricMean;
-import org.apache.commons.math.stat.univariate.moment.Kurtosis;
-import org.apache.commons.math.stat.univariate.moment.Mean;
-import org.apache.commons.math.stat.univariate.moment.Skewness;
-import org.apache.commons.math.stat.univariate.moment.Variance;
-import org.apache.commons.math.stat.univariate.rank.Max;
-import org.apache.commons.math.stat.univariate.rank.Median;
-import org.apache.commons.math.stat.univariate.rank.Min;
-import org.apache.commons.math.stat.univariate.rank.Percentile;
-import org.apache.commons.math.stat.univariate.summary.Product;
-import org.apache.commons.math.stat.univariate.summary.Sum;
-import org.apache.commons.math.stat.univariate.summary.SumOfLogs;
-import org.apache.commons.math.stat.univariate.summary.SumOfSquares;
-
/**
* StatUtils provides easy static implementations of common double[] based
* statistical methods. These return a single result value or in some cases, as
@@ -77,52 +62,13 @@
*/
public class StatUtils {
-/** Sum Of Logs */
-private static UnivariateStatistic sumLog = new SumOfLogs();
-
-/** Product */
-private static UnivariateStatistic product = new Product();
-
-/** Geometric Mean */
-private static UnivariateStatistic geoMean = new GeometricMean();
-
-/** Mean */
-private static UnivariateStatistic mean = new Mean();
-
-/** Variance */
-private static UnivariateStatistic var = new Variance();
-
-/** Skewness */
-private static UnivariateStatistic skew = new Skewness();
-
-/** Kurtosis */
-private static UnivariateStatistic kurt = new Kurtosis();
-
-/** Min Of Logs */
-private static UnivariateStatistic min = new Min();
-
-/** Max */
-private static UnivariateStatistic max = new Max();
-
-/** Median */
-private static UnivariateStatistic median = new Median();
-
-/** Sum */
-private static UnivariateStatistic sum = new Sum();
-
-/** Sum Of Squares */
-private static UnivariateStatistic sumSq = new SumOfSquares();
-
-/** Percentile */
-private static Percentile percentile = new Percentile();
-
/**
* The sum of the values that have been added to Univariate.
* @param values Is a double[] containing the values
* @return the sum of the values or Double.NaN if the array is empty
*/
public static double sum(double[] values) {
-return sum.evaluate(values, 0, values.length);
+return sum(values, 0, values.length);
}
/**
@@ -133,7 +79,12 @@
* @return the sum of the values or Double.NaN if the array is empty
*/
public static double sum(double[] values, int begin, int length) {
-return sum.evaluate(values, begin, length);
+testInput(values, begin, length);
+double accum = 0.0;
+for (int i = begin; i begin + length; i++) {
+accum += values[i];
+}
+return accum;
}
/**
@@ -142,7 +93,7 @@
* @return the sum of the squared values or Double.NaN if the array is empty
*/
public static double sumSq(double[] values) {
-return sumSq.evaluate(values);
+return sumSq(values, 0, values.length);
}
/**
@@ -153,7 +104,12 @@
* @return the sum of the squared values or Double.NaN if the array is empty
*/
public static double sumSq(double[] values, int begin, int length) {
-return sumSq.evaluate(values, begin, length);
+testInput(values, begin, length);
+double accum = 0.0;
+for (int i = begin; i begin + length; i++) {
+accum += Math.pow(values[i], 2.0);
+}
+return accum;
}
/**
@@ -162,7 +118,7 @@
* @return the product values or Double.NaN if the array is empty
*/
public static double product(double[] values) {
-
[lamg] Re: Release of Commons Lang 2.0 (take 2)
From: Henri Yandell [EMAIL PROTECTED] [http://www.apache.org/~bayard/lang2.0/ contains a preliminary build of 2.0 and the javadoc and javadiff] The zip file has the following issues: - ReleaseNotes.txt refers to the 1.0 version - Javadoc includes non-public scoped classes (Although you probably knew these I thought I'd point them out...) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release of Commons Lang 2.0 (take 2)
+1 [ ] +1 I support Commons Lang 2.0 [ ] +0 Huh? Sure, let me sleep. [ ] -0 Lang? Sounds bad. [ ] -1 I hate you guys. [http://www.apache.org/~bayard/lang2.0/ contains a preliminary build of 2.0 and the javadoc and javadiff] What's not going: lang.functor has been removed from Lang. Collections will gain what it needs and [Functor] will be looked to for the complete functor-style solution. lang.reflect is not ready yet. What's new: -- lang.math.* package, which contains Range classes, RandomUtils and a Fraction class. lang.util.* package, which contains an IdentifierUtils, for easing IDs, a Validate class [akin to JUnit Assert in style] and BitField from the old Commons Util project [as created by POI]. lang.time.* package, which contains a DateUtils, an optimised DateFormat, a StopWatch class for measuring time periods, a DateFormatUtils and a DurationFormatUtils [for describing time periods]. In the top level package, we see a series of additions. There are a set of reusable Exceptions which provide slightly tighter meaning than their Commons Lang superclasses, IllegalClassException and NotImplementedException are examples of these. We also see the addition of more Utils classes: ArrayUtils BooleanUtils ClassUtils StringEscapeUtils StringPrintWriter WordWrapUtils What's changed: -- ToStringBuilder has gained an inner class. builder.* packages have gained new methods NumberUtils has a series of constants, LONG_ZERO, LONG_ONE etc. It is also deprecated for a move into the math subpackage. StringUtils has a series of new methods. A couple have been deprecated. The order in which a nested exception is printed has been reversed and a static legacy option left to reverse it the other way if desired. This now matches JDK 1.4 direction. What's gone: --- lang.NumberRange is gone as it has now moved into the math subpackage. The release: --- Following a successful vote, the PMC will be notified of the desire to release and the instructions at http://jakarta.apache.org/commons/releases/ followed to create a release. A changelog with 'jardiff' will be included. 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]
Re: [VOTE] Release of Commons Lang 2.0 (take 2)
Stephen Colebourne [EMAIL PROTECTED] writes: +1 +1 [ ] +1 I support Commons Lang 2.0 [ ] +0 Huh? Sure, let me sleep. [ ] -0 Lang? Sounds bad. [ ] -1 I hate you guys. [http://www.apache.org/~bayard/lang2.0/ contains a preliminary build of 2.0 and the javadoc and javadiff] What's not going: lang.functor has been removed from Lang. Collections will gain what it needs and [Functor] will be looked to for the complete functor-style solution. lang.reflect is not ready yet. What's new: -- lang.math.* package, which contains Range classes, RandomUtils and a Fraction class. lang.util.* package, which contains an IdentifierUtils, for easing IDs, a Validate class [akin to JUnit Assert in style] and BitField from the old Commons Util project [as created by POI]. lang.time.* package, which contains a DateUtils, an optimised DateFormat, a StopWatch class for measuring time periods, a DateFormatUtils and a DurationFormatUtils [for describing time periods]. In the top level package, we see a series of additions. There are a set of reusable Exceptions which provide slightly tighter meaning than their Commons Lang superclasses, IllegalClassException and NotImplementedException are examples of these. We also see the addition of more Utils classes: ArrayUtils BooleanUtils ClassUtils StringEscapeUtils StringPrintWriter WordWrapUtils What's changed: -- ToStringBuilder has gained an inner class. builder.* packages have gained new methods NumberUtils has a series of constants, LONG_ZERO, LONG_ONE etc. It is also deprecated for a move into the math subpackage. StringUtils has a series of new methods. A couple have been deprecated. The order in which a nested exception is printed has been reversed and a static legacy option left to reverse it the other way if desired. This now matches JDK 1.4 direction. What's gone: --- lang.NumberRange is gone as it has now moved into the math subpackage. The release: --- Following a successful vote, the PMC will be notified of the desire to release and the instructions at http://jakarta.apache.org/commons/releases/ followed to create a release. A changelog with 'jardiff' will be included. 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] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire --- Quote of the week: It is pointless to tell people anything when you know that they won't process the message. --- Jonathan Revusky - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] my plans, please comment
Oops, I didn't realize that. Thanks for pointing that out. Ok, so we got another todo instead: - Rename all *Util.java to *Utils.java for consistency. BTW: I'll be out of touch until next Friday. On 05.07.2003 16:32:56 Stephen Colebourne wrote: From: Jeremias Maerki [EMAIL PROTECTED] - Rename FileUtils to FileUtil for consistency. In fact, its IOUtil that is wrong. All jakarta-commons utility classes end in Utils. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release of Commons Lang 2.0 (take 2)
+1 Steven Caswell [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving One ring to rule them all, one ring to find them... -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Saturday, July 05, 2003 5:52 PM To: Jakarta Commons Developers List Subject: [VOTE] Release of Commons Lang 2.0 (take 2) (Repeating myself from the previous occasion) Our t's are dotted and our i's are crossed, so we'd like to make a release of Commons Lang 2.0. [ ] +1 I support Commons Lang 2.0 [ ] +0 Huh? Sure, let me sleep. [ ] -0 Lang? Sounds bad. [ ] -1 I hate you guys. [http://www.apache.org/~bayard/lang2.0/ contains a preliminary build of 2.0 and the javadoc and javadiff] What's not going: lang.functor has been removed from Lang. Collections will gain what it needs and [Functor] will be looked to for the complete functor-style solution. lang.reflect is not ready yet. What's new: -- lang.math.* package, which contains Range classes, RandomUtils and a Fraction class. lang.util.* package, which contains an IdentifierUtils, for easing IDs, a Validate class [akin to JUnit Assert in style] and BitField from the old Commons Util project [as created by POI]. lang.time.* package, which contains a DateUtils, an optimised DateFormat, a StopWatch class for measuring time periods, a DateFormatUtils and a DurationFormatUtils [for describing time periods]. In the top level package, we see a series of additions. There are a set of reusable Exceptions which provide slightly tighter meaning than their Commons Lang superclasses, IllegalClassException and NotImplementedException are examples of these. We also see the addition of more Utils classes: ArrayUtils BooleanUtils ClassUtils StringEscapeUtils StringPrintWriter WordWrapUtils What's changed: -- ToStringBuilder has gained an inner class. builder.* packages have gained new methods NumberUtils has a series of constants, LONG_ZERO, LONG_ONE etc. It is also deprecated for a move into the math subpackage. StringUtils has a series of new methods. A couple have been deprecated. The order in which a nested exception is printed has been reversed and a static legacy option left to reverse it the other way if desired. This now matches JDK 1.4 direction. What's gone: --- lang.NumberRange is gone as it has now moved into the math subpackage. The release: --- Following a successful vote, the PMC will be notified of the desire to release and the instructions at http://jakarta.apache.org/commons/releases/ followed to create a release. A changelog with 'jardiff' will be included. 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]
[lang] WordWrapUtils
Henri Yandell wrote: We also see the addition of more Utils classes: ... WordWrapUtils RT mode: It would be interesting if WordWrap would implement Unicode TR14. I, or better the FOP project, have also a hyphenator which would also fit with the word wrapping issue. Finally I have a spell chacker (a rewrite of MySpell in Java) which searches a home. Because it loads the whole dictionary into memory, I dont consider it ready for use in long running programs, like servers. Apart from this, is anybody interested in including this type of software into [lang], or perhaps in sponsoring a [text] project in the sandbox? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Re: Release of Commons Lang 2.0 (take 2)
On Sun, 6 Jul 2003, Stephen Colebourne wrote: From: Henri Yandell [EMAIL PROTECTED] [http://www.apache.org/~bayard/lang2.0/ contains a preliminary build of 2.0 and the javadoc and javadiff] The zip file has the following issues: - ReleaseNotes.txt refers to the 1.0 version Need to write the new ReleaseNotes. Will aim that for today while votes are bouncing around. - Javadoc includes non-public scoped classes Damn. Will look at the build.xml. (Although you probably knew these I thought I'd point them out...) Nah :) - 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 TestPropertiesSequence.java
henning 2003/07/06 08:09:27 Added: configuration/conf testSequenceDigester.xml testSequence.properties configuration/src/test/org/apache/commons/configuration TestPropertiesSequence.java Log: Test to make sure that a CompositeConfiguration and a Properties Configuration return their keys in the same order. Revision ChangesPath 1.1 jakarta-commons-sandbox/configuration/conf/testSequenceDigester.xml Index: testSequenceDigester.xml === ?xml version=1.0 encoding=ISO-8859-1 ? configuration properties className=org.apache.commons.configuration.PropertiesConfiguration fileName=conf/testSequence.properties/ /configuration 1.1 jakarta-commons-sandbox/configuration/conf/testSequence.properties Index: testSequence.properties === prefix.Fa.postfix=value.Fa prefix.Po.postfix=value.Po prefix.Ru.postfix=value.Ru prefix.Se.postfix=value.Se prefix.As.postfix=value.As prefix.Gl.postfix=value.Gl prefix.Pu.postfix=value.Pu prefix.Te.postfix=value.Te prefix.Ve.postfix=value.Ve 1.1 jakarta-commons-sandbox/configuration/src/test/org/apache/commons/configuration/TestPropertiesSequence.java Index: TestPropertiesSequence.java === package org.apache.commons.configuration; /* * The Apache Software License, Version 1.1 * * Copyright (c) 2001-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 acknowledgment: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgment may appear in the software itself, *if and wherever such third-party acknowledgments normally appear. * * 4. The names Apache and Apache Software Foundation and *Apache Turbine 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, *Apache Turbine, nor may Apache appear in their name, 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/. */ import java.io.File; import java.util.Iterator; import java.util.List; import junit.framework.Test; import junit.framework.TestCase; import junit.framework.TestSuite; import org.apache.commons.collections.IteratorUtils; import org.apache.commons.lang.StringUtils; import org.apache.commons.configuration.BaseConfiguration; /** * Test that the configuration factory returns keys in the same * sequence as the properties configurator * * @author a href=mailto:[EMAIL PROTECTED]Eric Pugh/a * @author a href0mailto:[EMAIL PROTECTED]Henning P. Schmiedehausen/a * @version $Id:
Re: [IO] my plans, please comment
On Thu, 3 Jul 2003, Jeremias Maerki wrote: - Setup a website to attract more people and to prepare for a release. Let me know if you need help with this. Additional ideas: - Add an additional ByteArrayOutputStream variant that saves content in memory just as the original but starts to write to a temp file when a given number of bytes is surpassed. This is to reduce the memory usage for big things. Sounds good. For reference, I've just looked up what projects/modules are currently showing as depedant on Commons IO in Gump: - commons-xo - db-torque - jakarta-turbine-3 - jakarta-turbine-stratum - jakarta-turbine-stratum-full - maven - maven-bootstrap - xml-fop Youch. What needs to be done to bring IO to release readiness? What I see is: - Many classes need test cases (I'll try to write some) - filefilter, input and output packages look pretty good, probably need some occasional documentation touch-up. - I don't know about the compress package. There's bzip2 in a separate sub-subproject. Ant also still has classes for bzip/zip/tar. I think these parts should be consolidated in a separate compress project. Compress should be pulled out I agree. Have you noticed the list of todo's in STATUS.html? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration BaseConfiguration.java
henning 2003/07/06 08:14:10
Modified:configuration/src/java/org/apache/commons/configuration
BaseConfiguration.java
Log:
Replace the internal Hashtable with the keysAsListed ArrayList by the
commons-collections provided SequencedHashMap, which keeps its keys in
sequence automatically.
Revision ChangesPath
1.13 +6 -30
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.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- BaseConfiguration.java7 Jun 2003 18:24:00 - 1.12
+++ BaseConfiguration.java6 Jul 2003 15:14:10 - 1.13
@@ -56,14 +56,16 @@
import java.util.ArrayList;
import java.util.Collection;
-import java.util.Hashtable;
import java.util.Iterator;
import java.util.List;
+import java.util.Map;
import java.util.NoSuchElementException;
import java.util.Properties;
import java.util.StringTokenizer;
import java.util.Vector;
+import org.apache.commons.collections.SequencedHashMap;
+
/**
* Basic configuration classe. Stores the configuration data but does not
* provide any load or save functions. If you want to load your Configuration
@@ -92,18 +94,11 @@
private static final int INITIAL_LIST_SIZE = 2;
/** stores the configuration key-value pairs */
-private Hashtable store = new Hashtable();
+private SequencedHashMap store = new SequencedHashMap();
/** stores the configuration key-value pairs */
protected Configuration defaults = null;
-/**
- * These are the keys in the order they listed in the configuration file.
- * This is useful when you wish to perform operations with configuration
- * information in a particular order.
- */
-protected ArrayList keysAsListed = new ArrayList();
-
/** start token */
protected static final String START_TOKEN = ${;
/** end token */
@@ -250,13 +245,6 @@
*/
protected void addPropertyDirect(String key, Object obj)
{
-// safety check
-if (!store.containsKey(key))
-{
-keysAsListed.add(key);
-}
-
-// and the value
store.put(key, obj);
}
@@ -506,18 +494,6 @@
{
if (containsKey(key))
{
-/*
- * we also need to rebuild the keysAsListed or else things get
- * *very* confusing
- */
-for (int i = 0; i keysAsListed.size(); i++)
-{
-if (((String) keysAsListed.get(i)).equals(key))
-{
-keysAsListed.remove(i);
-break;
-}
-}
store.remove(key);
}
}
@@ -530,7 +506,7 @@
*/
public Iterator getKeys()
{
-return keysAsListed.iterator();
+return store.iterator();
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration CompositeConfiguration.java
henning 2003/07/06 08:19:08
Modified:configuration/src/java/org/apache/commons/configuration
CompositeConfiguration.java
Log:
One of the properties of the normal configuration objects like the
PropertiesConfiguration is, that it keeps the sequence of keys the
same as it was added. To get this from the CompositeConfiguration, it
is necessary to keep the additional inMemory Keys at the back of the
configuration list. Else things like adding single keys to an existing
configuration (just as needed e.g. by Turbine) won't work.
Revision ChangesPath
1.14 +25 -9
jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/CompositeConfiguration.java
Index: CompositeConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/CompositeConfiguration.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- CompositeConfiguration.java 20 Jun 2003 07:50:47 - 1.13
+++ CompositeConfiguration.java 6 Jul 2003 15:19:08 - 1.14
@@ -52,13 +52,16 @@
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/
+
import java.util.ArrayList;
import java.util.Iterator;
+import java.util.LinkedList;
import java.util.List;
import java.util.ListIterator;
import java.util.NoSuchElementException;
import java.util.Properties;
import java.util.Vector;
+
/**
* This Configuration class allows you to add multiple different types of
Configuration
* to this CompositeConfiguration. If you add Configuration1, and then
Configuration2,
@@ -67,35 +70,48 @@
* If Configuration1 doesn't have the property, then Configuration2 will be checked.
*
* @author a href=mailto:[EMAIL PROTECTED]Eric Pugh/a
+ * @author a href=mailto:[EMAIL PROTECTED]Henning P. Schmiedehausen/a
* @version $Id$
*/
public class CompositeConfiguration implements Configuration
{
/** Array holding all the configuration */
-private ArrayList configList = new ArrayList();
-/** Configuration that holds in memory stuff. Inserted as first so any
- * setProperty() override anything else added.
+private LinkedList configList = new LinkedList();
+
+/**
+ * Configuration that holds in memory stuff. Inserted as first so any
+ * setProperty() override anything else added.
*/
private BaseConfiguration inMemoryConfiguration;
+
/**
* Creates an empty CompositeConfiguration object which can then
* be added some other Configuration files
*/
public CompositeConfiguration()
{
-inMemoryConfiguration = new BaseConfiguration();
-addConfiguration(inMemoryConfiguration);
+clear();
}
+
public void addConfiguration(Configuration config)
{
if (!configList.contains(config))
{
-configList.add(config);
+// As the inMemoryConfiguration contains all manually added keys,
+// we must make sure that it is always last. Normal, non composed
+// configuration add their keys at the end of the configuration and
+// we want to mimic this behaviour.
+configList.add(configList.indexOf(inMemoryConfiguration), config);
}
}
public void removeConfiguration(Configuration config)
{
-configList.remove(config);
+// Make sure that you can't remove the inMemoryConfiguration from
+// the CompositeConfiguration object
+if (!config.equals(inMemoryConfiguration))
+{
+configList.remove(config);
+}
}
public int getNumberOfConfigurations()
{
@@ -106,7 +122,7 @@
configList.clear();
// recreate the in memory configuration
inMemoryConfiguration = new BaseConfiguration();
-addConfiguration(inMemoryConfiguration);
+configList.addLast(inMemoryConfiguration);
}
/**
* CompositeConfigurations can not be added to
-
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/07/06 08:23:53 Modified:configuration/src/test/org/apache/commons/configuration TestConfigurationFactory.java Log: The first added configuration has the index == 0. Change the test to account for this. Revision ChangesPath 1.7 +9 -9 jakarta-commons-sandbox/configuration/src/test/org/apache/commons/configuration/TestConfigurationFactory.java Index: TestConfigurationFactory.java === RCS file: /home/cvs/jakarta-commons-sandbox/configuration/src/test/org/apache/commons/configuration/TestConfigurationFactory.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- TestConfigurationFactory.java 27 Jun 2003 20:06:08 - 1.6 +++ TestConfigurationFactory.java 6 Jul 2003 15:23:53 - 1.7 @@ -96,8 +96,8 @@ compositeConfiguration = (CompositeConfiguration) configurationFactory.getConfiguration(); assertEquals(Verify how many configs, 3, compositeConfiguration.getNumberOfConfigurations()); -assertEquals(PropertiesConfiguration.class, compositeConfiguration.getConfiguration(1).getClass()); -PropertiesConfiguration pc = (PropertiesConfiguration) compositeConfiguration.getConfiguration(1); +assertEquals(PropertiesConfiguration.class, compositeConfiguration.getConfiguration(0).getClass()); +PropertiesConfiguration pc = (PropertiesConfiguration) compositeConfiguration.getConfiguration(0); assertNotNull(Make sure we have a fileName: + pc.getFileName(), pc.getFileName()); @@ -131,9 +131,9 @@ assertEquals(Verify how many configs, 3, compositeConfiguration.getNumberOfConfigurations()); -assertEquals(PropertiesConfiguration.class, compositeConfiguration.getConfiguration(1).getClass()); +assertEquals(PropertiesConfiguration.class, compositeConfiguration.getConfiguration(0).getClass()); -PropertiesConfiguration pc = (PropertiesConfiguration) compositeConfiguration.getConfiguration(1); +PropertiesConfiguration pc = (PropertiesConfiguration) compositeConfiguration.getConfiguration(0); assertNotNull(Make sure we have a fileName: + pc.getFileName(), pc.getFileName()); assertTrue(Make sure we have loaded our key, pc.getBoolean(test.boolean)); @@ -155,9 +155,9 @@ assertEquals(Verify how many configs, 2, compositeConfiguration.getNumberOfConfigurations()); -assertEquals(PropertiesConfiguration.class, compositeConfiguration.getConfiguration(1).getClass()); +assertEquals(PropertiesConfiguration.class, compositeConfiguration.getConfiguration(0).getClass()); -PropertiesConfiguration pc = (PropertiesConfiguration) compositeConfiguration.getConfiguration(1); +PropertiesConfiguration pc = (PropertiesConfiguration) compositeConfiguration.getConfiguration(0); assertNotNull(Make sure we have a fileName: + pc.getFileName(), pc.getFileName()); assertTrue(Make sure we have loaded our key, pc.getBoolean(test.boolean)); @@ -186,9 +186,9 @@ assertEquals(Verify how many configs, 2, compositeConfiguration.getNumberOfConfigurations()); -assertEquals(PropertiesConfiguration.class, compositeConfiguration.getConfiguration(1).getClass()); +assertEquals(PropertiesConfiguration.class, compositeConfiguration.getConfiguration(0).getClass()); -PropertiesConfiguration pc = (PropertiesConfiguration) compositeConfiguration.getConfiguration(1); +PropertiesConfiguration pc = (PropertiesConfiguration) compositeConfiguration.getConfiguration(0); assertNotNull(Make sure we have a fileName: + pc.getFileName(), pc.getFileName()); assertTrue(Make sure we have loaded our key, pc.getBoolean(test.boolean)); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] WordWrapUtils
J.Pietschmann [EMAIL PROTECTED] writes: +1 However, as it was me who resurrected WordWrapUtils, I'd like to see them in a commons-proper package the sooner the better, because we're currently planning to remove our internal class from the Turbine code and we want to use it. Moving it to a commons-text package later would be really nice. Regards Henning Henri Yandell wrote: We also see the addition of more Utils classes: ... WordWrapUtils RT mode: It would be interesting if WordWrap would implement Unicode TR14. I, or better the FOP project, have also a hyphenator which would also fit with the word wrapping issue. Finally I have a spell chacker (a rewrite of MySpell in Java) which searches a home. Because it loads the whole dictionary into memory, I dont consider it ready for use in long running programs, like servers. Apart from this, is anybody interested in including this type of software into [lang], or perhaps in sponsoring a [text] project in the sandbox? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire --- Quote of the week: It is pointless to tell people anything when you know that they won't process the message. --- Jonathan Revusky - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] my plans, please comment
On 06.07.2003 17:13:26 Henri Yandell wrote: On Thu, 3 Jul 2003, Jeremias Maerki wrote: - Setup a website to attract more people and to prepare for a release. Let me know if you need help with this. Thanks. snip/ What needs to be done to bring IO to release readiness? What I see is: - Many classes need test cases (I'll try to write some) - filefilter, input and output packages look pretty good, probably need some occasional documentation touch-up. - I don't know about the compress package. There's bzip2 in a separate sub-subproject. Ant also still has classes for bzip/zip/tar. I think these parts should be consolidated in a separate compress project. Compress should be pulled out I agree. Have you noticed the list of todo's in STATUS.html? Nope. :-O But looking at them, they seem confusing: Compress - Move the compress sub-package out of IO - READY What does READY mean here? Ready to be moved out? Then, does that mean we can simply start a new package compress (or compression) and move it there and integrate bzip2? But I guess we should synchronize with the Ant-people first. I will add my items to the file. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io STATUS.html
jeremias2003/07/06 08:47:27 Modified:io STATUS.html Log: Add myself as committer. Add todo items. Revision ChangesPath 1.9 +19 -4 jakarta-commons-sandbox/io/STATUS.html Index: STATUS.html === RCS file: /home/cvs/jakarta-commons-sandbox/io/STATUS.html,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- STATUS.html 16 May 2003 22:29:03 - 1.8 +++ STATUS.html 6 Jul 2003 15:47:27 - 1.9 @@ -59,6 +59,7 @@ lia href=maito:[EMAIL PROTECTED]Nicola Ken Barozzi/abr/li lia href=maito:[EMAIL PROTECTED]Henri Yandell/abr/li lia href=maito:[EMAIL PROTECTED]Stephen Colebourne/abr/li + lia href=maito:[EMAIL PROTECTED]Jeremias Maerki/abr/li liFancy volunteering? We need you!/li /ul @@ -70,9 +71,19 @@ release of this component:/p ul liCompress - Move the compress sub-package out of IO - READY/li - liRename FileUtilTest to FileUtilsTest/li + liRename FileUtilTest to FileUtilsTest - DONE/li + liRename *Util.java for *Utils.java for consistency/li liExtract code from IOUtils to CopyUtils? /li - liRemove StreamUtils as all its methods are in IOUtils - READY/li + liRemove StreamUtils as all its methods are in IOUtils - DONE/li + liIOUtil: Remove the toByteArray() variants with the bufferSize +parameter. Reasoning can be found at +http://www.mail-archive.com/[EMAIL PROTECTED]/msg19703.html/li + liIOUtil: Change toByteArray() methods to use the new +ByteArrayOutputStream which should improve performance considerably./li + liIOUtil: Remove the deprecated bufferedCopy method. IO is not released +so we should be able to do that./li + liFileUtils: Add isFileNewer() method from Alban Peignier: +http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=348688/li /ul h55.1 NEW CODE/h5 ul @@ -83,8 +94,12 @@ liFormattedWriter, when it writes out values it uses Format objects to output them. /li liFixedWidthReader. Reads in files with a known width, ie) mainframe like. /li liFinder system. Generic code to find things in things. So FileFinder, ClassFinder, ZipFinder. Probably too big for IO/li + liAdd an additional ByteArrayOutputStream variant that saves content +in memory just as the original but starts to write to a temp file when +a given number of bytes is surpassed. This is to reduce the memory +usage for big things./li /ul - + table border=1 tbody tr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] WordWrapUtils
Henning P. Schmiedehausen wrote: +1 Ahem, +1 to what: [ ] Creating a sandbox [text] component, move WordWrapUtils there and [ ] implement TR14 [ ] add hyphenation including all utilities [ ] add spell checking [ ] improve/add stuff to WordWrapUtils in [lang] [ ] something else: However, as it was me who resurrected WordWrapUtils, I'd like to see them in a commons-proper package the sooner the better, because we're currently planning to remove our internal class from the Turbine code and we want to use it. Moving it to a commons-text package later would be really nice. Hmm, there are rules, I mean a developer community is required. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jdbc2pool [was Re: DBCP status?]
Have looked a couple of weeks ago * jdbc2 part seemed out of operation to me (just can't go into a release) I've seen a couple statements like this. No one presents any reasons for their statement though. I started this pool and use it in production, so have dual interest in hearing what the problems are. I see one bug entered against it, but I would not classify it as a blocker. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] WordWrapUtils
J.Pietschmann [EMAIL PROTECTED] writes: Henning P. Schmiedehausen wrote: +1 Ahem, +1 to what: +1 to keep WordWrapUtils in commons-lang for the next release but moving it into commons-text (sandbox) and deprecating it from c-l once the commons-text leaves sandbox status. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire --- Quote of the week: It is pointless to tell people anything when you know that they won't process the message. --- Jonathan Revusky - 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 TestEqualBehaviour.java
henning 2003/07/06 10:47:24
Added: configuration/conf testEqual.properties
testEqualDigester.xml
configuration/src/test/org/apache/commons/configuration
TestEqualBehaviour.java
Log:
Compare the results of some basic operations on simple (properties) configuration
and composite configuration. They should result in the same behaviour
Revision ChangesPath
1.1 jakarta-commons-sandbox/configuration/conf/testEqual.properties
Index: testEqual.properties
===
property.a = a
property.b = b
property.c = 100
#
# Value set twice
property.a = aa
clear.property = delete me
existing.property = i exist
1.1 jakarta-commons-sandbox/configuration/conf/testEqualDigester.xml
Index: testEqualDigester.xml
===
?xml version=1.0 encoding=ISO-8859-1 ?
configuration
properties className=org.apache.commons.configuration.PropertiesConfiguration
fileName=conf/testEqual.properties/
/configuration
1.1
jakarta-commons-sandbox/configuration/src/test/org/apache/commons/configuration/TestEqualBehaviour.java
Index: TestEqualBehaviour.java
===
package org.apache.commons.configuration;
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2001-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 acknowledgment:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgment may appear in the software itself,
*if and wherever such third-party acknowledgments normally appear.
*
* 4. The names Apache and Apache Software Foundation and
*Apache Turbine 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,
*Apache Turbine, nor may Apache appear in their name, 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/.
*/
import java.io.File;
import java.util.Iterator;
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
/**
* Compare the behaviour of various methods between CompositeConfiguration
* and normal (Properties) Configuration
*
* @author a href0mailto:[EMAIL PROTECTED]Henning P. Schmiedehausen/a
* @version $Id: TestEqualBehaviour.java,v 1.1 2003/07/06 17:47:24 henning Exp $
*/
public class TestEqualBehaviour
extends TestCase
{
public TestEqualBehaviour(String name) throws Exception
{
super(name);
}
public static Test suite()
{
return new
cvs commit: jakarta-commons-sandbox/configuration/src/test/org/apache/commons/configuration TestCompositeConfiguration.java
henning 2003/07/06 11:14:10
Modified:configuration/src/test/org/apache/commons/configuration
TestCompositeConfiguration.java
Log:
Make sure we can't remove the inMemory configuration from a Composite
Configuration object
Fix up the test indices, the first added configuration object is now
index 0
The testAddingProperty test was quite broken. Fix it up. addProperty means
add property, not replace property.
Revision ChangesPath
1.9 +30 -5
jakarta-commons-sandbox/configuration/src/test/org/apache/commons/configuration/TestCompositeConfiguration.java
Index: TestCompositeConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/configuration/src/test/org/apache/commons/configuration/TestCompositeConfiguration.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- TestCompositeConfiguration.java 18 Jun 2003 17:45:50 - 1.8
+++ TestCompositeConfiguration.java 6 Jul 2003 18:14:09 - 1.9
@@ -120,6 +120,18 @@
assertEquals(Make sure we get the property from conf1 first,
override.packages, cc.getString(packages));
}
+public void testCantRemoveMemoryConfig() throws Exception
+{
+cc.clear();
+assertEquals(1, cc.getNumberOfConfigurations());
+
+Configuration internal = cc.getConfiguration(0);
+cc.removeConfiguration(internal);
+
+assertEquals(1, cc.getNumberOfConfigurations());
+
+}
+
public void testGetPropertyMissing() throws Exception
{
cc.addConfiguration(conf1);
@@ -176,8 +188,8 @@
{
cc.addConfiguration(conf1);
cc.addConfiguration(dom4jConf);
-assertEquals(PropertiesConfiguration.class,
cc.getConfiguration(1).getClass());
-assertEquals(DOM4JConfiguration.class, cc.getConfiguration(2).getClass());
+assertEquals(PropertiesConfiguration.class,
cc.getConfiguration(0).getClass());
+assertEquals(DOM4JConfiguration.class, cc.getConfiguration(1).getClass());
}
/**
@@ -193,7 +205,8 @@
}
/**
- * Tests adding values. Make sure they override any other properties!
+ * Tests adding values. Make sure they _DON'T_ override any other properties
but add to the
+ * existing properties and keep sequence
*/
public void testAddingProperty() throws Exception
{
@@ -201,8 +214,20 @@
cc.addConfiguration(conf1);
cc.addConfiguration(dom4jConf);
+String [] values = cc.getStringArray(test.short);
+
+assertEquals(Number of values before add is wrong!, 2, values.length);
+assertEquals(First Value before add is wrong, 1, values[0]);
+assertEquals(Second Value is wrong, 8, values[1]);
+
cc.addProperty(test.short, 88);
-assertEquals(Make sure test.short is overridden!, 88,
cc.getString(test.short));
+
+values = cc.getStringArray(test.short);
+
+assertEquals(Number of values is wrong!, 3, values.length);
+assertEquals(First Value is wrong, 1, values[0]);
+assertEquals(Second Value is wrong, 8, values[1]);
+assertEquals(Third Value is wrong, 88, values[2]);
}
/**
-
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 TestEqualBehaviour.java
henning 2003/07/06 11:15:30
Modified:configuration/src/test/org/apache/commons/configuration
TestEqualBehaviour.java
Log:
Make sure we also test the getVector() behaviour. Add some clearer messages
Revision ChangesPath
1.2 +24 -7
jakarta-commons-sandbox/configuration/src/test/org/apache/commons/configuration/TestEqualBehaviour.java
Index: TestEqualBehaviour.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/configuration/src/test/org/apache/commons/configuration/TestEqualBehaviour.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TestEqualBehaviour.java 6 Jul 2003 17:47:24 - 1.1
+++ TestEqualBehaviour.java 6 Jul 2003 18:15:30 - 1.2
@@ -57,6 +57,7 @@
import java.io.File;
import java.util.Iterator;
+import java.util.Vector;
import junit.framework.Test;
import junit.framework.TestCase;
@@ -112,10 +113,10 @@
{
String key1 = (String) it1.next();
String key2 = (String) it2.next();
-assertEquals(msg, key1, key2);
-assertEquals(msg, c1.containsKey(key1), c2.containsKey(key2));
+assertEquals(msg + , Keys: , key1, key2);
+assertEquals(msg + , Contains: , c1.containsKey(key1),
c2.containsKey(key2));
}
-assertEquals(msg, it1.hasNext(), it2.hasNext());
+assertEquals(msg + , Iterator: , it1.hasNext(), it2.hasNext());
}
/**
@@ -126,12 +127,28 @@
String [] s1 = c1.getStringArray(key);
String [] s2 = c2.getStringArray(key);
-assertEquals(msg, s1.length, s2.length);
+assertEquals(msg + , length: , s1.length, s2.length);
for (int i = 0; i s1.length ; i++)
{
-assertEquals(msg, s1[i], s2[i]);
+assertEquals(msg + , String Array: , s1[i], s2[i]);
}
+
+Vector v1 = c1.getVector(key);
+Vector v2 = c2.getVector(key);
+
+assertEquals(msg + , Size: , v1.size(), v2.size());
+
+Iterator it1 = v1.iterator();
+Iterator it2 = v2.iterator();
+
+while(it1.hasNext() it2.hasNext())
+{
+String val1 = (String) it1.next();
+String val2 = (String) it2.next();
+assertEquals(msg + , Vector: , val1, val2);
+}
+assertEquals(msg + , Iterator End: , it1.hasNext(), it2.hasNext());
}
/**
@@ -263,7 +280,7 @@
}
/**
- * If we add a to an existng key, does it work?
+ * If we add a to an existing key, does it work?
*/
public void testAddingSet()
throws Exception
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration CompositeConfiguration.java
henning 2003/07/06 11:17:56
Modified:configuration/src/java/org/apache/commons/configuration
CompositeConfiguration.java
Log:
Changed getStringArray() and getVector() to return all the
configuration values referenced in all sub configurations.
Now CompositeConfiguration and Simple Configurations behave just the same
Revision ChangesPath
1.15 +20 -23
jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/CompositeConfiguration.java
Index: CompositeConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/CompositeConfiguration.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- CompositeConfiguration.java 6 Jul 2003 15:19:08 - 1.14
+++ CompositeConfiguration.java 6 Jul 2003 18:17:56 - 1.15
@@ -698,15 +698,10 @@
*/
public String[] getStringArray(String key)
{
-try
-{
-return getFirstMatchingConfig(key).getStringArray(key);
-}
-catch (NoSuchElementException nsee)
-{
-return new String[0];
-}
+Vector v = getVector(key);
+return (String []) v.toArray(new String [0]);
}
+
/**
* Get a Vector of strings associated with the given configuration key.
*
@@ -717,15 +712,20 @@
*/
public Vector getVector(String key)
{
-try
+Vector v = new Vector();
+
+for (ListIterator li = configList.listIterator(); li.hasNext();)
{
-return getFirstMatchingConfig(key).getVector(key);
-}
-catch (NoSuchElementException nsee)
-{
-return new Vector();
+Configuration config = (Configuration) li.next();
+if (config.containsKey(key))
+{
+v.addAll(config.getVector(key));
+}
}
+
+return v;
}
+
/**
* Get a Vector of strings associated with the given configuration key.
*
@@ -737,15 +737,11 @@
*/
public Vector getVector(String key, Vector defaultValue)
{
-try
-{
-return getFirstMatchingConfig(key).getVector(key, defaultValue);
-}
-catch (NoSuchElementException nsee)
-{
-return defaultValue;
-}
+Vector v = getVector(key);
+
+return (v.size() == 0) ? defaultValue : v;
}
+
private Configuration getFirstMatchingConfig(String key)
{
for (ListIterator i = configList.listIterator(); i.hasNext();)
@@ -759,6 +755,7 @@
throw new NoSuchElementException(
'\'' + key + ' doesn't map to an existing object);
}
+
public Configuration getConfiguration(int index)
{
return (Configuration) configList.get(index);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/configuration maven.xml
henning 2003/07/06 11:25:36 Modified:configuration maven.xml Log: Remove maven warning about deprecated goal Revision ChangesPath 1.5 +2 -2 jakarta-commons-sandbox/configuration/maven.xml Index: maven.xml === RCS file: /home/cvs/jakarta-commons-sandbox/configuration/maven.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- maven.xml 21 Jun 2003 22:11:04 - 1.4 +++ maven.xml 6 Jul 2003 18:25:36 - 1.5 @@ -6,7 +6,7 @@ !-- -- !-- = -- -project default=java:jar +project default=jar:jar !-- NonStringTestHolder.java contains tests shared by JUnit and Cactus tests. This ugly hack moves the src from /src/test to /src/test-cactus so the Cactus tests will compile. Not sure what is worse, this hack, or - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release of Commons Lang 2.0 (take 2)
On Saturday, July 5, 2003, at 11:51 PM, Henri Yandell wrote: [X] +1 I support Commons Lang 2.0 [ ] +0 Huh? Sure, let me sleep. [ ] -0 Lang? Sounds bad. [ ] -1 I hate you guys. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DBCP] cpdsadapter needs a Statement implementation
I recently noticed that the cpdsadapter package needs to be fixed wrt the Statement.getConnection() method. It will currently return the underlying physical Connection object as opposed to the logical Connection which was used to create the Statement. When first writing cpdsapapter, I determined that using DelegatingConnection was not possible as it allowed reopening of a closed Connection. The code in jdbc2pool and cpdsadapter attempts to be fully jdbc2 (or later) compliant and the specification requires that a Connection object be unusable after close() is called. Now cpdsadapter needs a Statement implementation which will require a ResultSet implementation. Taking another look at DelegatingConnection, it could be used as the base class for a jdbc2 compliant Connection as long as the child class creates a no-op for the activate method. Does anyone see a problem with that approach? The only problem I have with going that route is the situation regarding the abandoned connection code. I thought it was already agreed that this code would be removed many months ago, but I am seeing revived debate and the possibility of retaining some of the code for possible logging. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DBCP] should Connection.close() render associated Statementobjects unusable.
I think that currently an application could call Connection.close() while retaining a reference to a Statement object and continue using it. The specification does not require Connection.close() to call Statement.close on any associated Statement(s). Is there a use case for closing a Connection while expecting a Statement to remain active? The general principal when developing a jdbc compliant pool is that the application should experience similar behavior whether a Connection came from a pool or not. I would expect that if a Connection was actually physically closed that operations on its Statement(s) or ResultSets to fail. Would anyone counter that expectation? This situation would appear to be the opposite of the abandoned connection problem, where helping a badly coded application would be straightforward and receiving an sql exception after calling ResultSet.next() on a closed Connection would be preferrable to having multiple threads continuing to use ResultSets while the Connection keeps getting returned to the pool. A related question: I have never found a reason to keep multiple Statements on a single Connection open. The spec states that only a single ResultSet can be open on a Statement at a time and that multiple Statements should be used if multiple open ResultSets are required. Should this be interpreted to mean multiple open Statements per Connection are allowed? john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/recursion TestRecursion.java recursion.xml
rdonkin 2003/07/06 14:10:35
Modified:betwixt/src/test/org/apache/commons/betwixt/recursion
TestRecursion.java recursion.xml
Log:
Improved unit tests by adding automated testing of xml output.
Revision ChangesPath
1.9 +57 -10
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/recursion/TestRecursion.java
Index: TestRecursion.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/recursion/TestRecursion.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- TestRecursion.java1 Jul 2003 19:12:36 - 1.8
+++ TestRecursion.java6 Jul 2003 21:10:34 - 1.9
@@ -108,16 +108,63 @@
public void testReadwithCollectionsInElementRoundTrip()
throws Exception
{
+//SimpleLog log = new
SimpleLog([testReadwithCollectionsInElementRoundTrip:XMLIntrospectorHelper]);
+//log.setLevel(SimpleLog.LOG_LEVEL_TRACE);
+//XMLIntrospectorHelper.setLog(log);
+
+//log = new
SimpleLog([testReadwithCollectionsInElementRoundTrip:XMLIntrospector]);
+//log.setLevel(SimpleLog.LOG_LEVEL_TRACE);
+
XMLIntrospector intro = createXMLIntrospector();
-//((SimpleLog) intro.getLog()).setLevel(SimpleLog.LOG_LEVEL_TRACE);
+//intro.setLog(log);
intro.setWrapCollectionsInElement(true);
+
+//log = new
SimpleLog([testReadwithCollectionsInElementRoundTrip:BeanReader]);
+//log.setLevel(SimpleLog.LOG_LEVEL_TRACE);
+
BeanReader reader = new BeanReader();
-reader.registerBeanClass(ElementBean.class);
reader.setXMLIntrospector(intro);
-Object object =
reader.parse(getTestFileURL(src/test/org/apache/commons/betwixt/recursion/recursion.xml));
+//reader.setLog(log);
+reader.registerBeanClass(ElementBean.class);
+
+ElementBean bean = (ElementBean) reader.parse(
+
getTestFileURL(src/test/org/apache/commons/betwixt/recursion/recursion.xml));
+
+List elements = bean.getElements();
+assertEquals(Root elements size, 2, elements.size());
+Element elementOne = (Element) elements.get(0);
+assertEquals(Element one name, element1, elementOne.getName());
+Element elementTwo = (Element) elements.get(1);
+assertEquals(Element two name, element2, elementTwo.getName());
+assertEquals(Element two children, 0, elementTwo.getElements().size());
+elements = elementOne.getElements();
+assertEquals(Element one children, 2, elements.size());
+Element elementOneOne = (Element) elements.get(0);
+assertEquals(Element one one name, element11, elementOneOne.getName());
+Element elementOneTwo = (Element) elements.get(1);
+assertEquals(Element one two name, element12, elementOneTwo.getName());
+assertEquals(Element one two children, 0,
elementOneTwo.getElements().size());
+elements = elementOneOne.getElements();
+assertEquals(Element one one children, 2, elements.size());
+Element elementOneOneOne = (Element) elements.get(0);
+assertEquals(Element one one one name, element111,
elementOneOneOne.getName());
+Element elementOneOneTwo = (Element) elements.get(1);
+assertEquals(Element one one two name, element112,
elementOneOneTwo.getName());
+
StringWriter buffer = new StringWriter();
-write (object, buffer, true);
-System.out.println(buffer : +buffer);
+write (bean, buffer, true);
+
+String xml = ?xml version='1.0'?ElementBeanelementselement
name='element1'
++ elementselement name='element11'elementselement
name='element111'
++ elements//elementelement
name='element112'elements//element
++ /elements/elementelement
name='element12'elements//element
++ /elements/elementelement name='element2'elements/
++ /element/elements/ElementBean;
+
+xmlAssertIsomorphic(
+parseString(xml),
+parseString(buffer.getBuffer().toString()),
+true);
}
/**
* This will test reading a simple recursive xml file
1.2 +5 -3
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/recursion/recursion.xml
Index: recursion.xml
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/recursion/recursion.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
Fw: [CLI][Proposal] V2 Model
Whoops - hit the message size limit. This time I've chucked the zip file on the web at http://www.oxspring.demon.co.uk/cli/clirob2.zip. I forgot to mention that the new model doesn't have the CommandLine vs CommandLineImpl vs CommandLineCreator distictions. There isn't any reason for this and it might be a good idea to fit this distinction back in. Also people should check out the Builders, particularly how the ArgumentBuilder fits in with Parents (I think the ApplicationTest has some real world-ish examples). I'm not sure how natural this will feel and am open to ideas on how to do it better Rob - Original Message - From: Rob Oxspring [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: John Keyes [EMAIL PROTECTED] Sent: Sunday, July 06, 2003 10:26 PM Subject: [CLI][Proposal] V2 Model Hi all, After posetive feedback from my previous model suggestion I've been working some more. The model still only deals with parsing so far but now copes with option groups, switches, and anonymous arguments. I've used the o.a.c.cli2 package now just to keep my changes together as a unit, a global replace of cli2 to cli is probably needed before committing to any branch. Below are the changes of note for this snapshot: Dropped the word Option from a few classnames as it seemed unnecessary. Option.getPrefixes() becomes Option.triggers(). This seems to match the usage the set of strings that trigger this option and allows me to use prefixes to mean something else... added Option.prefixes(). This returns the set of strings that this Option considers an option prefix. DefaultOptions would add - and -- to the set, commands would add each of their names, and switches would add +,- (or whatever). Groups would return the union of their Options' prefixes(). These can then be used when processing argument values to decide whether a particular arg[n] looks like an option or not. Formalised Argument so that it is an interface with two methods processParent(..) and processValues(...). This makes it reflect Parent more closely Renamed Options to Group. Makes it easier to spot the distinction between Option and Options both in code and discussion. Also I've formalised Group to be an interface with a default GroupImpl that can be built with a GroupBuilder instance. I've also removed the Exclusive/InclusiveGroup classes that existed at one point and added minimum and maximum parameters to the GroupImpl constructor - this should allow functionality to be implemented more flexibly in a single class. Still to do: Option currently has a commented out validation method. Some validation method needs to be added and implemented throughout to properly cope with the complex rules that exist. Plugin validation. Something like the current ValueValidator needs to be plugged in somewhere. HelpFormatter and friends. I've got plans for how these will work but nothing coded up yet. Lots of docs and tests. Rob - 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/univariate/summary SumTest.java SumLogTest.java SumSqTest.java ProductTest.java
mdiggory2003/07/06 19:12:47
Modified:math/src/test/org/apache/commons/math/stat/univariate/moment
MeanTest.java VarianceTest.java KurtosisTest.java
StandardDeviationTest.java SkewnessTest.java
math/src/test/org/apache/commons/math/stat/univariate
UnivariateStatisticAbstractTest.java
math/src/test/org/apache/commons/math/stat/univariate/rank
MinTest.java MaxTest.java
math/src/test/org/apache/commons/math/stat/univariate/summary
SumTest.java SumLogTest.java SumSqTest.java
ProductTest.java
Added: math/src/test/org/apache/commons/math/stat/univariate
StorelessUnivariateStatisticAbstractTest.java
Log:
Adding incremental tests for storeless univariates as evaluations are now based on
the implementations that were previously provided by StatUtils.
Revision ChangesPath
1.2 +2 -1
jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/univariate/moment/MeanTest.java
Index: MeanTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/univariate/moment/MeanTest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MeanTest.java 5 Jul 2003 18:24:50 - 1.1
+++ MeanTest.java 7 Jul 2003 02:12:47 - 1.2
@@ -56,6 +56,7 @@
import junit.framework.Test;
import junit.framework.TestSuite;
+import
org.apache.commons.math.stat.univariate.StorelessUnivariateStatisticAbstractTest;
import org.apache.commons.math.stat.univariate.UnivariateStatistic;
import org.apache.commons.math.stat.univariate.UnivariateStatisticAbstractTest;
@@ -64,7 +65,7 @@
*
* @author Mark Diggory
*/
-public class MeanTest extends UnivariateStatisticAbstractTest{
+public class MeanTest extends StorelessUnivariateStatisticAbstractTest{
protected Mean stat;
1.2 +2 -1
jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/univariate/moment/VarianceTest.java
Index: VarianceTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/univariate/moment/VarianceTest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- VarianceTest.java 5 Jul 2003 18:24:50 - 1.1
+++ VarianceTest.java 7 Jul 2003 02:12:47 - 1.2
@@ -56,6 +56,7 @@
import junit.framework.Test;
import junit.framework.TestSuite;
+import
org.apache.commons.math.stat.univariate.StorelessUnivariateStatisticAbstractTest;
import org.apache.commons.math.stat.univariate.UnivariateStatistic;
import org.apache.commons.math.stat.univariate.UnivariateStatisticAbstractTest;
@@ -64,7 +65,7 @@
*
* @author Mark Diggory
*/
-public class VarianceTest extends UnivariateStatisticAbstractTest{
+public class VarianceTest extends StorelessUnivariateStatisticAbstractTest{
protected Variance stat;
1.2 +2 -1
jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/univariate/moment/KurtosisTest.java
Index: KurtosisTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/univariate/moment/KurtosisTest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- KurtosisTest.java 5 Jul 2003 18:24:50 - 1.1
+++ KurtosisTest.java 7 Jul 2003 02:12:47 - 1.2
@@ -56,6 +56,7 @@
import junit.framework.Test;
import junit.framework.TestSuite;
+import
org.apache.commons.math.stat.univariate.StorelessUnivariateStatisticAbstractTest;
import org.apache.commons.math.stat.univariate.UnivariateStatistic;
import org.apache.commons.math.stat.univariate.UnivariateStatisticAbstractTest;
@@ -64,7 +65,7 @@
*
* @author Mark Diggory
*/
-public class KurtosisTest extends UnivariateStatisticAbstractTest{
+public class KurtosisTest extends StorelessUnivariateStatisticAbstractTest{
protected Kurtosis stat;
1.2 +2 -1
jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/univariate/moment/StandardDeviationTest.java
Index: StandardDeviationTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/univariate/moment/StandardDeviationTest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- StandardDeviationTest.java5 Jul 2003 18:24:50 - 1.1
+++
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/rank Max.java Min.java Percentile.java
mdiggory2003/07/06 19:15:20
Modified:math/src/java/org/apache/commons/math/stat/univariate/moment
FourthMoment.java GeometricMean.java Mean.java
ThirdMoment.java Kurtosis.java Variance.java
Skewness.java StandardDeviation.java
SecondMoment.java
math/src/java/org/apache/commons/math/stat/univariate/summary
SumOfSquares.java Product.java Sum.java
SumOfLogs.java
math/src/java/org/apache/commons/math/stat/univariate
UnivariateStatistic.java
AbstractUnivariateStatistic.java
StorelessUnivariateStatistic.java
AbstractStorelessUnivariateStatistic.java
math/src/java/org/apache/commons/math/stat/univariate/rank
Max.java Min.java Percentile.java
Log:
Addition of optimal array based evaluations available in StatUtils. These are not
delegates to StatUtils, they are implementations.
Revision ChangesPath
1.2 +6 -26
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/moment/FourthMoment.java
Index: FourthMoment.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/moment/FourthMoment.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- FourthMoment.java 5 Jul 2003 18:23:51 - 1.1
+++ FourthMoment.java 7 Jul 2003 02:15:19 - 1.2
@@ -53,31 +53,11 @@
*/
package org.apache.commons.math.stat.univariate.moment;
-import org
-.apache
-.commons
-.math
-.stat
-.univariate
-.AbstractStorelessUnivariateStatistic;
-
/**
* @author Mark Diggory
*
*/
-public class FourthMoment extends AbstractStorelessUnivariateStatistic {
-
-/** count of values that have been added */
-protected int n = 0;
-
-/** first moment of values that have been added */
-protected double m1 = Double.NaN;
-
-/** second moment of values that have been added */
-protected double m2 = Double.NaN;
-
-/** third moment of values that have been added */
-protected double m3 = Double.NaN;
+public class FourthMoment extends ThirdMoment {
/** fourth moment of values that have been added */
protected double m4 = Double.NaN;
@@ -122,11 +102,11 @@
}
/**
-* @see
org.apache.commons.math.stat.univariate.AbstractStorelessUnivariateStatistic#internalClear()
-*/
-protected void internalClear() {
-n = 0;
-m1 = m2 = m3 = m4 = Double.NaN;
+ * @see
org.apache.commons.math.stat.univariate.StorelessUnivariateStatistic#clear()
+ */
+public void clear() {
+super.clear();
+m4 = Double.NaN;
}
}
1.2 +25 -11
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/moment/GeometricMean.java
Index: GeometricMean.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/moment/GeometricMean.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- GeometricMean.java5 Jul 2003 18:23:51 - 1.1
+++ GeometricMean.java7 Jul 2003 02:15:19 - 1.2
@@ -53,40 +53,54 @@
*/
package org.apache.commons.math.stat.univariate.moment;
+import org.apache.commons.math.stat.univariate.AbstractStorelessUnivariateStatistic;
import org.apache.commons.math.stat.univariate.summary.SumOfLogs;
/**
* @author Mark Diggory
*
*/
-public class GeometricMean extends SumOfLogs {
+public class GeometricMean extends AbstractStorelessUnivariateStatistic {
-protected double geomean = Double.NaN;
+private SumOfLogs sumLog = new SumOfLogs();
-protected int n = 0;
+private double value = Double.NaN;
+
+private int n = 0;
/**
* @see
org.apache.commons.math.stat.univariate.StorelessUnivariateStatistic#increment(double)
*/
public double increment(double d) {
n++;
-super.increment(d);
-geomean = Math.exp( sumLog / (double)n );
-return geomean;
+sumLog.increment(d);
+value = Math.exp( sumLog.increment(d) / (double)n );
+return value;
}
/**
* @see
org.apache.commons.math.stat.univariate.StorelessUnivariateStatistic#getValue()
*/
public double getValue() {
-return geomean;
+return value;
}
/**
-* @see
Re: [math] Recent commits to stat, util packages
Thank you Phil for the code, I've finished adding the StatUtil
strategies to the evaluation methods of the new classes I've been
working on. The Timings are once again comparable for both packages. As
they should be, since the code is the same for these approaches.
Mean (old=StatUtils, new=Mean class)
old: 3505new: 2534
old: 3395new: 2513
old: 3385new: 2514
old: 3385new: 2513
old: 3405new: 2504
old: 3395new: 2503
old: 3405new: 2504
old: 3405new: 2513
old: 3385new: 2524
old: 3385new: 2523
old: mean=3405.0 std=36.20926830400073
new: mean=2514.5 std=10.013879257199855
Variance (old=StatUtils, new=Variance class)
old: 38265new: 40168
old: 38235new: 40038
old: 38235new: 40037
old: 38255new: 40098
old: 38305new: 40098
old: 38275new: 40147
old: 38285new: 40068
old: 38185new: 39977
old: 38205new: 39978
old: 38185new: 39977
old: mean=38243.0 std=41.57990967870072
new: mean=40058.6 std=69.6661881961239
I've also added test that exec the same set of values and results on
both evaluation and incremental methods to show that both approaches
return equal results within a tolerance of 10E-12 for the provided dataset.
-Mark
Phil Steitz wrote:
Sorry, last reply got sent before I was done with it. Pls disregard and try
this
This adds
significant overhead and I do not see the value in it. The cost of the
additional stack operations/object creations is significant. I ran tests
comparing the previous version that does direct computations using the
double[]
arrays to the modified version and found an average of more than 6x
slowdown
using the new implementation. I did not profile memory utilization, but
that is
also a concern. Repeated tests computing the mean of a 1000 doubles 10
times using the old and new implementations averaged 1.5 and 10.2 seconds,
resp. I do not see the need for all of this additional overhead.
If you review the code, you'll find there is no added object creation,
the static Variable objects calculate on double[] just as the
Univariates did, I would have to see more substantial analysis to
believe your claim. All thats going on here are that the Static StatUtil
methods are delegating to individual static instances of
UnivariateStatistics. These are instantiated on JVM startup like all
static objects, calling a method in such an object should not require
any more overhead than having the method coded directly into the static
method.
If there are performance considerations, lets discuss these.
Here is what I added to StatUtils.test
double[] x = new double[1000];
for (int i = 0; i 1000; i++) {
x[i] = (5 - i) * (i - 200);
}
long startTick = 0;
double res = 0;
for (int j = 0; j 10; j++) {
startTick = System.currentTimeMillis();
for (int i = 0; i 10; i++) {
res = OStatUtils.mean(x);
}
System.out.println(old: + (System.currentTimeMillis() - startTick));
startTick = System.currentTimeMillis();
for (int i = 0; i 10; i++) {
res = StatUtils.mean(x);
}
System.out.println(new: + (System.currentTimeMillis() - startTick));
The result was a mean of 10203 for the new and 1531.1 for the old, with
standard deviations 81.1 and 13.4 resp. The overhead is the stack operations
and temp object creations.
I doubt (as the numerous discussions over the past week have pointed
out) that what we really want to have in StatUtils is one monolithic
Static class with all the implemented methods present in it. If I have
misinterpreted this opinion in the group, then I'm sure there will be
responses to this.
Well, I for one would prefer to have the simple computational methods in one
place. I would support making the class require instantiation, however, i.e.
making the methods non-static.
There was a great deal of discussion about the benefit of not having the
methods implemented directly in static StatUtils because they could not
be overridden or worked with in an Instantiable form. This approach
frees the implementations up to be overridden and frees up room for
alternate implementations.
As I said above, the simplest way to deal with this is to make the methods
non-static.
You may have your opinions of how you would like to see the packages
organized and implemented. Others in the group do have alternate
opinions to yours. I for one see a strong value in individually
implemented Statistics. I also have a strong vision that the framework I
have been working on provides substantial benefits.
(1a.) It Allows both the storageless and storage based implementations
to function behind the same interface. No matter if your calling
increment(double d)
or
evaluate(double[]...)
your working with the same algorithm.
That is true in the old implementation as well, with the core computational
methods in StatUtils.
(1b.) If you wish to have alternate implementations for evaluate and
increment, it is easily possible of overload
Re: [math] Recent commits to stat, util packages
--- Mark R. Diggory [EMAIL PROTECTED] wrote: Well, I for one would prefer to have the simple computational methods in one place. I would support making the class require instantiation, however, i.e. making the methods non-static. Yes, but again is a question of having big flat monolithic classes vs having extensible implementations that can easily be expanded on. I'm not particularly thrilled at the idea of being totally locked into such an interface like Univariate or StatUtils. It is just totally inflexible and there always too much restriction and argument about what do we want to put in it vs, not put in it. I think that it is a good idea to have these discussions and I don't understand what you mean by inflexible. In retrospect, we probably should have named StoreUnivariate ExtendedUnivariate, since it really represents a statistical object supporting more statistics. Univariate can always be extended -- statistics can be added to the base interface as well as to the abstract and concrete classes that implement the base interface. Some of these statistics can be based on computational methods in StatUtils. If we eliminate the static methods in StatUtils, then we can make the computational strategies pluggable. One more sort of philosphical point that makes me want to keep Univariates as objects with statistics as properties: to me a Univariate is in fact a java bean. It's state is the data that it is characterizing and its properties are the statistics describing these data. Univariates that support only a limited set of statistics don't have to hold all of the individual data values comprising their state internally. Extended Univariates require more overhead. It is natural, therefore, to define the extended statistics in an extended interface. Yes, simple, but not very organized, and not as extensible as a framework like solvers is. You can implement any new solver we could desire right now without much complaint, but try to implement a new statistic and blam, all this argument starts up as to whether its appropriate or not in the Univariate interface. You are confusing strategies with implementations. The rootfinding framework exists to support multiple strategies to do rootfinding, not to support arbitrary numerical methods. A better analogy would be to the distribution framework which supports creation of different probability distributions. You could argue that a statistic is as natural an abstraction as a probability distribution. I disagree with that. There is lots of structure in a probability distribution, very little in a statistic from an abstract standpoint. There's not room for growth here! If I decide to go down the road an try to implement things like auto-correlation coefficients (which would be a logical addition someday) then I end up having to get permission just to add the implementation, whereas if there's a logical framework, theres more room for growth without stepping on each others toes so much. This is very logical to me. I disagree. Extending a class or adding a method to an interface is no harder than adding a new class (actually easier). It seems ridiculous to me to add a new class for each univariate statistic that we want to support. If the stats are going to be meaningfully integrated, they will have to be used/defined by the core univariate classes any way, unless your idea is to eliminate these and force users think about statistics one at a time instead of as part of a univariate statistical summary. This may be the crux of our disagreement. I see the statistics as natural properties of a set of data, not meaningful objects in their own right. We are always going to have to discuss what goes in to commons-math and what does not go in, regardless of how packages are organized. For example, I would be opposed (as I suspect J, Al and Brent would be too) to adding a Newton's method solver now, since it would provide no value beyond what we already have. This has nothing to do with how the package is organized. I would like to propose the following compromise solution that allows the kind of flexibility that you want without breaking things apart as much. 1. Rename StoreUnivariate to ExtendedUnivariate and change all other Store names to Extended. 2. Make the methods in StatUtils non-static. Continue to use these for basic computational methods shared by Univariate and ExtendedUnivariate implementations and for direct use by applications and elsewhere in commons-math. These methods do not have to be used by all Univariate implementation strategies. 3. Add addValues methods to Univariate that accept double[], List and Collection with property name and eliminate ListUnivariate and BeanListUnivariate. 4. Rename UnivariateImpl to SimpleUnivariate and add a UnivariateFactory with factory methods to create Simple, Extended and whatever other sorts of Univariates we may define. To add
Re: [DBCP] should Connection.close() render associated Statement objects unusable.
--- John McNally [EMAIL PROTECTED] wrote: I think that currently an application could call Connection.close() while retaining a reference to a Statement object and continue using it. The specification does not require Connection.close() to call Statement.close on any associated Statement(s). Is there a use case for closing a Connection while expecting a Statement to remain active? Closing a Connection should *always* close the resources obtained from that Connection including Statements and ResultSets. It would be highly confusing to implement it any other way. Imagine calling Statement.getConnection() to generate another Statement and receiving an SQLException because the Connection is closed. That's completely nonsensical. The general principal when developing a jdbc compliant pool is that the application should experience similar behavior whether a Connection came from a pool or not. I would expect that if a Connection was actually physically closed that operations on its Statement(s) or ResultSets to fail. Would anyone counter that expectation? This situation would appear to be the opposite of the abandoned connection problem, where helping a badly coded application would be straightforward and receiving an sql exception after calling ResultSet.next() on a closed Connection would be preferrable to having multiple threads continuing to use ResultSets while the Connection keeps getting returned to the pool. A related question: I have never found a reason to keep multiple Statements on a single Connection open. The spec states that only a single ResultSet can be open on a Statement at a time and that multiple Statements should be used if multiple open ResultSets are required. Should this be interpreted to mean multiple open Statements per Connection are allowed? Multiple open Statements per Connection are allowed. David john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] cpdsadapter needs a Statement implementation
--- John McNally [EMAIL PROTECTED] wrote: I recently noticed that the cpdsadapter package needs to be fixed wrt the Statement.getConnection() method. It will currently return the underlying physical Connection object as opposed to the logical Connection which was used to create the Statement. Can you explain the uses of the cpdsadapter classes? Having multiple implementations like this seems counter productive. When first writing cpdsapapter, I determined that using DelegatingConnection was not possible as it allowed reopening of a closed Connection. The code in jdbc2pool and cpdsadapter attempts to be fully jdbc2 (or later) compliant and the specification requires that a Connection object be unusable after close() is called. Now cpdsadapter needs a Statement implementation which will require a ResultSet implementation. Taking another look at DelegatingConnection, it could be used as the base class for a jdbc2 compliant Connection as long as the child class creates a no-op for the activate method. Does anyone see a problem with that approach? The only problem I have with going that route is the situation regarding the abandoned connection code. I thought it was already agreed that this code would be removed many months ago, but I am seeing revived debate and the possibility of retaining some of the code for possible logging. The abandoned related code will be removed and any logging will be new code. David john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] cpdsadapter needs a Statement implementation
On the subject of logging, are there any plans to implement SQL traces? I have a hacked copy of dbcp which I used to help track down a deadlock. If there's any interest, I'll clean it up and submit it. Regards, Tim -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, 7 July 2003 1:51 PM To: Jakarta Commons Developers List Subject: Re: [DBCP] cpdsadapter needs a Statement implementation --- John McNally [EMAIL PROTECTED] wrote: I recently noticed that the cpdsadapter package needs to be fixed wrt the Statement.getConnection() method. It will currently return the underlying physical Connection object as opposed to the logical Connection which was used to create the Statement. Can you explain the uses of the cpdsadapter classes? Having multiple implementations like this seems counter productive. When first writing cpdsapapter, I determined that using DelegatingConnection was not possible as it allowed reopening of a closed Connection. The code in jdbc2pool and cpdsadapter attempts to be fully jdbc2 (or later) compliant and the specification requires that a Connection object be unusable after close() is called. Now cpdsadapter needs a Statement implementation which will require a ResultSet implementation. Taking another look at DelegatingConnection, it could be used as the base class for a jdbc2 compliant Connection as long as the child class creates a no-op for the activate method. Does anyone see a problem with that approach? The only problem I have with going that route is the situation regarding the abandoned connection code. I thought it was already agreed that this code would be removed many months ago, but I am seeing revived debate and the possibility of retaining some of the code for possible logging. The abandoned related code will be removed and any logging will be new code. David john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.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] Recent commits to stat, util packages
Then we're back to dependency issues where now theres another interface that is restrictive and difficult to expand upon easily, it will be hard to add things to the library because everyone will be arguing about what should/shouldn't be in interface, uughh. :-( I am becoming more and more against having these generic Univariate interfaces where a particular statistic is embodied in a method. every time someone comes up with a new method there will be debate about should it be in the interface or not. Instead of just being an additional class that can be added to the package. This is the benefit of a framework over monolithic interfaces. Preach on brother Mark. I too would argue that the Univariate interfaces need to change and take on more of the look and feel provided by Mark and his statistic objects. One reason for this is flexibility. By forcing Univariate to determine the statistics it can compute we limit users as to when they can use Univariate's features of window and storageless computation. That is to say, a user only gets the benefit of those features iff the statistics they need computed are defined by the interface. Granted, we've taken some effort to include the most commonly used statistics in the interface, but others remain that the user might have a need for but can't leverage Univariate to compute them. By using statistic objects, like those supplied by Mark, and some way to supply those object data via the Univariate objects we can eliminate that limitation of the current design. Another reason for this is performance. The storageless Univariate implementation is a compute all or nothing design. Because of this, every time a new statistic is added to the interface, the extra computation needed to compute the new statistic slows down the computation of the existing statistics. With the current design, if a new statistic is added, all current users of Univariate in adversely effected, in terms of performance, by the change even though they don't rely on the new statistic. For instance, add Mark's auto-correlation coefficients and all of a sudden all existing test statistics using Univariate have gotten slower. That is a clear sign of bad design. Still another reason is maintenance. With every new statistic added to Univariate, besides the method added to support the statistic, numerous other methods need to change to support the computation, most notably addValue. Each addition of a statistic will make that method more complex which in turn makes it harder to debug, harder to change, and harder to understand. Also, with changing existing, working code, one runs the risk of introducing errors where none previously existed. It would royally bite, once we added auto-correlation coefficients again and then have variance no longer work. In comparison, it's impossible to break existing code by adding new code that isn't dependent on anything else, such as the case with Marks statistic objects. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] cpdsadapter needs a Statement implementation
Tim Anderson wrote: On the subject of logging, are there any plans to implement SQL traces? I have a hacked copy of dbcp which I used to help track down a deadlock. If there's any interest, I'll clean it up and submit it. I think the sense moving forward is that DBCP will remain only a pooling implementation, and leave other responsibilities to other libraries. The open source mac-daddy of SQL tracing is at www.p6spy.com. Great for tracking deadlocks and slow spots. There's even a recent add-on that will analyze all the SQL tracing and suggest indexes for tables. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math][collections] Customized Primitive Collections
snip/ rolling could be implemented using a version of CircularFifoBuffer which could accept double primitives. It would be important to gauge the Readiness of the o.a.c.collections.primitives classes. Is there an sense of a timeline for the next collections release? Until we get an answer to that, I'd recommend that commons-math not add a dependency to the SNAPSHOT for collections. Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Recent commits to stat, util packages
snip/ (I do a lot of snipping, don't I? Save the ASF bandwidth money, and snip liberally.) The statistic objects strike me as being very flexible, and I do agree with Brent's assessment that the storageless Univariate implementation was an all or nothing affair. Mark, how do you propose to integrate these functor-esque objects with the existing Univariate implementations? Also, can we now discuss dropping author tags? Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] author tags was Re: recent commits to stat, util packages
Also, can we now discuss dropping author tags? +1 for me at least -- i.e., I am OK dropping all of my @author tags. Phil __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] cpdsadapter needs a Statement implementation
On Sun, 2003-07-06 at 20:51, David Graham wrote: --- John McNally [EMAIL PROTECTED] wrote: I recently noticed that the cpdsadapter package needs to be fixed wrt the Statement.getConnection() method. It will currently return the underlying physical Connection object as opposed to the logical Connection which was used to create the Statement. Can you explain the uses of the cpdsadapter classes? Having multiple implementations like this seems counter productive. In jdbc2+, a connection pool would not normally wrap a DataSource or Driver. The specification is written so that vendors supply a ConnectionPoolDataSource (CPDS) which would normally be used by a pooling DataSource. Jdbc2PoolDataSource is written to use a CPDS. I created DriverAdapterCPDS, so that it can still be used with jdbc implementations that do not yet implement the newer specification. The jdbc2 specification for a Connection object returned by CPDS.getPooledConnection().getConnection() is that it should always return a new object, only one should be open at any given time, and after Connection.close() is called that object is no longer usable. john mcnally john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Recent commits to stat, util packages
Ok, my next email will be much shorter than this (I promise I'll start snip/ing). Phil Steitz wrote: --- Mark R. Diggory [EMAIL PROTECTED] wrote: Well, I for one would prefer to have the simple computational methods in one place. I would support making the class require instantiation, however, i.e. making the methods non-static. Yes, but again is a question of having big flat monolithic classes vs having extensible implementations that can easily be expanded on. I'm not particularly thrilled at the idea of being totally locked into such an interface like Univariate or StatUtils. It is just totally inflexible and there always too much restriction and argument about what do we want to put in it vs, not put in it. I think that it is a good idea to have these discussions and I don't understand what you mean by inflexible. Inflexability in that a well designed interface doesn't really need to grow or change over time, with an interface that can grows as the project grows, theres always going to be ALOT of growing pains (between developers, and in terms of orgaization of the code). In retrospect, we probably should have named StoreUnivariate ExtendedUnivariate, since it really represents a statistical object supporting more statistics. Univariate can always be extended -- This is the problem, every time we implement another stat are we going to Extend Univariate and create a whole new set of implementations just to support that stat. statistics can be added to the base interface as well as to the abstract and concrete classes that implement the base interface. Some of these statistics can be based on computational methods in StatUtils. If we eliminate the static methods in StatUtils, then we can make the computational strategies pluggable. This was my whole intention with the separate statistics. These eliminate the need to delegate to the static StatUtils and provide both plugability and individual implementations, as such establishing an organized library with room for growth. If you want to use an individual implementation you can, if you want to use a facade, you can. The facades just delegate to the individual stats in the same fashion we currently have UnivariateImpl delegating to StatUtils. One more sort of philosphical point that makes me want to keep Univariates as objects with statistics as properties: to me a Univariate is in fact a java bean. It's state is the data that it is characterizing and its properties are the statistics describing these data. And this will still be the case, I'm just modularizing the Statistical Implementations so there's more room for alternate implmentation and alternate usage. Univariates that support only a limited set of statistics don't have to hold all of the individual data values comprising their state internally. Extended Univariates require more overhead. It is natural, therefore, to define the extended statistics in an extended interface. Yes, simple, but not very organized, and not as extensible as a framework like solvers is. You can implement any new solver we could desire right now without much complaint, but try to implement a new statistic and blam, all this argument starts up as to whether its appropriate or not in the Univariate interface. You are confusing strategies with implementations. The rootfinding framework exists to support multiple strategies to do rootfinding, not to support arbitrary numerical methods. A better analogy would be to the distribution framework which supports creation of different probability distributions. You could argue that a statistic is as natural an abstraction as a probability distribution. I disagree with that. There is lots of structure in a probability distribution, very little in a statistic from an abstract standpoint. Ok, I do like your analogy better. And I agree that a statistic does not have as much structure as a probability distribution. But I disagree that this is grounds for not approaching my strategy. There's not room for growth here! If I decide to go down the road an try to implement things like auto-correlation coefficients (which would be a logical addition someday) then I end up having to get permission just to add the implementation, whereas if there's a logical framework, theres more room for growth without stepping on each others toes so much. This is very logical to me. I disagree. Extending a class or adding a method to an interface is no harder than adding a new class (actually easier). It seems ridiculous to me to add a new class for each univariate statistic that we want to support. So far any time the Univariate interface is modified, it usually results in a disagreement from someone that the change was not appropriate, usually this is based on opinion and not the functional capabilities of the particular method. This is not easily extendable because any new experimental development is in a constant battle with the
Re: [math] Recent commits to stat, util packages
Tim O'Brien wrote: snip/ (I do a lot of snipping, don't I? Save the ASF bandwidth money, and snip liberally.) The statistic objects strike me as being very flexible, and I do agree with Brent's assessment that the storageless Univariate implementation was an all or nothing affair. Mark, how do you propose to integrate these functor-esque objects with the existing Univariate implementations? One approach is shown in my last attachments. These delegate to these Statistic methods as internal objects in the AbstractUnivariate and AbstractStoreUnivariate. Also, can we now discuss dropping author tags? What is your concern? Did I leave some out? Or are you suggesting we drop them altogether? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math][collections] Customized Primitive Collections
Tim O'Brien wrote: snip/ rolling could be implemented using a version of CircularFifoBuffer which could accept double primitives. It would be important to gauge the Readiness of the o.a.c.collections.primitives classes. Is there an sense of a timeline for the next collections release? This is a good point we should discuss readiness with the collections crew. Note, I think Rodney Wandhoff has handled the primitive collection development so he is probably the most knowledgeable source for its status. Until we get an answer to that, I'd recommend that commons-math not add a dependency to the SNAPSHOT for collections. I changed to the snapshot so we could at least experiment with them. We should be careful about using these dependencies. I have not, as of yet started to use them. Note that in Maven, dependency on a SNAPSHOT during development is resolved to a version on release of a distribution of your project. You can set dependencies as SNAPSHOTs because the snapshots are just soft links to a fully numbered version in the maven repository (this can be a full release or a dated build). When you release, the SNAPSHOT is resolved to the existing repository version. So your assured of having the jar you developed against available in the future for download. Also note that many Commons and Jakarta projects have released with dependencies on dated jars, though I do recognize its also good to release with dependencies on solid versions as they stick around longer and tend to be more stable (in theory). -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] cpdsadapter needs a Statement implementation
Very cool - thanks for the link. -Original Message- From: Serge Knystautas [mailto:[EMAIL PROTECTED] Sent: Monday, 7 July 2003 2:31 PM To: Jakarta Commons Developers List Subject: Re: [DBCP] cpdsadapter needs a Statement implementation Tim Anderson wrote: On the subject of logging, are there any plans to implement SQL traces? I have a hacked copy of dbcp which I used to help track down a deadlock. If there's any interest, I'll clean it up and submit it. I think the sense moving forward is that DBCP will remain only a pooling implementation, and leave other responsibilities to other libraries. The open source mac-daddy of SQL tracing is at www.p6spy.com. Great for tracking deadlocks and slow spots. There's even a recent add-on that will analyze all the SQL tracing and suggest indexes for tables. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [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: cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestAuthenticator.java TestHttpState.java TestHttps.java TestMethodsExternalHost.java TestWebappBasicAuth.java
-Original Message- From: Christopher Lenz [mailto:[EMAIL PROTECTED] Sent: 06 July 2003 13:46 To: Commons HttpClient Project Subject: Re: cvs commit: jakarta- commons/httpclient/src/test/org/apache/commons/httpclient TestAuthenticator.java TestHttpState.java TestHttps.java TestMethodsExternalHost.java TestWebappBasicAuth.java Oleg, Oleg Kalnichevski wrote: It was an unfortunate oversight. The method should have been deprecated along with all other methods whose functionality is now provided by CookieSpec classes. I apologise for that. That's what I thought. Please remember to add the @deprecate tag to the 2_0 branch, so that others don't suffer from this oversight. We will no longer be able to provide API compatibility with 2.0 branch in CVS HEAD. We have to start fixing things that are broken by design Sigh. I hope you're not serious about this. I understand that you need to change stuff, and maybe a lot of stuff. Still, you need to *evolve* the API[1], implying that you should maintain API compatibility with the 2.0 release. Now, I can live with deprecated methods being removed inbetween point releases (usually they live a bit longer). The methods were deprecated, and we're not using them anymore. I absolutely cannot silently accept this announcement that API compatibility is not going to be maintained. HttpClient has already been forked in the past[2] for this reason. Now that HttpClient is a healthier and also pretty successful project, the team should pay utmost attention to not breaking its clients. If changes are necessary, deprecate first and find a good way to evolve the API without breaking it. That can be challenging, but it's usually worth the effort. Strong +1 Please do not break compatibility at once, go through a deprecation mechanism. Thanks -Vincent 2.0 is almost done. We foresee only minor documentation changes in the future. The code will not be touched unless something _really_ bad pops up. Please use official 2.0.x builds. We will continue to use both: the official releases of the 2.0 branch (and hopefully soon a 2.0 final), as well as CVS HEAD. The latter is done because we want to detect potential problems with our usage of HttpClient as early as possible. Obviously, that will make it easier for us to switch to 2.1 (for example) when it's released, but more importantly, we can give feedback to the HttpClient team when stuff changes that we're not happy with. Oh wait, there's a Jakarta project about this: http://jakarta.apache.org/gump/ -chris [1] http://eclipse.org/eclipse/development/java-api-evolution.html [2] http://cvs.apache.org/viewcvs.cgi/jakarta- slide/src/webdav/client/src/org/apache/commons/httpclient/ -- Christopher Lenz /=/ cmlenz at gmx.de - To unsubscribe, e-mail: commons-httpclient-dev- [EMAIL PROTECTED] For additional commands, e-mail: commons-httpclient-dev- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestAuthenticator.java TestHttpState.java TestHttps.java TestMethodsExternalHost.java TestWebappBasicAuth.java
Just a few comments. The current plans for 2.1 are fairly modest and most of the changes can be made with little or no API modifications. The exceptions are: Taken from http://cvs.apache.org/viewcvs/jakarta-commons/httpclient/ RELEASE_PLAN_2_1.txt?rev=1.1content-type=text/vnd.viewcvs-markup - Removal of functions classes deprecated in 2.0. This one is obvious and I think we can agree this is okay. The one exception is the oversight in Cookie.parse() but that will be fixed. -Better exception handling framework (Bug #19868). This one is being debated now. I think this change can be done without API problems, though that is perhaps not the cleanest option. - Cross-site redirect fix. Authentication, redirect retry logic to be moved from HttpMethodBase to HttpClient (Bug #20089, #16729). This is the big one. This fix is the most requested and the most useful I think. This change does not effect method signatures but it does change current Method behavior. My feeling is that we should make all possible efforts to keep API compatibility. I do not think this is our highest priority though. When it comes between adding 2.1 functionality and API compatibility I think we should choose 2.1 functionality. I think we need to weigh the added benefit to users of new functionality against the burden of not having the functionality because of API compatibility. Perhaps this debate should occur on a case by case basis. In doing so I think it is quite possible we will come up with a solution for each case that is satisfactory to both sides. Mike On Sunday, July 6, 2003, at 07:46 AM, Christopher Lenz wrote: Oleg, Oleg Kalnichevski wrote: It was an unfortunate oversight. The method should have been deprecated along with all other methods whose functionality is now provided by CookieSpec classes. I apologise for that. That's what I thought. Please remember to add the @deprecate tag to the 2_0 branch, so that others don't suffer from this oversight. We will no longer be able to provide API compatibility with 2.0 branch in CVS HEAD. We have to start fixing things that are broken by design Sigh. I hope you're not serious about this. I understand that you need to change stuff, and maybe a lot of stuff. Still, you need to *evolve* the API[1], implying that you should maintain API compatibility with the 2.0 release. Now, I can live with deprecated methods being removed inbetween point releases (usually they live a bit longer). The methods were deprecated, and we're not using them anymore. I absolutely cannot silently accept this announcement that API compatibility is not going to be maintained. HttpClient has already been forked in the past[2] for this reason. Now that HttpClient is a healthier and also pretty successful project, the team should pay utmost attention to not breaking its clients. If changes are necessary, deprecate first and find a good way to evolve the API without breaking it. That can be challenging, but it's usually worth the effort. 2.0 is almost done. We foresee only minor documentation changes in the future. The code will not be touched unless something _really_ bad pops up. Please use official 2.0.x builds. We will continue to use both: the official releases of the 2.0 branch (and hopefully soon a 2.0 final), as well as CVS HEAD. The latter is done because we want to detect potential problems with our usage of HttpClient as early as possible. Obviously, that will make it easier for us to switch to 2.1 (for example) when it's released, but more importantly, we can give feedback to the HttpClient team when stuff changes that we're not happy with. Oh wait, there's a Jakarta project about this: http://jakarta.apache.org/gump/ -chris [1] http://eclipse.org/eclipse/development/java-api-evolution.html [2] http://cvs.apache.org/viewcvs.cgi/jakarta-slide/src/webdav/client/src/ org/apache/commons/httpclient/ -- Christopher Lenz /=/ cmlenz at gmx.de - 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: cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestAuthenticator.java TestHttpState.java TestHttps.java TestMethodsExternalHost.java TestWebappBasicAuth.java
Thanks Michael for you answer. Cactus is being built using Gump every day so whenever something breaks in HttpClient, be sure we'll be there to help prevent any incompatibility :-) We always try to follow the deprecation hints and upgrade as we go. What is bad it when it breaks suddenly, which is what we would like to avoid. This happened yesterday with the parse() method but I understand this was a mistake and not something wanted... :-) Thanks -Vincent -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: 06 July 2003 20:28 To: Commons HttpClient Project Subject: Re: cvs commit: jakarta- commons/httpclient/src/test/org/apache/commons/httpclient TestAuthenticator.java TestHttpState.java TestHttps.java TestMethodsExternalHost.java TestWebappBasicAuth.java Just a few comments. The current plans for 2.1 are fairly modest and most of the changes can be made with little or no API modifications. The exceptions are: Taken from http://cvs.apache.org/viewcvs/jakarta-commons/httpclient/ RELEASE_PLAN_2_1.txt?rev=1.1content-type=text/vnd.viewcvs-markup - Removal of functions classes deprecated in 2.0. This one is obvious and I think we can agree this is okay. The one exception is the oversight in Cookie.parse() but that will be fixed. -Better exception handling framework (Bug #19868). This one is being debated now. I think this change can be done without API problems, though that is perhaps not the cleanest option. - Cross-site redirect fix. Authentication, redirect retry logic to be moved from HttpMethodBase to HttpClient (Bug #20089, #16729). This is the big one. This fix is the most requested and the most useful I think. This change does not effect method signatures but it does change current Method behavior. My feeling is that we should make all possible efforts to keep API compatibility. I do not think this is our highest priority though. When it comes between adding 2.1 functionality and API compatibility I think we should choose 2.1 functionality. I think we need to weigh the added benefit to users of new functionality against the burden of not having the functionality because of API compatibility. Perhaps this debate should occur on a case by case basis. In doing so I think it is quite possible we will come up with a solution for each case that is satisfactory to both sides. Mike On Sunday, July 6, 2003, at 07:46 AM, Christopher Lenz wrote: Oleg, Oleg Kalnichevski wrote: It was an unfortunate oversight. The method should have been deprecated along with all other methods whose functionality is now provided by CookieSpec classes. I apologise for that. That's what I thought. Please remember to add the @deprecate tag to the 2_0 branch, so that others don't suffer from this oversight. We will no longer be able to provide API compatibility with 2.0 branch in CVS HEAD. We have to start fixing things that are broken by design Sigh. I hope you're not serious about this. I understand that you need to change stuff, and maybe a lot of stuff. Still, you need to *evolve* the API[1], implying that you should maintain API compatibility with the 2.0 release. Now, I can live with deprecated methods being removed inbetween point releases (usually they live a bit longer). The methods were deprecated, and we're not using them anymore. I absolutely cannot silently accept this announcement that API compatibility is not going to be maintained. HttpClient has already been forked in the past[2] for this reason. Now that HttpClient is a healthier and also pretty successful project, the team should pay utmost attention to not breaking its clients. If changes are necessary, deprecate first and find a good way to evolve the API without breaking it. That can be challenging, but it's usually worth the effort. 2.0 is almost done. We foresee only minor documentation changes in the future. The code will not be touched unless something _really_ bad pops up. Please use official 2.0.x builds. We will continue to use both: the official releases of the 2.0 branch (and hopefully soon a 2.0 final), as well as CVS HEAD. The latter is done because we want to detect potential problems with our usage of HttpClient as early as possible. Obviously, that will make it easier for us to switch to 2.1 (for example) when it's released, but more importantly, we can give feedback to the HttpClient team when stuff changes that we're not happy with. Oh wait, there's a Jakarta project about this: http://jakarta.apache.org/gump/ -chris [1] http://eclipse.org/eclipse/development/java-api-evolution.html [2] http://cvs.apache.org/viewcvs.cgi/jakarta-slide/src/webdav/client/src/ org/apache/commons/httpclient/ -- Christopher Lenz /=/ cmlenz at gmx.de
RE: cvscommit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclientTestAuthenticator.javaTestHttpState.javaTestHttps.java TestMethodsExternalHost.javaTestWebappBasicAuth.java
My 2 cents. It is ALWAYS possible to maintain binary compatibility. The downside is that it is ugly and gets unmaintainable over time and it occasionally forces you to create new classes or methods where you would have liked to have reuse the old name. Such is life. An acceptable compromise is to maintain deprecated methods and classes for a release or two and then remove them. Ralph -Original Message- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Sunday, July 06, 2003 2:33 PM To: Commons HttpClient Project Subject: RE: cvscommit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclientTestAut henticator.javaTestHttpState.javaTestHttps.java TestMethodsExternalHost.javaTestWebappBasicAuth.java Vincent, I have a feeling that you somehow suspect me of waking up this morning and thinking: Geez, I feel like screwing up those HttpClient APIs. Wouldn't that be fun?. Believe me, I am not THAT bad Please allow me to copy verbatim the paragraph from the release plan that I wrote: -- Objective: The objective of the 2.1 release of HttpClient is to build upon the foundation laid with the previous release while addressing those architectural shortcomings and flaws identified during 2.0 development process. Several well known and much complained about problems could not be resolved without sacrificing API stability. The primary motivation behind the 2.1 is to fix those design limitations, breaking 2.0 API compatibility where absolutely unavoidable, while preserving overall compatibility with 2.0 use patterns. -- Cmon, what else am I supposed to say to make you beleive? And of course, it just goes without saying that each and every patch will be discussed on this mailing list and committed only if there are enough confidence that it satisfies the above stated criteria. You are welcome to dispute the merits of each individual API breakage, but just demanding 100% compatibility with 2.0 release no matter what will effectively halt further development of HttpClient. Cheers Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvscommit: jakarta-commons/httpclient/src/test/org/apache/com mons/httpclientTestAuthenticator.javaTestHttpState.javaTestHttps.java Tes tMethodsExternalHost.javaTestWebappBasicAuth.java
On Monday, July 7, 2003, at 10:46 AM, Ralph Goers wrote: My 2 cents. It is ALWAYS possible to maintain binary compatibility. The downside is that it is ugly and gets unmaintainable over time and it occasionally forces you to create new classes or methods where you would have liked to have reuse the old name. Such is life. An acceptable compromise is to maintain deprecated methods and classes for a release or two and then remove them. Ralph We have spent a fair bit of time looking at ways to fix the problem without breaking API compatibility and I believe at one point someone even created a patch for one of the issues and it was voted down because it introduced far too much instability into HttpClient to make the preservation of the API worthwhile. This isn't a decision that we've taken lightly and if you're using HttpClient as we've always recommended (check the tutorial in particular) then I'd be very surprised if you noticed any change to the API. Really, we've spent a lot of time trying to come up with the best solution to these problems and I believe all the developers who've looked at the problem are in agreement that the only realistic way to fix them is to break API compatibility. If you want to spend the time to come up with a maintainable way to solve the problems and maintain API compatibility then by all means feel free. To summarize the biggest problem with the architecture at the moment: HttpClient (the class) creates a connection to the host and passes just the connection into the method being executed. The method then handles all the retry/authentication/etc logic and has absolutely no way to create a new connection since that's handled in HttpClient. Now, if we move the retry logic, we break API compatibility, if we move the creation of connections we break api compatibility. If we add a new method to HttpMethodBase which accepts a connection manager instead of just a connection and depreciate the old method everyone who would have run into the API change would still have to rewrite their code to use the new method, we still wouldn't have solved all the problems (recreating proxied SSL connections is still not possible), plus the depreciated methods would still have all the bugs that people have been complaining about and the architecture of HttpClient remains unworkable just waiting for the next problem to arise. At some point we need to move the retry logic out of the methods because it simply doesn't belong there, is very difficult to maintain there and has been causing a lot of problems. When we do that, we have two choices - maintain API compatibility but change the way the methods work (really bad since you won't get any warning that things have changed) or break API compatibility so you get a compile time error. We've chosen the latter. Note that through all of this, if you're using HttpClient like you should be (ie: actually going through the HttpClient class instead of calling execute on methods directly) you shouldn't see any change. Hopefully that helps people understand the reasoning behind the proposed changes even if it is a high-level handwaving kind of explanation. Regards, Adrian Sutton. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
