Re: [math] Tasks remaining for initial release
--- Phil Steitz [EMAIL PROTECTED] wrote: * RealMatrixImpl is missing one method implementation -- getRank(). The most accurate way to implement this would be to add Singular Value Decomposition and use this to compute effective numerical rank. If someone wants to volunteer to do this, we can leave this in; otherwise I suggest dropping the rank computation from the interface. +1 for dropping the rank computation. I'd guess most users won't miss it. * Rootfinding framework. We need to get this rectified or just decide to stay with the simple solution in place now. My vote would be to rectify J's framework. +1 for rectifying the Pietschmann framework. * Interpolation. Al is working on cubic spline interpolation. Right? Right. * Continued work on javadoc, checkstyle, and test coverage. We need to look at test data coverage as well as path coverage. In some cases, we have good path coverage, but we have not tested all of the data boundary conditions. +1 * Additional performance and accuracy testing. If anyone is interested in helping out here, what we could really use is a wider selection of test cases for the core numerical functions and validation against either other packages (e.g. R for the statistical stuff), verified datasets, or experiments comparing implementions using floats to doubles. * Additional code review. I am planning to review the current state of all of the code to verify that the code matches the documentation and to identify obvious inefficiencies or numerical problems. It would be a good idea for others to do the same. All feedback/suggestions for improvement are welcome -- especially if accompanied by patches :-) +1 for both the above. I suspect we may be in a test-and-fix phase for a while once we enter it. Al = Albert Davidson Chou Get answers to Mac questions at http://www.Mac-Mgrs.org/ . __ 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]
cvs commit: jakarta-commons/net/xdocs changes.xml
brekke 2003/06/23 05:47:39
Modified:net/src/java/org/apache/commons/net/telnet
TelnetInputStream.java
net/xdocs changes.xml
Log:
Another patch for a deadlock situation in TelnetInputStream.
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
1.7 +1 -1
jakarta-commons/net/src/java/org/apache/commons/net/telnet/TelnetInputStream.java
Index: TelnetInputStream.java
===
RCS file:
/home/cvs/jakarta-commons/net/src/java/org/apache/commons/net/telnet/TelnetInputStream.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- TelnetInputStream.java14 Apr 2003 12:53:34 - 1.6
+++ TelnetInputStream.java23 Jun 2003 12:47:39 - 1.7
@@ -492,7 +492,7 @@
__queue.notify();
try
{
-__queue.wait();
+__queue.wait(100);
}
catch (InterruptedException e)
{
1.10 +5 -0 jakarta-commons/net/xdocs/changes.xml
Index: changes.xml
===
RCS file: /home/cvs/jakarta-commons/net/xdocs/changes.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- changes.xml 18 May 2003 04:19:41 - 1.9
+++ changes.xml 23 Jun 2003 12:47:39 - 1.10
@@ -8,6 +8,11 @@
body
release version=1.0.1 date=In CVS
action dev=brekke type=fix
+If the buffer queue run full, the run() method sometimes hangs forever.
+Changed wait() to wait(100) as with other changes in TelnetInputStream.
+Fix submitted From: J. Matysiak ( [EMAIL PROTECTED] ).
+ /action
+ action dev=brekke type=fix
FTP.smnt(String dir) was not passing on the dir to the SMNT command as an
argument.
/action
action dev=brekke type=add
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] FileUpload 1.0 Final Release Plan
Hi all, I read a mail a while ago about the release candidate of fileupload that explain this release break tomcat!? Is it true? If yes, which version of tomcat are affected? As Debian maintainer of fileupload, I'd like to know if I have to tell Debian users if they have to upgrade tomcat (and which version) if they install Fileupload v1.0. Many thanks for your attention, Best regard, Arnaud. Martin Cooper [EMAIL PROTECTED] wrote: Release Candidate 1 of the Commons FileUpload component has proved to be stable, with no new showstopper issues reported since that release, and only minor documentation updates applied. Therefore, I propose that the tip of the main trunk in CVS be released as FileUpload 1.0 Final. I will act as the Release Manager. -- Arnaud Vandyck, STE fi, ULg Formateur Cellule Programmation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Tasks remaining for initial release
Phil Steitz wrote: Here are the remaining open tasks. I think we are getting close to the time when we can develop a release plan. I will submit a patch to Bugzilla updating tasks.xml, but I wanted to post the open tasks and my own short term plan. * RealMatrixImpl is missing one method implementation -- getRank(). The most accurate way to implement this would be to add Singular Value Decomposition and use this to compute effective numerical rank. If someone wants to volunteer to do this, we can leave this in; otherwise I suggest dropping the rank computation from the interface. * Write the User's guide. Now that the package structure is in place, I suggest that we structure the guide following the subpackages. I have started on the random and stat sections. I will submit a patch with the overview and all sections stubbed out tomorrow AM. I will work on sections in the following order: random, stat, linear, analysis, special, util, posting patches as I have drafts. If anyone else wants to start on any of these, please post patches/plans. One sort of dodgy issue related to this is the MathML dilemma. So far, I have been able to avoid the need for real math notation by using extra words, etc; but this is going to be a pain. I would like to either just use MathML (forcing users to download the free plugin if their browser does not support it) or use LaTex and the maven tex plugin (have not tried this, but it is advertised) or just generate pdf from the LaTex. In either case, I think that it is essential that we keep the source text in plain ASCII in CVS. The MathML approach is best, IMHO, because it just amounts to additional markup in the xdocs. * Rootfinding framework. We need to get this rectified or just decide to stay with the simple solution in place now. My vote would be to rectify J's framework. * Interpolation. Al is working on cubic spline interpolation. Right? * Extend distribution framework to support discrete distributions and implement binomial and hypergeometric distributions. Volunteers? I will do this if no one else wants to; but I will wait until the end of next week to start. * Continued work on javadoc, checkstyle, and test coverage. We need to look at test data coverage as well as path coverage. In some cases, we have good path coverage, but we have not tested all of the data boundary conditions. A good example is the problem that Al pointed out re: RealMatrixImpl dimension verification. * Additional performance and accuracy testing. If anyone is interested in helping out here, what we could really use is a wider selection of test cases for the core numerical functions and validation against either other packages (e.g. R for the statistical stuff), verified datasets, or experiments comparing implementions using floats to doubles. * Additional code review. I am planning to review the current state of all of the code to verify that the code matches the documentation and to identify obvious inefficiencies or numerical problems. It would be a good idea for others to do the same. All feedback/suggestions for improvement are welcome -- especially if accompanied by patches :-) * Finalize the contents of MathUtils and StatUtils. Now would be a good time to suggest any additions -- again, ideally with patches -- to these utility classes. Two more small items that I forgot to add to the list above: * Add confidence intervals for the mean. Originally, I proposed nonparametric bootstrap confidence intervals only for the StoredUnivariates; but I now think that it would be better to include t-based confidence intervals in Univariate. The interface and implementation could be similar to what is implemented as getSlopeConfidenceInterval() in RealMatrix -- getMeanConfidenceInterval returns the half-width of 95% t-based confidence interval for the mean, getMeanConfidenceInterval(alpha) returns the 100(1-alpha)% interval half-width. This can be easily implemented using the distribution framework (cf the RealMatrixImpl example and the t-test methods recently added to TestStatisticImpl). Bootstrap confidence intervals could also be added to StoredUnivariate, using the sampling methods in RandomDataImpl, if someone wants to do this. EmpiricalDistributionImpl could also be extended to support generation of bootstrap confidence intervals based on the distribution digest without storing the full set of values. * Add double[] |- double methods in StatUtils to take start and end array indexes as parameters and delegate the current full array versions to these. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Some issues with DoubleArrays
Tim O'Brien wrote: What about this possibility. we could easily have DoubleArray return a reference to the internalStorageArray. I know this would violate encapsulation, but if we expose the interal array, the start and end index then there is no need to copy the contents of the array. Instead we pass a reference to an existing array - aka, no need to copy our element array. +1 -- it *is* after all an array and if this is not exposed, you are always going to be stuck with using ArrayCopy to get at the underlying data, which makes efficient computation using large arrays impossible. I agonized over this same decision vis a vis RealMatrixImpl, where I ended up breaking encapsulation (similarly to other double[][]-based implementations) and exposing a getDataRef method that returns a reference to the underlying double[][] array. Now, every method that takes a double[] in StatUtil, would be altered to take a (double[], int start, int length). So, public static double sum(double[] values); would delegate to a more generic public static double sum(double[] values, int startIndex, int length); I agree -- I think that Brent suggested this improvement already. (2) Some of the methods in DoubleArray are questionable as they are statistical in nature and replicated in the Univariate Interface, specifically DoubleArray.getMin() and DoubleArray.getMax(), and I can't find anywhere that these ever actually get used, I recommend we remove these methods from the Interface and Implementations. 100% agreed. There is really no need to calulate min and max in these classes. It seems very redundant. I agree here as well. (3) Following our same philosophy of not having methods in the interface that can't be supported across all implementations, DoubleArray.discardFrontElements seems problematic as not all DoubleArrays may support it. I do understand the usage, requirement and need for this method. I wonder if there is some way to internalize the discarding or provide a more generic sort of DoubleArray.trim() method. Discarding really only comes into play when working with ContractableDoubleArrays, maybe it should be exposed at that level instead of in the interface. Any thoughts? I noticed this as well. It would make sense to remove method from the interface completely. +1 Phil -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] FileUpload 1.0 Final Release Plan
On Mon, 23 Jun 2003, Arnaud Vandyck wrote: Hi all, I read a mail a while ago about the release candidate of fileupload that explain this release break tomcat!? Some changes to FileUpload did break the *nightly* build of Tomcat, but a patch was provided and has been applied, so there is no longer a problem. Is it true? If yes, which version of tomcat are affected? You'll need to ask the Tomcat team about that, but I believe currently only the nightly builds of Tomcat 4.x and 5.x use the latest FileUpload. As Debian maintainer of fileupload, I'd like to know if I have to tell Debian users if they have to upgrade tomcat (and which version) if they install Fileupload v1.0. Tomcat bundles its own copy of FileUpload, as do several other projects, so that issues like this do not occur. If someone tried to *replace* the version bundled with an older version of Tomcat with FileUpload 1.0, that would cause a problem for the Tomcat apps that use it. However, using FileUpload 1.0 in your own apps running on top of Tomcat should not be a problem, since you will be the one writing to the FileUpload API. -- Martin Cooper Many thanks for your attention, Best regard, Arnaud. Martin Cooper [EMAIL PROTECTED] wrote: Release Candidate 1 of the Commons FileUpload component has proved to be stable, with no new showstopper issues reported since that release, and only minor documentation updates applied. Therefore, I propose that the tip of the main trunk in CVS be released as FileUpload 1.0 Final. I will act as the Release Manager. -- Arnaud Vandyck, STE fi, ULg Formateur Cellule Programmation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] NumberUtils minimum, maximum, and xor
I have a path and test for xor(boolean[]) that I will submit for BooleanUtils. I can also submit a patch for min and max with parameters short[], int[], long[], float[], and double[]. Would it make sense for this to go into lang.NumberUtils or a new class in lang.math? On Mon, 2003-06-23 at 02:08, [EMAIL PROTECTED] wrote: I disagree. lang.math exists for very simple, common maths operations. Min/max is a good example of this. It should be extended to all primitive types. A little duplication here is OK. (Note that a year ago I wouldn't have written this, but it makes more sense to me now) Adding min(int[]) etc is also probably a good idea. It may be best to rename the methods to min and max to be compatable with [math] (deprecating as needed). On the boolean question, we have a BooleanUtils to add xor() to. Do you have a patch/test available? Stephen from:Gary Gregory [EMAIL PROTECTED] If we want to be consistent, we could deprecate [lang]'s min/max and point to [math]. This would parallel nicely with c.lang for java.lang and c.math for java.math. It does not seem right to add all primitive types to c.lang.NumberUtils if min/max routines are in c.math. Gary -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Saturday, June 21, 2003 15:18 To: Jakarta Commons Developers List Subject: Re: [lang] NumberUtils minimum, maximum, and xor Just to note: we have moved somwhat along these lines in the the commons [math] sandbox component. Currently we have o.a.c.m.stat.StatUtils: double min(double[] doubleArr) double max(double[] doubleArr) available there. -Mark Diggory _matthewHawthorne wrote: I have 2 observations: (1) Currently, the following methods are in o.a.c.l.NumberUtils int maximum(int a, int b, int c) long maximum(long a, long b, long c) int minimum(int a, int b, int c) long minimum(long a, long b, long c) I think it be more flexible to replace them with the following: int minimum(int[] intArr) int maximum(int[] intArr) long minimum(long[] longArr) long maximum(long[] longArr) It also may be a good time to add any missing methods such as: short minimum(short[] shortArr) short maximum(short[] shortArr) float minimum(float[] floatArr) float maximum(float[] floatArr) double minimum(double[] doubleArr) double maximum(double[] doubleArr) Any thoughts? (2) After searching for an easy way to xor booleans, and not finding anything, I created a method: boolean xor(boolean[] boolArr) Would this be a good addition to NumberUtils? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21015] New: - [math] Update task list
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21015. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21015 [math] Update task list Summary: [math] Update task list Product: Commons Version: Nightly Builds Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Sandbox AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Attaching a patch updating tasks.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19331] - [lang] General case: infinite loop: ToStringBuilder.reflectionToString
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19331. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19331 [lang] General case: infinite loop: ToStringBuilder.reflectionToString --- Additional Comments From [EMAIL PROTECTED] 2003-06-23 16:21 --- This has been fixed in the nightly build for quite some time as I notice that this report is marked for version 1.0Alpha. Can you please check your case against a current build? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11092] - [patch] JDK 1.4.1 compil error / TestHashMap.java does not define makeEmptyMap() in org.apache.commons.collections.TestMap
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11092. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11092 [patch] JDK 1.4.1 compil error / TestHashMap.java does not define makeEmptyMap() in org.apache.commons.collections.TestMap --- Additional Comments From [EMAIL PROTECTED] 2003-06-23 16:49 --- Created an attachment (id=6938) This patch replaces creation of Boolean objects with references to TRUE and FALSE - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11092] - [patch] JDK 1.4.1 compil error / TestHashMap.java does not define makeEmptyMap() in org.apache.commons.collections.TestMap
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11092. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11092 [patch] JDK 1.4.1 compil error / TestHashMap.java does not define makeEmptyMap() in org.apache.commons.collections.TestMap --- Additional Comments From [EMAIL PROTECTED] 2003-06-23 16:52 --- Please ignore attachment (id=6938). It was attached to the wrong bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
Serge, I'm using DBCP in a production environment. It actually does support validation queries to detect whether a connection is bogus or not. You just need to call setValidationQuery() on the PoolableConnectionFactory, and enable testOnBorrow on the ObjectPool you pass to the DBCP init stuff. I can provide sample code if you'd like. But like David said earlier, DBCP is pretty much a dead project. It works well enough for my needs, but I'm not sure I'd integrate it into a project right now. On a related note, does anybody know what the status of PreparedStatement pooling is in the latest DBCP release? It seems broken to me, but I might be doing something wrong. -- Mark Lewis On Sun, 2003-06-22 at 19:06, Serge Knystautas wrote: Is anyone working on DBCP or planning another release anytime soon? It's been almost a year, and the project seems pretty inactive. I was trying to integrate DBCP into James this weekend to replace my home-rolled DB connection, and after the fact realized that DBCP cannot handle database restarts as without a validate SQL statement, DBCP doesn't realize connections are corrupt and keeps putting them back in the pool. Would anyone be interested in me supplying some patches to do some extra checking, get some examples and documentation straight (I found 3 or 4 different basic examples, none of which worked for me)? Are other Apache projects using DBCP at this point, and is it reasonable to remove methods that have not been implemented (like setLoginTimeout())? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21021] - [PATCH] reduce object creation in ToStringBuilder
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21021. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21021 [PATCH] reduce object creation in ToStringBuilder --- Additional Comments From [EMAIL PROTECTED] 2003-06-23 16:54 --- Created an attachment (id=6939) This patch replaces the creation of new Boolean objects with refererences to TRUE and FALSE - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/builder ToStringBuilder.java
ggregory2003/06/23 10:04:39
Modified:lang/src/java/org/apache/commons/lang/builder
ToStringBuilder.java
Log:
PR: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21021.
Reduce object creation in ToStringBuilder. Applied the patch in spirit but not in
detail since I used
BooleanUtils.toBooleanObject(fullDetail) instead of fullDetail ? Boolean.TRUE :
Boolean.FALSE
to reduce code duplication.
Revision ChangesPath
1.23 +13 -11
jakarta-commons/lang/src/java/org/apache/commons/lang/builder/ToStringBuilder.java
Index: ToStringBuilder.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/builder/ToStringBuilder.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- ToStringBuilder.java 3 Jun 2003 03:51:56 - 1.22
+++ ToStringBuilder.java 23 Jun 2003 17:04:39 - 1.23
@@ -53,6 +53,8 @@
*/
package org.apache.commons.lang.builder;
+import org.apache.commons.lang.BooleanUtils;
+
/**
* pBuilds codetoString()/code values./p
*
@@ -572,7 +574,7 @@
* @return this
*/
public ToStringBuilder append(String fieldName, boolean[] array, boolean
fullDetail) {
-style.append(buffer, fieldName, array, new Boolean(fullDetail));
+style.append(buffer, fieldName, array,
BooleanUtils.toBooleanObject(fullDetail));
return this;
}
@@ -618,7 +620,7 @@
* @return this
*/
public ToStringBuilder append(String fieldName, byte[] array, boolean
fullDetail) {
-style.append(buffer, fieldName, array, new Boolean(fullDetail));
+style.append(buffer, fieldName, array,
BooleanUtils.toBooleanObject(fullDetail));
return this;
}
@@ -664,7 +666,7 @@
* @return this
*/
public ToStringBuilder append(String fieldName, char[] array, boolean
fullDetail) {
-style.append(buffer, fieldName, array, new Boolean(fullDetail));
+style.append(buffer, fieldName, array,
BooleanUtils.toBooleanObject(fullDetail));
return this;
}
@@ -710,7 +712,7 @@
* @return this
*/
public ToStringBuilder append(String fieldName, double[] array, boolean
fullDetail) {
-style.append(buffer, fieldName, array, new Boolean(fullDetail));
+style.append(buffer, fieldName, array,
BooleanUtils.toBooleanObject(fullDetail));
return this;
}
@@ -756,7 +758,7 @@
* @return this
*/
public ToStringBuilder append(String fieldName, float[] array, boolean
fullDetail) {
-style.append(buffer, fieldName, array, new Boolean(fullDetail));
+style.append(buffer, fieldName, array,
BooleanUtils.toBooleanObject(fullDetail));
return this;
}
@@ -802,7 +804,7 @@
* @return this
*/
public ToStringBuilder append(String fieldName, int[] array, boolean
fullDetail) {
-style.append(buffer, fieldName, array, new Boolean(fullDetail));
+style.append(buffer, fieldName, array,
BooleanUtils.toBooleanObject(fullDetail));
return this;
}
@@ -848,7 +850,7 @@
* @return this
*/
public ToStringBuilder append(String fieldName, long[] array, boolean
fullDetail) {
-style.append(buffer, fieldName, array, new Boolean(fullDetail));
+style.append(buffer, fieldName, array,
BooleanUtils.toBooleanObject(fullDetail));
return this;
}
@@ -876,7 +878,7 @@
* @return this
*/
public ToStringBuilder append(String fieldName, Object object, boolean
fullDetail) {
-style.append(buffer, fieldName, object, new Boolean(fullDetail));
+style.append(buffer, fieldName, object,
BooleanUtils.toBooleanObject(fullDetail));
return this;
}
@@ -909,7 +911,7 @@
* @return this
*/
public ToStringBuilder append(String fieldName, Object[] array, boolean
fullDetail) {
-style.append(buffer, fieldName, array, new Boolean(fullDetail));
+style.append(buffer, fieldName, array,
BooleanUtils.toBooleanObject(fullDetail));
return this;
}
@@ -955,7 +957,7 @@
* @return this
*/
public ToStringBuilder append(String fieldName, short[] array, boolean
fullDetail) {
-style.append(buffer, fieldName, array, new Boolean(fullDetail));
+style.append(buffer, fieldName, array,
BooleanUtils.toBooleanObject(fullDetail));
return this;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21021] - [PATCH] reduce object creation in ToStringBuilder
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21021. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21021 [PATCH] reduce object creation in ToStringBuilder [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-06-23 17:07 --- Applied the patch in spirit but not in detail since I used BooleanUtils.toBooleanObject(fullDetail) instead of fullDetail ? Boolean.TRUE : Boolean.FALSE in order to reduce code duplication. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
On a related note, does anybody know what the status of PreparedStatement pooling is in the latest DBCP release? It seems broken to me, but I might be doing something wrong. It doesn't appear to be implemented yet. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18012 David -- Mark Lewis On Sun, 2003-06-22 at 19:06, Serge Knystautas wrote: Is anyone working on DBCP or planning another release anytime soon? It's been almost a year, and the project seems pretty inactive. I was trying to integrate DBCP into James this weekend to replace my home-rolled DB connection, and after the fact realized that DBCP cannot handle database restarts as without a validate SQL statement, DBCP doesn't realize connections are corrupt and keeps putting them back in the pool. Would anyone be interested in me supplying some patches to do some extra checking, get some examples and documentation straight (I found 3 or 4 different basic examples, none of which worked for me)? Are other Apache projects using DBCP at this point, and is it reasonable to remove methods that have not been implemented (like setLoginTimeout())? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
Howdy, Yes, but that doubles the # of SQL statements. And I actually have probably no more than 8 SQL statements in total (all prepared), so the issue is not the SQL but the connection. Is there another way to check that a connection is bad, other than a validation query? AFAIK this is the standard way, and the above argument that using validation queries doubles the number of SQL statement doesn't matter that much. Validation queries are supposed to be quick, small, etc. Do you know of anything else in Apache that could handle this? Anybody know what Tomcat is using at this point? Tomcat doesn't have built-in connection pooling, but a mechanism for users to plug in their own. Many people use DBCP, and tomcat provides a HOW-TO: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-datasource-examples -howto.html I wouldn't rush to declare DBCP dead. Database connection pooling is not exactly the most revolutionary development area right now: DBCP is good at what it does, is being used widely, and I personally am not aware of anything that required a DBCP release within the past year. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21021] - [PATCH] reduce object creation in ToStringBuilder
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21021. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21021 [PATCH] reduce object creation in ToStringBuilder --- Additional Comments From [EMAIL PROTECTED] 2003-06-23 17:16 --- BTW, thank you Janek for spotting this one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
Shapira, Yoav wrote: I wouldn't rush to declare DBCP dead. Database connection pooling is not exactly the most revolutionary development area right now: DBCP is good at what it does, is being used widely, and I personally am not aware of anything that required a DBCP release within the past year. That's somewhat encouraging about Tomcat using it (or at least mentions it first). Since James really does need a new connection pooler, and I'm stuck having to invest some time into making **some** database pooler more robust, is the DBCP project open to this? I'm not sure if there are any committers remaining, or what exactly is the next step. Basically I would make the following changes: - Allow the pool to optionally close a connection on a SQL exception (since that will often corrupt the transaction and/or indicate the connection is boofed). - Change some default values so it doesn't block indefinitely to open a connection out of the box. - Maybe support a connection factory constructor that can take a String for a driver name, rather than require you to do Class.forName() separately. - Maybe implement login timeout. - Maybe implement logging via commons logging so you can catch events rather than just use a writer. - Make a formal new release (either 1.1 or 2.0, I don't care), just so the examples, test code, and javadoc (in distro and website) all have working examples. Any feedback on these changes, or people I should talk to before heading down this road? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19331] - [lang] General case: infinite loop: ToStringBuilder.reflectionToString
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19331. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19331 [lang] General case: infinite loop: ToStringBuilder.reflectionToString --- Additional Comments From [EMAIL PROTECTED] 2003-06-23 17:27 --- For an example test, see the method ToStringBuilderTest.testReflectionObjectCycle() v 1.8. I would like to close thie PR if the reporter (Jack Wasey) could confirm that the current build solves the issue in his code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
Howdy, Since James really does need a new connection pooler, and I'm stuck having to invest some time into making **some** database pooler more robust, is the DBCP project open to this? I'm not sure if there are any I'm positive no one would oppose you contributing and working on it ;) - Allow the pool to optionally close a connection on a SQL exception (since that will often corrupt the transaction and/or indicate the connection is boofed). - Change some default values so it doesn't block indefinitely to open a connection out of the box. - Maybe support a connection factory constructor that can take a String for a driver name, rather than require you to do Class.forName() separately. - Maybe implement login timeout. - Maybe implement logging via commons logging so you can catch events rather than just use a writer. - Make a formal new release (either 1.1 or 2.0, I don't care), just so the examples, test code, and javadoc (in distro and website) all have working examples. The above ideas all seem cool to various degrees. I dislike the commons-logging one, as that may cause some problems for people using DBCP who don't want to use commons-logging. But testing can iron that out and I don't think it'll be a showstopper ultimately. Any feedback on these changes, or people I should talk to before heading down this road? You already have the above list; I would start by entering them as DBCP enhancement requests in bugzilla. Then start working them and send in patches to the mailing list (appropriately marking the subject lines, i.e. [DBCP][PATCH]). The committers will comment... Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
Serge Knystautas wrote: Since James really does need a new connection pooler, and I'm stuck having to invest some time into making **some** database pooler more robust, is the DBCP project open to this? I'm not sure if there are any committers remaining, or what exactly is the next step. Basically I would make the following changes: - Allow the pool to optionally close a connection on a SQL exception (since that will often corrupt the transaction and/or indicate the connection is boofed). We are using DBCP in an application that has not yet gone to production, but is in active development; and we could definitely use this feature. Of course, I could just hack the source and implement it myself, but I've been too lazy thus far. :) Anyway, just wanted to let you know that your proposed enhancements would be much appreciated by the user community! - Maybe implement logging via commons logging so you can catch events rather than just use a writer. This would be nice, too: we're using C-L in our app. - Make a formal new release (either 1.1 or 2.0, I don't care), just so the examples, test code, and javadoc (in distro and website) all have working examples. That would all be just great! Hoping you decide to go this route, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] What's left for 2.0
Bug #19331 I think this should be fixed in the cvs code base as we do detect cycles with the reflection version of the code. Of course, if two classes both implement their own toString() methods and point to each other, that is still a problem. Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Sunday, June 22, 2003 21:02 To: Jakarta Commons Developers List Subject: Re: [lang] What's left for 2.0 2.0 time again. As far as I can tell, all we have left are: Bug #15082. Stephen has done some work here, and suggests making DurationFormatUtils package scoped for 2.0. +1 from me, anyone against it? Bug #19331 Some kind of issue with the builders. Mohan has a good reply here, is it a real problem or just a feature? Do we kill or solve? Are there any others that people think should go in? Are there any other tasks that people are working on or have open? Hen On Sun, 15 Jun 2003, Henri Yandell wrote: On Wed, 4 Jun 2003, Gary Gregory wrote: We have over the last couple of weeks started what's left for 2.0 message threads a couple of times, do people here want a 2.0 (or a 2.0 beta first)? Yep. Time for another one soon. [email I mean]. I'm in favour of just going straight to a 2.0 rather than pushing a beta out. I'm not sure that reusable libraries as abstract as ours [and not a service like maven, tomcat etc] gain much from a beta release. Apologies for some of the questions coming up and for reopening of old emails, I've been gone for 3 weeks. Should we consider: (1) IntHashMap as a non-public member of [lang] In for 2.0, or defer to discuss (2)? This was for Entities.java optimisation? Sounds good to go in. (2) all his other utility code Does not affect [lang] per se but it is becoming clear that keeping [lang] and [collections] not inter-dependent will introduce duplication of functionality or odd placement of functionality (IntHashMap in lang, not collection). Duplicating code is something I am really not fond of. I think this is a clear case of a good reason for allowing duplication. Optimisation involves lots of yucky things [and rarely anything nice]. Duplication is a yucky thing, but the optimisation is more important. 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] FileUpload 1.0 Final Release Plan
On Sun, 22 Jun 2003, Martin Cooper wrote: -- Vote: FileUpload 1.0 Final Release Plan [X] +1 I am in favor of the release, and will help support it. [ ] +0 I am in favor of the release, but am unable to help support it. [ ] -0 I am not in favor of the release. [ ] -1 I am against this proposal (must include a reason). -- Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21023] New: - [PATCH] [math] Natural spline interpolation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21023. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21023 [PATCH] [math] Natural spline interpolation Summary: [PATCH] [math] Natural spline interpolation Product: Commons Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Sandbox AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Appended a tgz with new files for interpolation with an natural cubic spline. Caveats: several TODOs in the source, and the unit tests must be reworked. The patch depends on the UnivariateRealFunction interface. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21023] - [PATCH] [math] Natural spline interpolation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21023. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21023 [PATCH] [math] Natural spline interpolation --- Additional Comments From [EMAIL PROTECTED] 2003-06-23 18:30 --- Created an attachment (id=6940) Proposed patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Tasks remaining for initial release
Al Chou wrote: * Interpolation. Al is working on cubic spline interpolation. Right? Right. Sorry if I preempted your work, but I just posted cubic spline interpolation to bugzilla for general review. There are a few design questions, to be discussed separately, and the unit test still need work. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] What's left for 2.0
By the way, I've been playing/learning JavaDiff [http://javadiff.sourceforge.net] and have outputted the changes from 1.0.1 to 2.0[well, HEAD]. http://webmail.flamefew.net/~hen/langdiff/changes.html It's quite fun. I aim to make a 1.0-1.0.1 as well and make the publication of this a part of the informal Lang release process, unless someone dislikes it. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Tasks remaining for initial release
--- J.Pietschmann [EMAIL PROTECTED] wrote: Al Chou wrote: * Interpolation. Al is working on cubic spline interpolation. Right? Right. Sorry if I preempted your work, but I just posted cubic spline interpolation to bugzilla for general review. There are a few design questions, to be discussed separately, and the unit test still need work. That's OK, but it would have been nice if you had informed the rest of the gang that you were even working on it. In this case I don't mind, as it's made me refresh my knowledge and even learn things I never knew before, but to avoid duplicated work in the future, let's all try to keep each other up to date on what we're working on. Are you currently working on your root finding code? IIRC, it had a few problems that prevented it from being committed into CVS. Al = Albert Davidson Chou Get answers to Mac questions at http://www.Mac-Mgrs.org/ . __ 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 status?
Noel J. Bergman wrote: Martin Poeschl [EMAIL PROTECTED] wrote: dbcp is still used by torque and other projects ... i'm also interrested in maintaining the code .. how's about moving the package to db-commons?? Martin, so long as we get commit access, does it really matter which module? I view location as orthogonal. db.apache.org is a good location for a db connection pool, isn't it? when the db projects was started the idea was to have one place for all db related projects like torque, ojb, commons-dbcp, commons-sql, ... torque and ojb are already there ... if a new group of developers starts to work on dbcp i think it's a good chance to do the movement ... martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
existing apache committers have traditionally had few problems about being elected committers here so access shouldn't really be a problem. i'd say that there will probably be quite a difference in atmosphere between the two sub-projects. developing in the jakarta commons means putting up with folks here, subscribing to the commons-dev mailing list (which is pretty high volume) but is high visibility. db-commons should be quieter and more focused on database components. if people think that moving would be a good idea, then it'd probably be a good idea to check first with the existing committers (probably a VOTE would be a good way to handle it). so i suppose that the first step should really be to propose a VOTE to elect noel as a commons committer. i'd prefer it if it came from one of the existing DBCP committers but if no one steps up sometime soonish i'll set something in motion. - robert On Monday, June 23, 2003, at 11:03 PM, Noel J. Bergman wrote: Martin Poeschl [EMAIL PROTECTED] wrote: dbcp is still used by torque and other projects ... i'm also interrested in maintaining the code .. how's about moving the package to db-commons?? Martin, so long as we get commit access, does it really matter which module? I view location as orthogonal. --- Noel - 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: DBCP status?
dbcp is still used by torque and other projects ... i'm also interrested in maintaining the code .. how's about moving the package to db-commons?? Martin, so long as we get commit access, does it really matter which module? I view location as orthogonal. db.apache.org is a good location for a db connection pool, isn't it? when the db projects was started the idea was to have one place for all db related projects like torque, ojb, commons-dbcp, commons-sql, ... I'm sure it would be, yes. And if that's where people want it, I'll be happy to check it out from there and subscribe to that list. My only point is that I'd like to see the work start, and not get bogged down in any argument (*IF* there is one) about where to have the code. If it moves or stays, either way is fine with me. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang SerializationUtils.java
scolebourne2003/06/23 15:36:50 Modified:lang/src/java/org/apache/commons/lang SerializationUtils.java Log: Update javadoc Revision ChangesPath 1.6 +3 -2 jakarta-commons/lang/src/java/org/apache/commons/lang/SerializationUtils.java Index: SerializationUtils.java === RCS file: /home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/SerializationUtils.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- SerializationUtils.java 23 Mar 2003 18:02:29 - 1.5 +++ SerializationUtils.java 23 Jun 2003 22:36:50 - 1.6 @@ -64,7 +64,8 @@ /** * pcodeSerializationUtils/code provides methods that assist with the - * serialization process, or perform additional functionality based on serialization./p + * serialization process, or perform additional functionality based on serialization. + * /pp * ul * liDeep clone using serialization * liSerialize managing finally and IOException - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/time package.html
scolebourne2003/06/23 15:37:39 Added: lang/src/java/org/apache/commons/lang/util package.html lang/src/java/org/apache/commons/lang/time package.html Log: Add package level javadoc Revision ChangesPath 1.1 jakarta-commons/lang/src/java/org/apache/commons/lang/util/package.html Index: package.html === html body p Provides classes and methods that provide general utility code. p This includes: ul licodeBitField/code - for manipulating bits licodeIdentifierUtils/code - for creating identifiers licodeValidate/code - for validating values and throwing exceptions /ul /body /html 1.1 jakarta-commons/lang/src/java/org/apache/commons/lang/time/package.html Index: package.html === html body p Provides classes and methods to work with dates and durations. p This includes: ul licodeDateUtils/code - a set of static utility methods for working with dates licodeFastDateFormat/code - a replacement for codeSimpleDateFormat/code that is fast and thread-safe licodeDateFormatUtils/code - a formatting class for dates licodeStopWatch/code - a duration timer /ul /body /html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] NumberUtils minimum, maximum, and xor
NumberUtils is best for this. Stephen - Original Message - From: _matthewHawthorne [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, June 23, 2003 4:25 PM Subject: RE: [lang] NumberUtils minimum, maximum, and xor I have a path and test for xor(boolean[]) that I will submit for BooleanUtils. I can also submit a patch for min and max with parameters short[], int[], long[], float[], and double[]. Would it make sense for this to go into lang.NumberUtils or a new class in lang.math? On Mon, 2003-06-23 at 02:08, [EMAIL PROTECTED] wrote: I disagree. lang.math exists for very simple, common maths operations. Min/max is a good example of this. It should be extended to all primitive types. A little duplication here is OK. (Note that a year ago I wouldn't have written this, but it makes more sense to me now) Adding min(int[]) etc is also probably a good idea. It may be best to rename the methods to min and max to be compatable with [math] (deprecating as needed). On the boolean question, we have a BooleanUtils to add xor() to. Do you have a patch/test available? Stephen from:Gary Gregory [EMAIL PROTECTED] If we want to be consistent, we could deprecate [lang]'s min/max and point to [math]. This would parallel nicely with c.lang for java.lang and c.math for java.math. It does not seem right to add all primitive types to c.lang.NumberUtils if min/max routines are in c.math. Gary -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Saturday, June 21, 2003 15:18 To: Jakarta Commons Developers List Subject: Re: [lang] NumberUtils minimum, maximum, and xor Just to note: we have moved somwhat along these lines in the the commons [math] sandbox component. Currently we have o.a.c.m.stat.StatUtils: double min(double[] doubleArr) double max(double[] doubleArr) available there. -Mark Diggory _matthewHawthorne wrote: I have 2 observations: (1) Currently, the following methods are in o.a.c.l.NumberUtils int maximum(int a, int b, int c) long maximum(long a, long b, long c) int minimum(int a, int b, int c) long minimum(long a, long b, long c) I think it be more flexible to replace them with the following: int minimum(int[] intArr) int maximum(int[] intArr) long minimum(long[] longArr) long maximum(long[] longArr) It also may be a good time to add any missing methods such as: short minimum(short[] shortArr) short maximum(short[] shortArr) float minimum(float[] floatArr) float maximum(float[] floatArr) double minimum(double[] doubleArr) double maximum(double[] doubleArr) Any thoughts? (2) After searching for an easy way to xor booleans, and not finding anything, I created a method: boolean xor(boolean[] boolArr) Would this be a good addition to NumberUtils? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
Noel J. Bergman [EMAIL PROTECTED] writes: Martin Poeschl [EMAIL PROTECTED] wrote: dbcp is still used by torque and other projects ... i'm also interrested in maintaining the code .. how's about moving the package to db-commons?? Martin, so long as we get commit access, does it really matter which module? I view location as orthogonal. If Martin wants to work on it, I'm all +1 . Better than letting the code rot in (jakarta-)commons. 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]
RE: DBCP status?
I think that poolman had been end-of-lifed, and many of it's ideas went into DBCP. Eric -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 5:16 PM To: Jakarta Commons Developers List Subject: Re: DBCP status? On Mon, 23 Jun 2003, Serge Knystautas wrote: Mark Lewis wrote: Serge, I'm using DBCP in a production environment. It actually does support validation queries to detect whether a connection is bogus or not. Yes, but that doubles the # of SQL statements. And I actually have probably no more than 8 SQL statements in total (all prepared), so the issue is not the SQL but the connection. I can provide sample code if you'd like. But like David said earlier, DBCP is pretty much a dead project. It works well enough for my needs, but I'm not sure I'd integrate it into a project right now. Do you know of anything else in Apache that could handle this? Anybody know what Tomcat is using at this point? This isn't an Apache project (although one of the admins is an Apache guy ;), but you might want to look at PoolMan: http://sourceforge.net/projects/poolman/ -- Martin Cooper On a related note, does anybody know what the status of PreparedStatement pooling is in the latest DBCP release? It seems broken to me, but I might be doing something wrong. We'd like that feature as well (since like I say we have so few SQL statements), but that's a bummer if it's broken. From the API it seems like it would work. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 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: DBCP status?
did geir once suggest bringing poolman to apache? does anyone remember what happened about that? - robert On Tuesday, June 24, 2003, at 12:08 AM, [EMAIL PROTECTED] wrote: I think that poolman had been end-of-lifed, and many of it's ideas went into DBCP. Eric -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 5:16 PM To: Jakarta Commons Developers List Subject: Re: DBCP status? On Mon, 23 Jun 2003, Serge Knystautas wrote: Mark Lewis wrote: Serge, I'm using DBCP in a production environment. It actually does support validation queries to detect whether a connection is bogus or not. Yes, but that doubles the # of SQL statements. And I actually have probably no more than 8 SQL statements in total (all prepared), so the issue is not the SQL but the connection. I can provide sample code if you'd like. But like David said earlier, DBCP is pretty much a dead project. It works well enough for my needs, but I'm not sure I'd integrate it into a project right now. Do you know of anything else in Apache that could handle this? Anybody know what Tomcat is using at this point? This isn't an Apache project (although one of the admins is an Apache guy ;), but you might want to look at PoolMan: http://sourceforge.net/projects/poolman/ -- Martin Cooper On a related note, does anybody know what the status of PreparedStatement pooling is in the latest DBCP release? It seems broken to me, but I might be doing something wrong. We'd like that feature as well (since like I say we have so few SQL statements), but that's a bummer if it's broken. From the API it seems like it would work. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21030] New: - PATCH MultiHashMap
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21030. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21030 PATCH MultiHashMap Summary: PATCH MultiHashMap Product: Commons Version: 2.1 Final Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Collections AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The implementation of MultiMap and MultiHashMap currenlty offered is a very simple implementation and, as such, has several problems. You probably already know all of them, but I've listed the more obvious ones below. Since a robust implementation of a MultiHashMap was required for my work, I've implemented by own class, which I will be willing to share with you. It is very closely based on Sun's implementation of the HashMap class and resolves all of the issues listed below. Since I'm new to Jakarta, I'm not yet sure how to make contributions. 1) The size() method returns the number of keys, not values, stored in the map. There currently is no way to determine how many values are in the map without calling values().size(). 2) The values() method is very inefficient since it creates an ArrayList and adds all the values from the map to it in a linear fashion. The fact that this collection is essentially a clone of the map is the cause of most of the bugs listed below. 3) The values() method returns a collection that is not backed by the map, violating the principles of collection view methods set forth by Sun. Making a change to the collection returned by values(), such as removing an element, will NOT modify the map. 4) The iterator for the values collection, returned by values().iterator(), is not tied into the map in any way. Therefore, calling the remove() method on the iterator will NOT change the map. 5) The iterator for the values collection is not fail-fast. Therefore, a change to the map during iteration will never be detected and may cause serious problems in a multi-threaded environment. 6) Several functions that I feel should be included in the MultiMap inteface didn't exist: containsValue(key,item) - Removes the key-value mapping from the key to a value equal to item. removeValue(item) - Removes the first encountered value that is equal to item. removeAll(key,item) - Since the map should allow multiple mappings between equivalent key and values, this method should be provided so that all mappings between the key and values equivalent to item may be removed from the map. removeAll(item) - Since the map may store multiple mappings to equivalent values, this method should be provided so that all mappings to values equivalent to item may be removed from the map. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
existing apache committers have traditionally had few problems about being elected committers here so access shouldn't really be a problem. I didn't expect that there would be a problem. i suppose that the first step should really be to propose a VOTE to elect noel as a commons committer. Whoops. Thanks, but don't forget Serge, who is the James PMC Chair, and the one who started this thread. :-) developing in the jakarta commons means putting up with folks here, subscribing to the commons-dev mailing list (which is pretty high volume) but is high visibility. db-commons should be quieter and more focused on database components. I'm good either way. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21030] - PATCH MultiHashMap
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21030. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21030 PATCH MultiHashMap --- Additional Comments From [EMAIL PROTECTED] 2003-06-23 23:31 --- Created an attachment (id=6945) My implementation of a hash-based multimap to replace MultiHashMap - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
Subject: Re: DBCP status? did geir once suggest bringing poolman to apache? does anyone remember what happened about that? There was not enough support for the move. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/time DateUtils.java
scolebourne2003/06/23 16:41:10
Modified:lang/src/test/org/apache/commons/lang/time
DateUtilsTest.java
lang/src/java/org/apache/commons/lang/time DateUtils.java
Log:
Prepare DateUtils for 2.0 release
Revision ChangesPath
1.4 +122 -58
jakarta-commons/lang/src/test/org/apache/commons/lang/time/DateUtilsTest.java
Index: DateUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/time/DateUtilsTest.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- DateUtilsTest.java8 Jun 2003 23:14:23 - 1.3
+++ DateUtilsTest.java23 Jun 2003 23:41:10 - 1.4
@@ -153,62 +153,104 @@
assertEquals(round second-2 failed,
dateTimeParser.parse(November 18, 2001 1:23:11.000),
DateUtils.round(date2, Calendar.SECOND));
+
+try {
+DateUtils.round((Date) null, Calendar.SECOND);
+fail();
+} catch (IllegalArgumentException ex) {}
+try {
+DateUtils.round((Calendar) null, Calendar.SECOND);
+fail();
+} catch (IllegalArgumentException ex) {}
+try {
+DateUtils.round((Object) null, Calendar.SECOND);
+fail();
+} catch (IllegalArgumentException ex) {}
+try {
+DateUtils.round(, Calendar.SECOND);
+fail();
+} catch (ClassCastException ex) {}
}
/**
* Tests various values with the trunc method
*/
-public void testTrunc() throws Exception {
-assertEquals(trunc year-1 failed,
+public void testTruncate() throws Exception {
+assertEquals(truncate year-1 failed,
dateParser.parse(January 1, 2002),
-DateUtils.trunc(date1, Calendar.YEAR));
-assertEquals(trunc year-2 failed,
+DateUtils.truncate(date1, Calendar.YEAR));
+assertEquals(truncate year-2 failed,
dateParser.parse(January 1, 2001),
-DateUtils.trunc(date2, Calendar.YEAR));
-assertEquals(trunc month-1 failed,
+DateUtils.truncate(date2, Calendar.YEAR));
+assertEquals(truncate month-1 failed,
dateParser.parse(February 1, 2002),
-DateUtils.trunc(date1, Calendar.MONTH));
-assertEquals(trunc month-2 failed,
+DateUtils.truncate(date1, Calendar.MONTH));
+assertEquals(truncate month-2 failed,
dateParser.parse(November 1, 2001),
-DateUtils.trunc(date2, Calendar.MONTH));
-assertEquals(trunc semimonth-1 failed,
+DateUtils.truncate(date2, Calendar.MONTH));
+assertEquals(truncate semimonth-1 failed,
dateParser.parse(February 1, 2002),
-DateUtils.trunc(date1, DateUtils.SEMI_MONTH));
-assertEquals(trunc semimonth-2 failed,
+DateUtils.truncate(date1, DateUtils.SEMI_MONTH));
+assertEquals(truncate semimonth-2 failed,
dateParser.parse(November 16, 2001),
-DateUtils.trunc(date2, DateUtils.SEMI_MONTH));
-assertEquals(trunc date-1 failed,
+DateUtils.truncate(date2, DateUtils.SEMI_MONTH));
+assertEquals(truncate date-1 failed,
dateParser.parse(February 12, 2002),
-DateUtils.trunc(date1, Calendar.DATE));
-assertEquals(trunc date-2 failed,
+DateUtils.truncate(date1, Calendar.DATE));
+assertEquals(truncate date-2 failed,
dateParser.parse(November 18, 2001),
-DateUtils.trunc(date2, Calendar.DATE));
-assertEquals(trunc hour-1 failed,
+DateUtils.truncate(date2, Calendar.DATE));
+assertEquals(truncate hour-1 failed,
dateTimeParser.parse(February 12, 2002 12:00:00.000),
-DateUtils.trunc(date1, Calendar.HOUR));
-assertEquals(trunc hour-2 failed,
+DateUtils.truncate(date1, Calendar.HOUR));
+assertEquals(truncate hour-2 failed,
dateTimeParser.parse(November 18, 2001 1:00:00.000),
-DateUtils.trunc(date2, Calendar.HOUR));
-assertEquals(trunc minute-1 failed,
+DateUtils.truncate(date2, Calendar.HOUR));
+assertEquals(truncate minute-1 failed,
dateTimeParser.parse(February 12, 2002 12:34:00.000),
-DateUtils.trunc(date1, Calendar.MINUTE));
-assertEquals(trunc minute-2 failed,
+DateUtils.truncate(date1, Calendar.MINUTE));
+assertEquals(truncate minute-2 failed,
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods PostMethod.java
mbecke 2003/06/23 16:41:40
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpMethodBase.java
httpclient/src/test/org/apache/commons/httpclient
TestWebappMethods.java TestRequestLine.java
httpclient/src/java/org/apache/commons/httpclient/methods
PostMethod.java
Log:
Modifies form urlencoding to not encode *, ., - and _. Adds urlencoding for query
params.
PR: 20481
Reviewed by: Oleg Kalnichevski and Laura Werner
Revision ChangesPath
1.156 +92 -36
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java
Index: HttpMethodBase.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java,v
retrieving revision 1.155
retrieving revision 1.156
diff -u -r1.155 -r1.156
--- HttpMethodBase.java 20 Jun 2003 16:43:18 - 1.155
+++ HttpMethodBase.java 23 Jun 2003 23:41:39 - 1.156
@@ -68,6 +68,7 @@
import java.io.IOException;
import java.io.InputStream;
import java.io.InterruptedIOException;
+import java.util.BitSet;
import java.util.HashSet;
import java.util.Set;
import org.apache.commons.httpclient.auth.AuthScheme;
@@ -157,6 +158,32 @@
USER_AGENT = new Header(User-Agent, agent);
}
+/**
+ * BitSet of www-form-url safe characters.
+ */
+protected static final BitSet WWW_FORM_URL = new BitSet(256);
+
+// Static initializer for www_form_url
+static {
+// alpha characters
+for (int i = 'a'; i = 'z'; i++) {
+WWW_FORM_URL.set(i);
+}
+for (int i = 'A'; i = 'Z'; i++) {
+WWW_FORM_URL.set(i);
+}
+// numeric characters
+for (int i = '0'; i = '9'; i++) {
+WWW_FORM_URL.set(i);
+}
+// blank to be replaced with +
+WWW_FORM_URL.set(' ');
+WWW_FORM_URL.set('-');
+WWW_FORM_URL.set('_');
+WWW_FORM_URL.set('.');
+WWW_FORM_URL.set('*');
+}
+
// - Instance variables
/** My request headers, if any. */
@@ -465,37 +492,7 @@
*/
public void setQueryString(NameValuePair[] params) {
LOG.trace(enter HttpMethodBase.setQueryString(NameValuePair[]));
-StringBuffer buf = new StringBuffer();
-boolean needAmp = false;
-for (int i = 0; i params.length; i++) {
-if (params[i].getName() != null) {
-if (needAmp) {
-buf.append();
-} else {
-needAmp = true;
-}
-String queryName = null;
-try {
-queryName = URIUtil.encodeWithinQuery(params[i].getName());
-} catch (URIException urie) {
-LOG.error(encoding error within query name, urie);
-queryName = params[i].getName();
-}
-buf.append(queryName).append(=);
-if (params[i].getValue() != null) {
-String queryValue = null;
-try {
-queryValue =
-URIUtil.encodeWithinQuery(params[i].getValue());
-} catch (URIException urie) {
-LOG.error(encoding error within query value, urie);
-queryValue = params[i].getValue();
-}
-buf.append(queryValue);
-}
-}
-}
-queryString = buf.toString();
+queryString = formUrlEncode(params, HttpConstants.HTTP_ELEMENT_CHARSET);
}
/**
@@ -1700,7 +1697,66 @@
return buf.toString();
}
-
+
+/**
+ * @deprecated temporary method. to be moved to commons Codec.
+ *
+ * Form-urlencoding routine.
+ *
+ * The default encoding for all forms is `application/x-www-form-urlencoded'.
+ * A form data set is represented in this media type as follows:
+ *
+ * The form field names and values are escaped: space characters are replaced
+ * by `+', and then reserved characters are escaped as per [URL]; that is,
+ * non-alphanumeric characters are replaced by `%HH', a percent sign and two
+ * hexadecimal digits representing the ASCII code of the character. Line
breaks,
+ * as in multi-line text field values, are represented as CR LF pairs, i.e.
`%0D%0A'.
+ *
+ * @param pairs the values to be encoded
+ * @param charset the character set of pairs to be encoded
+
[lang] Pre 2.0 checks
TODO 1) StringUtils.unescape(String) - this is merely forwarding to StringEscapeUtils and should surely be deprecated? 2) NumberUtils - Other maths classes are now in lang.math, so I think there is a good case to move this (deprecating the original) 3) ToStringBuilder - infinite recursion 4) BooleanUtils - xor (Don't delay release for this) 5) NumberUtils - min/max (Don't delay release for this) DONE DateUtils - now checked - renamed trunc to truncate - renamed parse to parseCVS - renamed getCalendarIterator to iterator - improved javadoc - broke out an anonymous inner class Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
On Mon, 23 Jun 2003 [EMAIL PROTECTED] wrote: I think that poolman had been end-of-lifed, and many of it's ideas went into DBCP. No, it wasn't end-of-life'd. What happened was that the original developer decided he didn't want to continue to support it by himself at its own web site. Geir offered to help out, so it's now maintained (?) only at the SF site. (The '?' is because there isn't evidence of activity there, but then it's supposedly pretty stable anyway.) -- Martin Cooper Eric -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 5:16 PM To: Jakarta Commons Developers List Subject: Re: DBCP status? On Mon, 23 Jun 2003, Serge Knystautas wrote: Mark Lewis wrote: Serge, I'm using DBCP in a production environment. It actually does support validation queries to detect whether a connection is bogus or not. Yes, but that doubles the # of SQL statements. And I actually have probably no more than 8 SQL statements in total (all prepared), so the issue is not the SQL but the connection. I can provide sample code if you'd like. But like David said earlier, DBCP is pretty much a dead project. It works well enough for my needs, but I'm not sure I'd integrate it into a project right now. Do you know of anything else in Apache that could handle this? Anybody know what Tomcat is using at this point? This isn't an Apache project (although one of the admins is an Apache guy ;), but you might want to look at PoolMan: http://sourceforge.net/projects/poolman/ -- Martin Cooper On a related note, does anybody know what the status of PreparedStatement pooling is in the latest DBCP release? It seems broken to me, but I might be doing something wrong. We'd like that feature as well (since like I say we have so few SQL statements), but that's a bummer if it's broken. From the API it seems like it would work. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
NetMatcher class for Commons
There is code I recently contributed to James to handle whether a particular host (FQDN or IP) is within a network. Is there any interest on having this class in Commons? I am happy maintaining it; I'm just offering it to be shared. --- Noel http://cvs.apache.org/viewcvs.cgi/jakarta-james/src/java/org/apache/james/ut il/NetMatcher.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)
robert burrell donkin wrote: On Friday, June 20, 2003, at 05:34 PM, Phil Steitz wrote: I keep reminding myself, we are the developers, there is always room for refactoring in the future. If there becomes a clear hindrance with the use of static methods, then we can refactor them into a class that needs to be instantiated. This is not too difficult to accomplish. Not for us, maybe, but it could be a real pain for the users who have written code using the static methods directly. We also need to keep reminding ourselves that what we are developing is a library for others to use. Refactoring public interfaces post release is a slow and painful process. Given that MathUtils and StatUtils are going to be public, we need to be committed to supporting the static methods that they will expose. I am personally OK with this, as long as we limit the scope to relatively trivial computational methods. we came across this very problem in beanutils not too long ago. beanutils was originally written to use static utility methods. we ended up creating (pseudo-)singletons that do the actual work. this has turned out to have more than a few wrinkles (since jakarta components are designed to be used in server applications, there's a lot to think about when it comes to ensuring that objects can be garbage collection and that different web applications use independent versions of configurable library code). i personally think that there is probably room for a few headline classes of this type at the top of the hierarchy in order to make things easy for basic users. but i would probably advise developers of library code to prefer concrete objects for advanced classes. experience has shown that these may need to be sub-classed or have to make use of the strategy pattern later. i would say that retro-fitting these capabilities to an existing library can prove to be very non-trivial. anyway, i'll be interested to see what J.Pietschmann comes up with. - robert This is a really strong point Robert, I know there are real issues with objects that get created from a static point not getting garbage collected from some applications I worked on, I shouldn't have assumed it wasn't an issue in the server env. I'd have to say, this is the strongest point I've seen so far for singleton object usage over static util usage and its quite convincing to me. I think I actually have somewhat of an interesting solution to this. But I want to get it fully formalized to present to the group, I have an alternative implementation of some of the stat/StatUtil classes that I will present to the group within the next day or so. -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
existing apache committers have traditionally had few problems about being elected committers here so access shouldn't really be a problem. Noel, forgive my ignorance but are you an existing committer? I'll nominate you to the commons based on Robert's apparent faith in you ;-). i'd say that there will probably be quite a difference in atmosphere between the two sub-projects. developing in the jakarta commons means putting up with folks here, subscribing to the commons-dev mailing list (which is pretty high volume) but is high visibility. db-commons should be quieter and more focused on database components. if people think that moving would be a good idea, then it'd probably be a good idea to check first with the existing committers (probably a VOTE would be a good way to handle it). so i suppose that the first step should really be to propose a VOTE to elect noel as a commons committer. i'd prefer it if it came from one of the existing DBCP committers but if no one steps up sometime soonish i'll set something in motion. I took a crack at fixing DBCP for Struts 1.1 and decided it was in such bad shape that we (Struts) should just drop it. If other people are willing to fix and support it, I'm +1 on moving to db-commons. Here is my wish list for DBCP in no particular order: - Delete the org.apache.commons.jocl package because it's no longer used/needed. - Analyze the o.a.c.dbcp.cpdsadapter and o.a.c.dbcp.jdbc2pool packages/classes and refactor any useful ideas into the main o.a.c.dbcp package. - We deprecated all the Abandoned* classes and related functionality but it still needs to be removed. It was an absolutely terrible idea to try and recover connections from poorly written client applications. Adding this to DBCP only increased the number of bugs. I do think logging potential connection leaks is appropriate but it's the application's responsibilty to not lose connections. - All of the Delegating* classes need to be returned to their pure delegate state. Functionality was added that lead to synchronization problems and wasn't in the spirit of a delegate class. - Standardize the coding conventions to the Sun Java guidelines. Most DBCP code follows it but some classes don't. Also, drop the hideous _var notation for instance variables. In combination these problems make the code uglier, harder to read, and thus harder to maintain. I would really like to see DBCP be a production quality connection pooling package so I'm really glad some more people are willing to take care of it. David - robert On Monday, June 23, 2003, at 11:03 PM, Noel J. Bergman wrote: Martin Poeschl [EMAIL PROTECTED] wrote: dbcp is still used by torque and other projects ... i'm also interrested in maintaining the code .. how's about moving the package to db-commons?? Martin, so long as we get commit access, does it really matter which module? I view location as orthogonal. --- Noel - 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] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
David Graham wrote: I took a crack at fixing DBCP for Struts 1.1 and decided it was in such bad shape that we (Struts) should just drop it. If other people are willing to fix and support it, I'm +1 on moving to db-commons. Here is my wish list for DBCP in no particular order: Thanks David. I'll add these to the list of changes I posted and will get it done shortly. They all seem very reasonable and helped confirm that there was unnecessary duplication in the codebase. -- 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: DBCP status?
existing apache committers have traditionally had few problems about being elected committers here so access shouldn't really be a problem. Noel, forgive my ignorance but are you an existing committer? I'll nominate you to the commons based on Robert's apparent faith in you ;-). No worries. :-) There are, after all, close to 700 of us now. What I do if I don't know is log in and use finger. Serge, Martin Poeschl and I are all Committers. I took a crack at fixing DBCP [and] decided it was in such bad shape that we (Struts) should just drop it. If other people are willing to fix and support it, I'm +1 on moving to db-commons. I would really like to see DBCP be a production quality connection pooling package so I'm really glad some more people are willing to take care of it. Are you still willing to pitch in and help (or kibbitz), now that you've got company? Here is my wish list for DBCP in no particular order: I'm keeping a copy of your message for future reference. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
David Graham wrote: I took a crack at fixing DBCP for Struts 1.1 and decided it was in such bad shape that we (Struts) should just drop it. If other people are willing to fix and support it, I'm +1 on moving to db-commons. Here is my wish list for DBCP in no particular order: Thanks David. I'll add these to the list of changes I posted and will get it done shortly. They all seem very reasonable and helped confirm that there was unnecessary duplication in the codebase. Neat. I wish I could help out more but Struts and Validator are consuming all of my volunteer time right now. The main problem with DBCP seems to have been a drop and run approach to adding code. It really needs a steady team to maintain it. David -- 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] _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
existing apache committers have traditionally had few problems about being elected committers here so access shouldn't really be a problem. Noel, forgive my ignorance but are you an existing committer? I'll nominate you to the commons based on Robert's apparent faith in you ;-). No worries. :-) There are, after all, close to 700 of us now. What I do if I don't know is log in and use finger. Serge, Martin Poeschl and I are all Committers. Thanks for the tip. I took a crack at fixing DBCP [and] decided it was in such bad shape that we (Struts) should just drop it. If other people are willing to fix and support it, I'm +1 on moving to db-commons. I would really like to see DBCP be a production quality connection pooling package so I'm really glad some more people are willing to take care of it. Are you still willing to pitch in and help (or kibbitz), now that you've got company? I'm willing to help where I can but Struts and Validator are consuming my volunteer time right now. If there were only more hours in the day... David Here is my wish list for DBCP in no particular order: I'm keeping a copy of your message for future reference. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Add Noel J. Bergman as commons committer
Noel has expressed an interest in maintaining the relatively dead commons-dbcp project. I propose we add him as a commons committer. Here's my +1. David _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Add Noel J. Bergman as commons committer
Noel has expressed an interest in maintaining the relatively dead commons-dbcp project. I propose we add him as a commons committer. AND Serge Knystautas and Martin Poeschl, who have also expressed interest. Serge is the one who started this thread (and is already sitting at home editing DBCP); it makes no sense to skip over him. Serge and I came at this together from the James project to demonstrate that this is not one person's interest. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[validator] regexp tests, patches for tests
Hello all, never posted to the list, but I've been lurking for a bit.
Bug 17799
http://issues.apache.org/bugzilla/show_bug.cgi?id=17799
brought up that '/'s were not being escaped in regular expression patterns
(masks) so I decided to look into it. I found out that when I included
'/'s in the regexp value and did not escape them, a matching value for the
regexp passed regardless. I decided to formalize this with some unit tests
that cover one pattern with '/'s and another phone number pattern just to
verify that regexp pattern (masks) matching is working ok.
I've attached a RegexpTest.java file and another file of patches to get it
to run with 'ant test'. All tests are a go. If I should include patches
and new code in the body of the email just let me know. I figured it might
get passed up if I posted new code to bug database.
Thanks,
Adam Kramer/*
* $Header: $
* $Revision: $
* $Date: $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*/
package org.apache.commons.validator;
import java.io.IOException;
import java.io.InputStream;
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
/**
* pPerforms Validation Test for e-mail validations./p
*
* @author Adam Kramer
* @version $Revision: $ $Date: $
*/
public class RegexpTest extends TestCase {
/**
* The key used to retrieve the set of PHONE validation
* rules from the xml file.
*/
protected static String PHONE_FORM_KEY = phoneForm;
/**
* The key used to retrieve the set of forward slash validation
* rules from the xml file.
*/
protected static String FS_FORM_KEY = forwardSlashForm;
/**
* The key used to retrieve the validator action.
*/
protected static String ACTION = regexp;
/**
* Commons Logging instance.
*/
private Log log = LogFactory.getLog(this.getClass());
/**
* Resources used for validation tests.
*/
private ValidatorResources resources = null;
public RegexpTest(String name) {
super(name);
}
/**
* Start the tests.
Re: [validator] regexp tests, patches for tests
adam kramer wrote: Hello all, never posted to the list, but I've been lurking for a bit. Bug 17799 http://issues.apache.org/bugzilla/show_bug.cgi?id=17799 brought up that '/'s were not being escaped in regular expression patterns (masks) so I decided to look into it. I found out that when I included '/'s in the regexp value and did not escape them, a matching value for the regexp passed regardless. I decided to formalize this with some unit tests that cover one pattern with '/'s and another phone number pattern just to verify that regexp pattern (masks) matching is working ok. I've attached a RegexpTest.java file and another file of patches to get it to run with 'ant test'. All tests are a go. If I should include patches and new code in the body of the email just let me know. I figured it might get passed up if I posted new code to bug database. Some projects like it posted to the list like you have done, and other like a bugzilla report filed. IN THIS CASE a Bugilla report is appropiate for Validator, I know it can be confusing, but please do file a Bugilla report, an account , http://issues.apache.org/bugzilla/createaccount.cgi, only takes 20 seconds and only required a valid email address from you. -Rob Thanks, Adam Kramer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] NumberUtils minimum, maximum, and xor
While working on the xor patch, I encountered the need to create the following method: boolean[] toPrimitiveArray(Boolean[]) to avoid duplicating logic between handling primitive and object booleans. I made it private. But would it be a good public addition? Along with: Boolean[] toObjectArray(boolean[]) Any thoughts or suggestions? On Mon, 2003-06-23 at 15:40, Stephen Colebourne wrote: NumberUtils is best for this. Stephen - Original Message - From: _matthewHawthorne [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, June 23, 2003 4:25 PM Subject: RE: [lang] NumberUtils minimum, maximum, and xor I have a path and test for xor(boolean[]) that I will submit for BooleanUtils. I can also submit a patch for min and max with parameters short[], int[], long[], float[], and double[]. Would it make sense for this to go into lang.NumberUtils or a new class in lang.math? On Mon, 2003-06-23 at 02:08, [EMAIL PROTECTED] wrote: I disagree. lang.math exists for very simple, common maths operations. Min/max is a good example of this. It should be extended to all primitive types. A little duplication here is OK. (Note that a year ago I wouldn't have written this, but it makes more sense to me now) Adding min(int[]) etc is also probably a good idea. It may be best to rename the methods to min and max to be compatable with [math] (deprecating as needed). On the boolean question, we have a BooleanUtils to add xor() to. Do you have a patch/test available? Stephen from:Gary Gregory [EMAIL PROTECTED] If we want to be consistent, we could deprecate [lang]'s min/max and point to [math]. This would parallel nicely with c.lang for java.lang and c.math for java.math. It does not seem right to add all primitive types to c.lang.NumberUtils if min/max routines are in c.math. Gary -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Saturday, June 21, 2003 15:18 To: Jakarta Commons Developers List Subject: Re: [lang] NumberUtils minimum, maximum, and xor Just to note: we have moved somwhat along these lines in the the commons [math] sandbox component. Currently we have o.a.c.m.stat.StatUtils: double min(double[] doubleArr) double max(double[] doubleArr) available there. -Mark Diggory _matthewHawthorne wrote: I have 2 observations: (1) Currently, the following methods are in o.a.c.l.NumberUtils int maximum(int a, int b, int c) long maximum(long a, long b, long c) int minimum(int a, int b, int c) long minimum(long a, long b, long c) I think it be more flexible to replace them with the following: int minimum(int[] intArr) int maximum(int[] intArr) long minimum(long[] longArr) long maximum(long[] longArr) It also may be a good time to add any missing methods such as: short minimum(short[] shortArr) short maximum(short[] shortArr) float minimum(float[] floatArr) float maximum(float[] floatArr) double minimum(double[] doubleArr) double maximum(double[] doubleArr) Any thoughts? (2) After searching for an easy way to xor booleans, and not finding anything, I created a method: boolean xor(boolean[] boolArr) Would this be a good addition to NumberUtils? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang StringUtils.java
bayard 2003/06/23 19:55:17
Modified:lang/src/java/org/apache/commons/lang StringUtils.java
Log:
Deprecated unescape method.
Revision ChangesPath
1.49 +3 -2
jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java
Index: StringUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- StringUtils.java 23 Jun 2003 03:51:13 - 1.48
+++ StringUtils.java 24 Jun 2003 02:55:17 - 1.49
@@ -1187,9 +1187,10 @@
* unless the '\' is preceded by another '\'.
* p
* As of Lang 2.0, this calls [EMAIL PROTECTED]
StringEscapeUtils#unescapeJava(java.lang.String)}
- * behind the scenes. For convenience, this method is not deprecated.
+ * behind the scenes.
* p
* @see StringEscapeUtils#unescapeJava(java.lang.String)
+ * @deprecated Use [EMAIL PROTECTED]
StringEscapeUtils#unescapeJava(java.lang.String)}
*/
public static String unescape(String str) {
return StringEscapeUtils.unescapeJava(str);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/analysis UnivariateRealFunction.java BrentSolver.java UnivariateRealSolverImpl.java UnivariateRealSolverFactory.java UnivariateRealSolver.java SecantSolver.java
mdiggory2003/06/23 20:01:40
Added: math/src/java/org/apache/commons/math/analysis
UnivariateRealFunction.java BrentSolver.java
UnivariateRealSolverImpl.java
UnivariateRealSolverFactory.java
UnivariateRealSolver.java SecantSolver.java
Log:
This is the first half of this pr. Commit of analysis solvers.
PR: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20844
Submitted by: J. Pietschman
Revision ChangesPath
1.1
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/analysis/UnivariateRealFunction.java
Index: UnivariateRealFunction.java
===
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/
package org.apache.commons.math.analysis;
import org.apache.commons.math.MathException;
/**
* Provide an interface univariate real functions.
* The object may held temporary data which is shared between calculations
* of the value and the derivatives for the same argument. It is not guaranteed
* that derivatives are evaluated after the value, the evaluation algorithm
* should throw an InvalidStateException if it can't cope with this.
*
* @author pietsch at apache.org
*/
public interface UnivariateRealFunction {
/**
* Compute the value for the function.
* @param x the point for which the function value should be computed
* @return the value
* @throws MathException if the function couldn't be computed due to
* missing additional data or other environmental problems.
* @throws RuntimeException if the operation isn't supported, the argument
* was outside the supported domain or any other problem.
*
*/
public double value(double x) throws MathException;
/**
* Compute the value for the first derivative of the function.
* It is recommended to provide this method only if the first derivative is
* analytical. Numerical derivatives may be acceptable in some cases.
* An implementation should throw an UnsupportedOperationException if
* this method is not implemented.
* @param x the point for which
cvs commit: jakarta-commons-sandbox/math/src/test/org/apache/commons/math/analysis - New directory
mdiggory2003/06/23 20:01:53 jakarta-commons-sandbox/math/src/test/org/apache/commons/math/analysis - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20844] - [math] alternative root finding framework and Brent-Dekker solver
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20844. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20844 [math] alternative root finding framework and Brent-Dekker solver --- Additional Comments From [EMAIL PROTECTED] 2003-06-24 03:38 --- Commited and tested, these files are now in the java/test directories under org.apache.commons.math.analysis.* - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21023] - [PATCH] [math] Natural spline interpolation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21023. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21023 [PATCH] [math] Natural spline interpolation --- Additional Comments From [EMAIL PROTECTED] 2003-06-24 03:40 --- Created an attachment (id=6949) Proposed enhancement to SplineInterpolator (persistence of c[][] array as instance variable) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17799] - '/' not escaped in regexp mask
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17799. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17799 '/' not escaped in regexp mask --- Additional Comments From [EMAIL PROTECTED] 2003-06-24 05:25 --- Created an attachment (id=6951) RegexpTest.java source file for testing regexp support in validator - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17799] - '/' not escaped in regexp mask
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17799. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17799 '/' not escaped in regexp mask --- Additional Comments From [EMAIL PROTECTED] 2003-06-24 05:26 --- Created an attachment (id=6952) [PATCH] patch to support adding of RegexpTest.java test cases - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add Noel J. Bergman as commons committer
Noel, you're already a jakarta committer right? Or has that changed since James left Jakarta? If you are, all u need is karma. Here's my +1 just in case. Noel J. Bergman wrote: Noel has expressed an interest in maintaining the relatively dead commons-dbcp project. I propose we add him as a commons committer. AND Serge Knystautas and Martin Poeschl, who have also expressed interest. Serge is the one who started this thread (and is already sitting at home editing DBCP); it makes no sense to skip over him. Serge and I came at this together from the James project to demonstrate that this is not one person's interest. --- Noel -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/fileupload/src/java/org/apache/commons/fileupload DefaultFileItem.java
martinc 2003/06/23 22:45:15 Modified:fileupload/src/java/org/apache/commons/fileupload DefaultFileItem.java Log: Fix a JavaDoc link. Revision ChangesPath 1.21 +5 -5 jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/DefaultFileItem.java Index: DefaultFileItem.java === RCS file: /home/cvs/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/DefaultFileItem.java,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- DefaultFileItem.java 1 Jun 2003 17:33:24 - 1.20 +++ DefaultFileItem.java 24 Jun 2003 05:45:15 - 1.21 @@ -515,7 +515,7 @@ * @return codetrue/code if the instance represents a simple form * field; codefalse/code if it represents an uploaded file. * - * @see #setIsFormField(boolean) + * @see #setFormField(boolean) * */ public boolean isFormField() - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/fileupload/src/java/org/apache/commons/fileupload FileUpload.java
martinc 2003/06/23 22:45:43 Modified:fileupload/src/java/org/apache/commons/fileupload FileUpload.java Log: Remove unused imports. Revision ChangesPath 1.23 +4 -9 jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/FileUpload.java Index: FileUpload.java === RCS file: /home/cvs/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/FileUpload.java,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- FileUpload.java 1 Jun 2003 17:33:24 - 1.22 +++ FileUpload.java 24 Jun 2003 05:45:43 - 1.23 @@ -63,11 +63,6 @@ package org.apache.commons.fileupload; -import java.io.File; -import java.util.List; -import javax.servlet.http.HttpServletRequest; - - /** * pHigh level API for processing file uploads./p * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Add Noel J. Bergman as commons committer
you're already a jakarta committer right? Or has that changed since James left Jakarta? If you are, all u need is karma. $ groups noel apcvs jakarta james I'm still in the Jakarta group, as are Serge and Martin. AFAIK, we just need karma for the module. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20981] - HTTPClient trace() calls a lot of overhead; consider isTraceEnabled() test
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20981. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20981 HTTPClient trace() calls a lot of overhead; consider isTraceEnabled() test --- Additional Comments From [EMAIL PROTECTED] 2003-06-23 06:12 --- Gordon, why do you think that the trace calls pose a significant overhead on HttpClient? Did you make any specific measurements? Please post figures. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21007] New: - method.getResponseBodyAsString() doesn't work for URL http://www.agalinks.com
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21007. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21007 method.getResponseBodyAsString() doesn't work for URL http://www.agalinks.com Summary: method.getResponseBodyAsString() doesn't work for URL http://www.agalinks.com Product: Commons Version: Nightly Builds Platform: PC OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: HttpClient AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] http://www.agalinks.com sends a redirect code (301 or 302), yet the method.getResponseBodyAsString() returns an empty string. The URL works fine in Lynx Internet Explorer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21007] - method.getResponseBodyAsString() doesn't work for URL http://www.agalinks.com
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21007. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21007 method.getResponseBodyAsString() doesn't work for URL http://www.agalinks.com [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER --- Additional Comments From [EMAIL PROTECTED] 2003-06-23 07:55 --- it redirects to a different host name: www.agaweb01.agalinks.com It is a known restriction of HttpClient. Please see http://jakarta.apache.org/commons/httpclient/redirects.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21007] - method.getResponseBodyAsString() doesn't work for URL http://www.agalinks.com
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21007. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21007 method.getResponseBodyAsString() doesn't work for URL http://www.agalinks.com [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2003-06-23 08:01 --- Thanks for the link, I did not know about the location response header. I had been parsing the response body for the URL, and for this particular site their response body was blank. I'll update my code to use the location header. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: URI URIUtil as a separate Commons project?
Hmm... looks like... most're intersted in some uri encoding methods. (at least in the mailing list) However, I will say that URI is generally a parser for some purposes with having some coder feature. As I look into Commons-Codec, well... bula...bula... And I think it's not a right choice. (I guess, probably they wouldn't think either) Sung-Gu, What do you mean by As I look into Commons-Codec, well... bula...bula...? Undoubtedly, URI specification doesn't belong to Commons-Codec. No one has ever suggested otherwise. The idea is to factor out only URL encoding/decoding logic that clearly does. 2) URI specification by itself is just one class. It hardly makes any sense in my opinion to make a package out of it, even though URI class is clearly useful beyond HttpClient. If you want make an jar, you'd better setup the build.xml when you tar it... This is not just about creating a separate jar file with URI spec implementation. The initial idea was to create Commons-URI sub-project out of existing URI spec implementation in HttpClient. However, as many pointed out, the overhead of maintaining a full fledged Jakarta Commons sub-project around what is essentially one class would be simply too much. This said, if you can write a proposal for Commons-URI sub-project and make a convincing case to the rest of the Jakarta Commons community, we will whole-heartedly support you. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20481] - HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20481. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20481 HttpClient does not properly handle 'application/x-www-form-urlencoded' encoding --- Additional Comments From [EMAIL PROTECTED] 2003-06-23 12:29 --- Hi Laura, Thank you for looking over the patch. I agree that we might want to spilt this functionality when moving to codec. For the moment though I think it's okay to keep it together. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 20481] - HttpClient does not properlyhandle 'application/x-www-form-urlencoded' encoding
I have just started working on URLEncoder/URLDecoder port to commons-codec, as there's a relative lull in HttpClient core development, anyway. I believe it's the right moment to get this done. Any objections to that? Please do. I think it's an excellent time to get started on it. Please let me know if you would like any assistance. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Coverage
Adrian,
Good of you to bring up the topic...
Adrian Sutton wrote:
Howdy all,
We now have a license for clover to analyze our test cases and am now
just starting to work through adding test cases to improve our code
coverage. I've very quickly come to the realization that 100% code
coverage may actually be a bad thing. I've gotten AuthChallengeParser
to 100% coverage now so let me use it as an example:
I think, like all code metrics, that coverage is a useful metric, but
one that can be just as misleading as any other code metric - for
example, lines of comments, or lines of code. It is just as easy to
have a false sense of security due to metrics such as this one. If you
consider a simple function like:
void doSomething(...) {
if (a) { ... }
if (b) { ... }
if (c) { ... }
...
}
Your coverage tool will tell you you've exercised 100% of the code
when you've only covered three of the eight possible ways through the
routine, and that is in a function without any looping. In any case,
the above function may either need detailed test cases that track for
all eight possibilities, or only three, depending on how the routine
works, and the contract it exposes, and how critical the code is.
So I would agree with your premise that 100% coverage could be a bad
thing, particularly if it lulls you into a false sense of security.
Also, given scarce resources, we should focus our time on testing those
areas that most need it, rather than simply improving the statistics.
On the other hand, now that we have the statistic, it should never go
_down_.
There are four test cases that I consider pedantic and 1 of those that
I really don't like. The pedantic ones are:
[snip]
Now, I don't mind what happens with any of these decisions to be
honest as none affect the actual behaviour of HttpClient - they are
very much edge cases. I would however like to set up a policy on the
types of test cases I should create (do we want to avoid testing
things like the pedantic things above) as well as the best way to keep
track of questionable or overly pedantic test cases. Currently I'm
just adding a // pedantic above any test case that seems pedantic and
a todo comment over anything that I think may require a change to the
code but isn't clearly a bug.
I figure from time to time I can provide a list of issues that need to
be considered as I work my way through the codebase.
I struggled with a project with reams of test code on getters and
setters, yet the value of those get/set functions and the tests that
went with them wasn't properly evaluated until late in the project. My
attitude would be to avoid adding such test cases, to the extent that
doing so does effectively enlarge the contract of the API. On the other
hand, where such tests already exists, I don't see much point in
removing them until they are actually in the way, either wrong or
testing deprecated functionality.
Personally, I'm hoping to achieve 100% test coverage firstly because
I've discovered how dependent I am on having good test cases while
working on HttpClient (most people don't have the detailed level of
knowledge that Mike and Oleg do and thus aren't aware that a change
will break some other section of code - NTLM is a regular victim of
this). Also, aiming for 100% coverage makes a very clear-cut decision
on when the job is done which make life easier as well and makes it
much more noticeable when new test cases need to be added.
Any thoughts?
If there is one thing I'd like to see with the testing code of
HttpClient, it is a better way to test without having to actually have a
connection to either local or remote host or proxy server. I'd
enhance SimpleConnection and SimpleConnectionManager so that we could
simulate more cases without actually having to resort to connecting to
actual servers. Putting in simulations of proxy handling, simulations
of dropped connections, NTLM, and so on, would be very cool. And I'd
like a way to do it so that you simply write a configuration file that
specifies what should be received and what the response should be.
Unfortunately, I've not had the time to tackle the problem, and this
week I'm spending my scarce open source time on the client side Slide
DAV library, to improve its compatibility with HttpClient.
Maybe someone else can run with the idea?
-Eric.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20981] - HTTPClient trace() calls a lot of overhead; consider isTraceEnabled() test
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20981. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20981 HTTPClient trace() calls a lot of overhead; consider isTraceEnabled() test --- Additional Comments From [EMAIL PROTECTED] 2003-06-23 18:41 --- Short version: updating to commons-logging 1.0.3 fixed the problem Longer version: I am profiling a web crawling application using the free JMechanic profiling plug-in for Eclipse. Previously with commons logging 1.0.2, Throwable.getStackTraceElement was taking over 30% of sampled CPU time, always triggered by HTTPClient's trace() calls. Now that Jdk14Logger has been updated to include the immediate test of logging level (as referred to in Adrian's comment), the overhead is negligible. Thanks for the comment that highlighted my logging library wasn't doing what it should! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
