RE: [collections] New class EnumerationUtils?
I'll go ahead a store a starter EnumerationUtils class tomorrow. As far as Sun goes, I wonder if they did do that internally and got some now my pretty code has compile warnings all over the place feedback. Or perhaps Sun feels self-deprecation is too much of an admission of guilt WRT now not so great design choices... Not marking these deprecated can't make Java any easier to teach, that's certain. Gary -Original Message- From: __matthewHawthorne [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 19:50 To: Jakarta Commons Developers List Subject: Re: [collections] New class EnumerationUtils? As you've pointed out, since there are already a few classes for working with Enumerations, I don't think it's such a bad idea to create EnumerationUtils in order to suit your needs. I say +1, go for it. Sometimes I wonder why Sun never deprecated Hashtable, Vector, and Enumeration... this unofficial deprecation thing doesn't make sense to me. David Graham wrote: --- Gary Gregory [EMAIL PROTECTED] wrote: The 2.1 Enumeration classes are: org.apache.commons.collections.iterators.EnumerationIterator Adapter to make Enumeration instances appear to be Iterator instances. org.apache.commons.collections.iterators.IteratorEnumeration Adapter to make an Iterator instance appear to be an Enumeration instance. So perhaps the anti Enumeration stance is more feeling than policy ;-) It seems that in a lot of cases, Enumerations enumerate over collection types of things as in ResourceBundle.getKeys() for example. Which is why (to me) an EnumerationUtils class seems at home here. More thoughts? Unfortunately, even though the dreaded Enumeration interface has been unofficially deprecated, important APIs like Servlet depend on it. I think anything that makes it easier to to deal with these legacy Enumerations is a good thing. David Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 11:56 To: Jakarta Commons Developers List Subject: Re: [collections] New class EnumerationUtils? Yes, we are pretty much anti Enumeration. There are some methods here and there though. Stephen - Original Message - From: __matthewHawthorne [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, October 27, 2003 7:36 PM Subject: Re: [collections] New class EnumerationUtils? The only problem is that Enumerations aren't really a part of the collections framework. Of course, this is just a technicality... but it may be the reason that a EnumerationUtils class hasn't been created. Cany anyone else confirm this? Gary Gregory wrote: Hello, In 2.1, I have code like: java.util.ResourceBundle resourceBundle = ... List keysList = IteratorUtils.toList(new EnumerationIterator(resourceBundle.getKeys())); Do we want an EnumerationUtils class, which, for now (a la XP) would have a toList() method and grow from there? Thanks, Gary - 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 you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] [collections] order-statistics tree (augmented red-black)
Sure, Determining something like 90% or 75% (order-statics) is O(n) time for n elements using most algorithms, however there is a technique of augmenting a red-black tree with the element's RANK (its global order) by doing this augmentation, and keeping track of the tree size, you can reduce the cost of order-statistics to O(lg n) time. Also, it requires a modification to both the insert and delete functions of the Red-Black tree, because any rotate-right or rotate-left functions must Repair the Augmented Data during the rotation. While I am not completely able to do this technique justice, there is a very good chapter (Chapter 14 of Corman, Leiserson, Rivest, and Stein) that discuss this augmentation technique. Maybe someone knows how to get an online copy of this chapter or a similar discussion. I Hope this Clarifys first email. Bryce -- - Original Message - DATE: Sat, 25 Oct 2003 11:48:38 From: J.Pietschmann [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Cc: Bryce Alcock wrote: I would like an order - statistics tree, Which behaves with the same running times as a standard red-black binary search tree. ... 1. Are there any plans to do something like this in either the Math, or Collections sections of Commons? I don't think so. I'm not quite familar with the term statistics tree. If it's a modification to rbtrees which optimizes for a predetermined ad-hoc statistic for modification or read access it should probably go into the collections module. If the statistic is calculated on the fly from the access, then, well, it should probably also go into the collections module. Could you explain a bit more? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Enter for a chance to win one year's supply of allergy relief! http://ad.doubleclick.net/clk;6413623;3807821;f?http://mocda3.com/1/c/563632/125699/307982/307982 This offer applies to U.S. Residents Only - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[BEANUTILS] patch for resultset
Ref: http://www.mail-archive.com/[EMAIL PROTECTED]/msg28389.html I sent a patch in a while back to allow mapping specific interface definitions to resultsets so that the returned dynabeans don't necessarily 100% map to the resulset metadata. It's useful when you have a service layer that needs to hand back data in a specific format, but it is not necessarily 100% matching the resultset's metadata (i.e. fields missing/etc). I've been eyeballing the activity and it looks as though there's little interest/time to review such a thing (or I did something wrong in the patch submission process?). Should I submit it through bugzilla or drop the issue? - This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [BEANUTILS] patch for resultset
Just as a follow-up after examining the reasoning, I exposed another reason I did this. DB2 (the version I'm using) maps all column names to UPPER_CASE and my Beans use the typical java camel-case. This allows me to do a automagic case-insensitive mapping between the resultset field names and the java class field names. I actually pass a WrapDynaClass into the consructor with the value-object class passed in and I get back DynaBeans with all the same field names as my value-object... No-muss, no-fuss... -Original Message- From: Mainguy, Mike [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 9:07 AM To: Jakarta Commons Developers List Subject: [BEANUTILS] patch for resultset Ref: http://www.mail-archive.com/[EMAIL PROTECTED]/msg28389.html I sent a patch in a while back to allow mapping specific interface definitions to resultsets so that the returned dynabeans don't necessarily 100% map to the resulset metadata. It's useful when you have a service layer that needs to hand back data in a specific format, but it is not necessarily 100% matching the resultset's metadata (i.e. fields missing/etc). I've been eyeballing the activity and it looks as though there's little interest/time to review such a thing (or I did something wrong in the patch submission process?). Should I submit it through bugzilla or drop the issue? - This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BEANUTILS] patch for resultset
I've seen the hint many times in the Jakarta lists, that it is better to post patches into bugzilla. there each issue is tracked, listed weekly and requires an explicit handling, closing. It is less likely that a patch in bugzilla gets lost as in the high volume commons-dev list. You got already a notice from someone that considers your patch to be useful. So either a committer jumps into this thread or you post you patch to bugzilla... Cheers, Christoph Mainguy, Mike wrote: Ref: http://www.mail-archive.com/[EMAIL PROTECTED]/msg28389.html I sent a patch in a while back to allow mapping specific interface definitions to resultsets so that the returned dynabeans don't necessarily 100% map to the resulset metadata. It's useful when you have a service layer that needs to hand back data in a specific format, but it is not necessarily 100% matching the resultset's metadata (i.e. fields missing/etc). I've been eyeballing the activity and it looks as though there's little interest/time to review such a thing (or I did something wrong in the patch submission process?). Should I submit it through bugzilla or drop the issue? - This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- :) Christoph Reck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [BEANUTILS] patch for resultset
Thanks, I'll post it into bugzilla... I know that the instructions say to post patches there, but, I had also heard it is ok to just post them into the mailing list (of course, that was a different mailing list). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 11:27 AM To: Jakarta Commons Developers List Subject: Re: [BEANUTILS] patch for resultset I've seen the hint many times in the Jakarta lists, that it is better to post patches into bugzilla. there each issue is tracked, listed weekly and requires an explicit handling, closing. It is less likely that a patch in bugzilla gets lost as in the high volume commons-dev list. You got already a notice from someone that considers your patch to be useful. So either a committer jumps into this thread or you post you patch to bugzilla... Cheers, Christoph Mainguy, Mike wrote: Ref: http://www.mail-archive.com/[EMAIL PROTECTED]/msg28389.html I sent a patch in a while back to allow mapping specific interface definitions to resultsets so that the returned dynabeans don't necessarily 100% map to the resulset metadata. It's useful when you have a service layer that needs to hand back data in a specific format, but it is not necessarily 100% matching the resultset's metadata (i.e. fields missing/etc). I've been eyeballing the activity and it looks as though there's little interest/time to review such a thing (or I did something wrong in the patch submission process?). Should I submit it through bugzilla or drop the issue? - This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- :) Christoph Reck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24184] New: - HelpFormatter doesn't sort options properly
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=24184. 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=24184 HelpFormatter doesn't sort options properly Summary: HelpFormatter doesn't sort options properly Product: Commons Version: Nightly Builds Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: CLI AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] HelpFormatter is using an inner class Comparator implementation to sort Option objects, however it seems to be a bit confused about what types of object it is sorting. The inner class is called StringBufferComparator, although it's actually sorting Option objects. Further, it simply compares the object's toString() values rather than using the getKey() method which would perform the sort that the comments seem to indicate is desired. The sort that is actually performed doesn't appear to modify the ordering of the list at all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24185] New: - Enhancement to ResultSetDynaClass to allow case-insensitive and missing parameter bean mapping
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=24185.
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=24185
Enhancement to ResultSetDynaClass to allow case-insensitive and missing parameter bean
mapping
Summary: Enhancement to ResultSetDynaClass to allow case-
insensitive and missing parameter bean mapping
Product: Commons
Version: 1.0 Alpha
Platform: Other
OS/Version: Other
Status: NEW
Severity: Enhancement
Priority: Other
Component: Bean Utilities
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
##This is a 1 file patch for JDBCDynaClass and ResultSetDynaClass to allow more
##flexibility in the mapping of variable names to bean attributes.
##e.g. PROJNBR in resultset will automatically get mapped to ProjNbr or PrOjNbR
##in bean. class returned by iterator will not fail if there are fewer fields
##in resultset than in input bean.
--- JDBCDynaClass.orig 2003-10-14 11:40:20.0 -0400
+++ JDBCDynaClass.java 2003-10-13 11:39:49.0 -0400
@@ -69,11 +69,13 @@
import java.util.HashMap;
import java.util.Map;
+
/**
* pProvides common logic for JDBC implementations of [EMAIL PROTECTED]
DynaClass}./p
*
* @author Craig R. McClanahan
* @author George Franciscus
+ * @author Michael Mainguy
* @version $Revision: 1.3 $ $Date: 2003/10/09 20:43:15 $
*/
@@ -256,6 +258,48 @@
}
-}
+ /**
+* pIntrospect the metadata associated with our result set, and
populate
+* the codeproperties/code and codepropertiesMap/code instance
+* variables./p
+*
+* @param resultSet The coderesultSet/code whose metadata is to
+* be introspected
+* @param resultSet The codeDynaClass/code whose properties we want
+* to use
+*
+* @exception SQLException if an error is encountered processing the
+* result set metadata
+*
+*/
+ protected void introspect(ResultSet resultSet, DynaClass dynaClass)
throws SQLException {
+ HashMap propmap = new HashMap();
+ DynaProperty[] props = dynaClass.getDynaProperties();
+ for (int i = 0; i props.length; i++) {
+ propmap.put(props[i].getName().toLowerCase(), props[i]);
+
+ }
+ // Accumulate an ordered list of DynaProperties
+ ArrayList list = new ArrayList();
+ ResultSetMetaData metadata = resultSet.getMetaData();
+ int n = metadata.getColumnCount();
+ for (int i = 1; i = n; i++) { // JDBC is one-relative!
+ DynaProperty dynaProperty = (DynaProperty)propmap.get
(metadata.getColumnName(i).toLowerCase());
+ if (dynaProperty != null) {
+ list.add(dynaProperty);
+ }
+ }
+
+ // Convert this list into the internal data structures we need
+ properties =
+ (DynaProperty[]) list.toArray(new DynaProperty[list.size
()]);
+ for (int i = 0; i properties.length; i++) {
+ propertiesMap.put(properties[i].getName(), properties
[i]);
+ }
+
+ }
+
+
+}
--- ResultSetDynaClass.orig 2003-10-14 11:39:15.0 -0400
+++ ResultSetDynaClass.java 2003-10-13 11:39:47.0 -0400
@@ -123,145 +123,171 @@
* /pre
*
* @author Craig R. McClanahan
+ * @author Michael Mainguy
* @version $Revision: 1.13 $ $Date: 2003/10/09 20:43:15 $
*/
public class ResultSetDynaClass extends JDBCDynaClass implements DynaClass {
- // ---
Constructors
+// --- Constructors
- /**
-* pConstruct a new ResultSetDynaClass for the specified
-* codeResultSet/code. The property names corresponding
-* to column names in the result set will be lower cased./p
-*
-* @param resultSet The result set to be wrapped
-*
-* @exception NullPointerException if coderesultSet/code
-* is codenull/code
-* @exception SQLException if the metadata for this result set
-* cannot be introspected
-*/
- public ResultSetDynaClass(ResultSet resultSet) throws SQLException {
- this(resultSet, true);
- }
+/**
+ * pConstruct a new ResultSetDynaClass for the specified
+ * codeResultSet/code. The property names corresponding
+ * to column names in the result set will be lower cased./p
+ *
+ * @param resultSet The
DO NOT REPLY [Bug 24184] - HelpFormatter doesn't sort options properly
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=24184. 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=24184 HelpFormatter doesn't sort options properly --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 17:14 --- Created an attachment (id=8773) patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24185] - Enhancement to ResultSetDynaClass to allow case-insensitive and missing parameter bean mapping
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=24185. 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=24185 Enhancement to ResultSetDynaClass to allow case-insensitive and missing parameter bean mapping --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 17:14 --- Created an attachment (id=8774) JDBCDynaClass patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24185] - Enhancement to ResultSetDynaClass to allow case-insensitive and missing parameter bean mapping
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=24185. 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=24185 Enhancement to ResultSetDynaClass to allow case-insensitive and missing parameter bean mapping --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 17:14 --- Created an attachment (id=8775) path for ResultsetDynaClass - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections EnumerationUtils.java
ggregory2003/10/28 10:47:47
Added: collections/src/java/org/apache/commons/collections
EnumerationUtils.java
Log:
New class EnumerationUtils.
Revision ChangesPath
1.1
jakarta-commons/collections/src/java/org/apache/commons/collections/EnumerationUtils.java
Index: EnumerationUtils.java
===
/*
* $Header:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/EnumerationUtils.java,v
1.1 2003/10/28 18:47:47 ggregory Exp $
*
*
* 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 acknowledgement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgement may appear in the software itself,
*if and wherever such third-party acknowledgements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*/
package org.apache.commons.collections;
import java.util.Enumeration;
import java.util.List;
import org.apache.commons.collections.iterators.EnumerationIterator;
/**
* Provides utility methods for [EMAIL PROTECTED] Enumeration} instances.
*
* @author a href=mailto:[EMAIL PROTECTED]Gary Gregory/a
* @version $Id: EnumerationUtils.java,v 1.1 2003/10/28 18:47:47 ggregory Exp $
*/
public class EnumerationUtils {
/**
* Do not instantiate.
*/
private EnumerationUtils() {
// no init.
}
/**
* Creates a list based on an enumeration.
*
* pAs the enumeration is traversed, an ArrayList of its values is
* created. The new list is returned./p
*
* @param enumeration the enumeration to traverse, which should not be
codenull/code.
* @throws codeNullPointerException/code if the enumeration parameter is
codenull/code.
*/
public static List toList(Enumeration enumeration) {
return IteratorUtils.toList(new EnumerationIterator(enumeration));
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections TestEnumerationUtils.java
ggregory2003/10/28 10:48:10
Added: collections/src/test/org/apache/commons/collections
TestEnumerationUtils.java
Log:
New class EnumerationUtils.
Revision ChangesPath
1.1
jakarta-commons/collections/src/test/org/apache/commons/collections/TestEnumerationUtils.java
Index: TestEnumerationUtils.java
===
/*
* $Header:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/TestEnumerationUtils.java,v
1.1 2003/10/28 18:48:10 ggregory Exp $
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2001-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowledgement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgement may appear in the software itself,
*if and wherever such third-party acknowledgements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*/
package org.apache.commons.collections;
import java.util.ArrayList;
import java.util.Hashtable;
import java.util.List;
import java.util.StringTokenizer;
import junit.framework.Assert;
import junit.framework.TestCase;
/**
* Tests EnumerationUtils.
*
* @author a href=mailto:[EMAIL PROTECTED]Gary Gregory/a
* @version $Id: TestEnumerationUtils.java,v 1.1 2003/10/28 18:48:10 ggregory Exp $
*/
public class TestEnumerationUtils extends TestCase {
public static final String TO_LIST_FIXTURE = this is a test;
public void testToListWithStringTokenizer() {
List expectedList1 = new ArrayList();
StringTokenizer st = new StringTokenizer(TO_LIST_FIXTURE);
while (st.hasMoreTokens()) {
expectedList1.add(st.nextToken());
}
List expectedList2 = new ArrayList();
expectedList2.add(this);
expectedList2.add(is);
expectedList2.add(a);
expectedList2.add(test);
List actualList = EnumerationUtils.toList(new
StringTokenizer(TO_LIST_FIXTURE));
Assert.assertEquals(expectedList1, expectedList2);
Assert.assertEquals(expectedList1, actualList);
Assert.assertEquals(expectedList2, actualList);
}
public void testToListWithHashtable() {
Hashtable expected = new Hashtable();
expected.put(one, new Integer(1));
expected.put(two, new Integer(2));
expected.put(three, new Integer(3));
// validate elements.
List actualEltList =
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections TestEnumerationUtils.java TestAll.java
ggregory2003/10/28 10:56:12
Modified:collections/src/test/org/apache/commons/collections
TestEnumerationUtils.java TestAll.java
Log:
Integrate TestEnumerationUtils into test suite.
Revision ChangesPath
1.2 +12 -4
jakarta-commons/collections/src/test/org/apache/commons/collections/TestEnumerationUtils.java
Index: TestEnumerationUtils.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/TestEnumerationUtils.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TestEnumerationUtils.java 28 Oct 2003 18:48:10 - 1.1
+++ TestEnumerationUtils.java 28 Oct 2003 18:56:12 - 1.2
@@ -63,7 +63,7 @@
import java.util.StringTokenizer;
import junit.framework.Assert;
-import junit.framework.TestCase;
+import junit.framework.Test;
/**
* Tests EnumerationUtils.
@@ -71,7 +71,11 @@
* @author a href=mailto:[EMAIL PROTECTED]Gary Gregory/a
* @version $Id$
*/
-public class TestEnumerationUtils extends TestCase {
+public class TestEnumerationUtils extends BulkTest {
+
+public TestEnumerationUtils(String name) {
+super(name);
+}
public static final String TO_LIST_FIXTURE = this is a test;
@@ -120,6 +124,10 @@
expectedKeyList.add(two);
expectedKeyList.add(three);
Assert.assertTrue(actualKeyList.containsAll(expectedKeyList));
+}
+
+public static Test suite() {
+return BulkTest.makeSuite(TestEnumerationUtils.class);
}
}
1.51 +3 -2
jakarta-commons/collections/src/test/org/apache/commons/collections/TestAll.java
Index: TestAll.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/TestAll.java,v
retrieving revision 1.50
retrieving revision 1.51
diff -u -r1.50 -r1.51
--- TestAll.java 6 Oct 2003 23:47:17 - 1.50
+++ TestAll.java 28 Oct 2003 18:56:12 - 1.51
@@ -115,6 +115,7 @@
suite.addTest(TestStaticBucketMap.suite());
suite.addTest(TestTreeBag.suite());
suite.addTest(TestUnboundedFifoBuffer.suite());
+suite.addTest(TestEnumerationUtils.suite());
return suite;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24191] New: - OptionBuilder only has static methods, yet many return an OptionBuilder instance
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=24191. 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=24191 OptionBuilder only has static methods, yet many return an OptionBuilder instance Summary: OptionBuilder only has static methods, yet many return an OptionBuilder instance Product: Commons Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: CLI AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] First of all, I think CLI is great. However, the OptionBuilder really gets my goat. All of the methods are static, yet all, except the create() methods, return an OptionBuilder instance. Presumably this is to allow us to chain calls to the builder, but by chaining calls, we are calling static methods through an instance, which is generally considered bad form. Also, it doesn't really qualify as an instance of the Builder Pattern in its current form since it does not meet the intent: 'Separate the construction of a complex object from its representation so that the same construction process can create different representations' (this is because of the static methods). Why not make the methods non-static and get the client to create an instance of the builder before proceeding? In it's current form, it seems a bit schizophrenic. Regards, Lance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DIGESTER] Fix maven build
patch applied. many thanks.
(i'm not convinced that the maven-driven tests run correctly from java 1.3
but since the maven build is subsidary, i'll leave this for someone else
to patch :)
- robert
On Sunday, October 26, 2003, at 05:21 PM, Henning P. Schmiedehausen wrote:
The current CVS head doesn't build right with maven. The DTD files
are not included into the final jar. Please apply this patch (it also
moves the current build version to 1.6-dev and stops overwriting the
existing 1.5 release):
--- cut ---
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons/digester/project.xml,v
retrieving revision 1.13
diff -u -b -r1.13 project.xml
--- project.xml 10 Aug 2003 18:56:11 - 1.13
+++ project.xml 26 Oct 2003 17:18:55 -
@@ -4,7 +4,7 @@
extend../project.xml/extend
nameDigester/name
idcommons-digester/id
- currentVersion1.5/currentVersion
+ currentVersion1.6-dev/currentVersion
inceptionYear2001/inceptionYear
shortDescriptionRule based XML-Java object mapping
module/shortDescription
descriptionThe Digester package lets you configure an XML-Java
object mapping module which triggers certain actions called rules
whenever a particular pattern of nested XML elements is
recognized./description
@@ -117,6 +117,14 @@
/dependencies
build
+resources
+ resource
+ directory${pom.build.sourceDirectory}/directory
+ includes
+ include**/*.dtd/include
+ /includes
+ /resource
+/resources
unitTest
includes
include**/*Test.java/include
--- cut ---
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
Dominate!! Dominate!! Eat your young and aggregate! I have grotty
silicon!
-- AOL CD when played backwards (User Friendly - 200-10-15)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester/xmlrules DigesterRuleParser.java
rdonkin 2003/10/28 14:31:02
Modified:digester/src/java/org/apache/commons/digester/xmlrules
DigesterRuleParser.java
Log:
This is an adapted version of the contributed patch. It should ensure that the
current behaviour is preserved (allowing rules to be added that begin with a slash)
whilst also ensure that the documented behaviour is also allowed. Original patch
contributed by Henning P. Schmiedehausen.
Revision ChangesPath
1.21 +10 -4
jakarta-commons/digester/src/java/org/apache/commons/digester/xmlrules/DigesterRuleParser.java
Index: DigesterRuleParser.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/xmlrules/DigesterRuleParser.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- DigesterRuleParser.java 23 Oct 2003 20:06:09 - 1.20
+++ DigesterRuleParser.java 28 Oct 2003 22:31:02 - 1.21
@@ -456,7 +456,13 @@
* by concatenating the pattern prefix with the given pattern.
*/
public void add(String pattern, Rule rule) {
-delegate.add(prefix + pattern, rule);
+StringBuffer buffer = new StringBuffer();
+buffer.append(prefix);
+if (!pattern.startsWith(/)) {
+buffer.append('/');
+}
+buffer.append(pattern);
+delegate.add(buffer.toString(), rule);
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/test/org/apache/commons/digester/xmlrules IncludeTest.java DigesterLoaderTestSuite.java
rdonkin 2003/10/28 14:31:54 Modified:digester/src/test/org/apache/commons/digester/xmlrules DigesterLoaderTestSuite.java Added: digester/src/test/org/apache/commons/digester/xmlrules IncludeTest.java Log: Test case for the adapted version of the contributed patch. It should ensure that the current behaviour is preserved (allowing rules to be added that begin with a slash) whilst also ensure that the documented behaviour is also allowed. Original patch contributed by Henning P. Schmiedehausen. Revision ChangesPath 1.7 +4 -3 jakarta-commons/digester/src/test/org/apache/commons/digester/xmlrules/DigesterLoaderTestSuite.java Index: DigesterLoaderTestSuite.java === RCS file: /home/cvs/jakarta-commons/digester/src/test/org/apache/commons/digester/xmlrules/DigesterLoaderTestSuite.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- DigesterLoaderTestSuite.java 23 Oct 2003 20:07:02 - 1.6 +++ DigesterLoaderTestSuite.java 28 Oct 2003 22:31:54 - 1.7 @@ -88,6 +88,7 @@ suite.addTestSuite(DigesterLoaderTest.class); suite.addTestSuite(DigesterPatternStackTest.class); suite.addTestSuite(DigesterLoaderRulesTest.class); +suite.addTestSuite(IncludeTest.class); return suite; } 1.1 jakarta-commons/digester/src/test/org/apache/commons/digester/xmlrules/IncludeTest.java Index: IncludeTest.java === /* * $Header: /home/cvs/jakarta-commons/digester/src/test/org/apache/commons/digester/xmlrules/IncludeTest.java,v 1.1 2003/10/28 22:31:54 rdonkin Exp $ * $Revision: 1.1 $ * $Date: 2003/10/28 22:31:54 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 2001-2003 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, *if any, must include the following acknowledgement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgement may appear in the software itself, *if and wherever such third-party acknowledgements normally appear. * * 4. The names Apache, 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, *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.digester.xmlrules; import java.util.ArrayList; import java.io.StringReader; import junit.framework.TestCase; import junit.framework.TestSuite; import org.xml.sax.InputSource; import org.apache.commons.digester.Digester; import
Re: [DIGESTER] Fix xmlrules include class= rule
hi henning
i've committed an adapted version of the patch you supplied. my version
preserves the existing behaviour (for backwards compatibility) whilst also
allowing the documented behaviour, please remember to supply a test case
with any future next patches.
- robert
On Sunday, October 26, 2003, at 05:28 PM, Henning P. Schmiedehausen wrote:
According to the example in the xmlrules package-summary, adding a
programmatic rule to a XML digester rules file should work like this:
--- cut --
digester-rules
pattern value=root/foo
include class=BarRuleCreator/
/pattern
/digester-rules
--- cut ---
--- cut ---
public class BarRuleCreator implements DigesterRulesSource {
public void getRules(Digester digester) {
digester.addObjectCreate(bar, Bar);
}
}
--- cut ---
In fact, it does not. One needs digester.addObjectCreate(/bar, Bar);
because of this bug:
--- cut ---
Index:
src/java/org/apache/commons/digester/xmlrules/DigesterRuleParser.java
===
RCS file: /home/cvs/jakarta-commons/digester/src/java/org/apache/commons/
digester/xmlrules/DigesterRuleParser.java,v
retrieving revision 1.20
diff -u -b -r1.20 DigesterRuleParser.java
--- src/java/org/apache/commons/digester/xmlrules/DigesterRuleParser.java
23 Oct 2003 20:06:09 - 1.20
+++ src/java/org/apache/commons/digester/xmlrules/DigesterRuleParser.java
26 Oct 2003 17:18:55 -
@@ -447,7 +447,7 @@
* pass through to this object.
*/
public RulesPrefixAdapter(String patternPrefix, Rules rules) {
-prefix = patternPrefix;
+prefix = patternPrefix + /;
delegate = rules;
}
--- cut ---
Please apply. Finding this cost me most of my sunday. :-)
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
Dominate!! Dominate!! Eat your young and aggregate! I have grotty
silicon!
-- AOL CD when played backwards (User Friendly - 200-10-15)
-
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: [digester] populating beans fixed to BeanUtils?
hi ricky beanutils adds quite a few powerful features which (seems to me to) justify these dependencies. there are some good reasons why it might be useful to abstract the actual population from the mechanism used to perform the population. i'm not sure whether the best way to do this would be through delegation to a strategy interface or through inheritance. i'd be interested to here other people's views on this. i don't seem to get as much coding time as i'd like these days so i probably won't get round to coding this any time soon but patches (including test cases ;) would be gratefully received. - robert On Friday, October 24, 2003, at 08:09 AM, Ricky Panaglucci wrote: simon, BeanUtils does the actual setting of properties. there are many other JavaSpec conforming utilities. (i use castor for introspection and generating relevant information) you are right, i can always use new rules... i still feel the dependency on BeanUtils in the populate() and setProperty() cases is too much - while ok in CallMethodRule etc ricardo --- Simon Kitching [EMAIL PROTECTED] wrote: On Wed, 2003-10-22 at 11:27, Ricky Panaglucci wrote: hello, is it by design, that SetPropertyRule and SetPropertiesRule use BeanUtils.populate()? it would be usefull to use other binders as well. Well, the term property in the name of these rules is intended to refer to the definition of a JavaBean property as per the official JavaBean specification. The BeanUtils library implements that specification, so there doesn't seem to be much need for allowing the user to configure alternate implementations. If you do wish to map xml attributes to class methods in a way other than the JavaBean spec defines, you can always create your own rule, like SetRicardoPropertyRule(...) which uses some other algorithm for determining which method to invoke on an object given an xml attribute or element name. What other binder do you have in mind? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk - 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 24191] - OptionBuilder only has static methods, yet many return an OptionBuilder instance
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=24191. 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=24191 OptionBuilder only has static methods, yet many return an OptionBuilder instance [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 22:47 --- The version 2 code has this resolved. Check out the source in the commons sandbox under the org.apache.commons.cli2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24191] - OptionBuilder only has static methods, yet many return an OptionBuilder instance
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=24191. 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=24191 OptionBuilder only has static methods, yet many return an OptionBuilder instance [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 22:51 --- Excellent. Thanks very much. Regards, Lance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24191] - OptionBuilder only has static methods, yet many return an OptionBuilder instance
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=24191. 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=24191 OptionBuilder only has static methods, yet many return an OptionBuilder instance [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/cli/src/test/org/apache/commons/cli2 ApplicationTest.java
jkeyes 2003/10/28 14:53:59 Modified:cli/src/test/org/apache/commons/cli2 ApplicationTest.java Log: - removed unused import Revision ChangesPath 1.4 +3 -5 jakarta-commons-sandbox/cli/src/test/org/apache/commons/cli2/ApplicationTest.java Index: ApplicationTest.java === RCS file: /home/cvs/jakarta-commons-sandbox/cli/src/test/org/apache/commons/cli2/ApplicationTest.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- ApplicationTest.java 24 Oct 2003 18:49:48 - 1.3 +++ ApplicationTest.java 28 Oct 2003 22:53:59 - 1.4 @@ -60,8 +60,6 @@ */ package org.apache.commons.cli2; -import java.util.List; - import junit.framework.Test; import junit.framework.TestCase; import junit.framework.TestSuite; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] why private XXXRule in DigesterRuleParser?
hi ricardo
i think i understand what you code is doing (in general terms). the idea
is that you're adding your own rules to the existing xml-rules so that
they can be used for parsing, right?
i've taken a look at the code in DigesterRuleParser i'm not too sure that
your plan would work. the inner classes cannot simply be extracted to
public scope without some refactoring.
i was wondering:
1. whether anyone would really need to subclass PatternRule - or whether a
factory method would be good enough.
2. whether it's only PatternRule that really needs more public scope.
answers anyone?
- robert
On Tuesday, October 21, 2003, at 11:23 PM, Ricky Panaglucci wrote:
hello,
below is a case, where the existing PatternRule would
be usefull
ricardo
myrules.xml:
digester-rules
pattern value=*/MyObject
object-create-rule classname=MyObject/
set-generic-property-rule pattern=attr
name=name value=value/
/pattern
/digester-rules
myobject.xml:
?xml version=1.0?
jLab
MyObject
attr name=att1 value=val1/
attr name=att2 value=val2/
/MyObject
/jLab
Digester d=new Digester()
DigesterRuleParser drp=new
DigesterRuleParser(d);
d.addFactoryCreate(*/set-generic-property-rule, new
SetGenericPropertyRuleFactory());
//*** would like to write
d.addRule(*/set-generic-property-rule, drp.new
PatternRule(pattern));
d.addRule(*/set-generic-property-rule, new
XPatternRule(pattern));
d.addSetNext(*/set-generic-property-rule,
add, Rule.class.getName());
RuleSet ruleSet = new FromXmlRuleSet(new
Files(myrules).toURL(), drp, d);
d.addRuleSet(ruleSet);
MyObject obj = (MyObject)d.parse(new
File(myobject.xml);
public class SetGenericPropertyRuleFactory extends
AbstractObjectCreationFactory {
public SetGenericPropertyRuleFactory() {
}
public Object createObject(Attributes
attributes) {
String name = attributes.getValue(name);
String value = attributes.getValue(value);
return new GenericPropertyRule( name,
value);
}
}
public class GenericPropertiesRule extends Rule {
//***source copied from SetPropertyRule with some
}
public class XPatternRule {
//***source copied from PatternRule
}
--- robert burrell donkin
[EMAIL PROTECTED] wrote: +1
i'd be happy to see the nested classed in the
xmlrules made public if a
need could be demonstrated.
- robert
On Monday, October 20, 2003, at 10:12 PM, Simon
Kitching wrote:
Hi Ricky,
You must be referring to
xmlrules/DigesterRuleParser.java
I'm no expert on the xmlrules package.
However it is normal practice for classes created
solely for the purpose
of implementing function X to be declared private.
The PatternRule class appears to have been created
*not* with the
intention of providing additional services to
users of Digester, but
solely as an implementation detail of the xmlrules
functionality. As
such, private seems the appropriate scope to me.
If you feel that the functionality of the
PatternRule is useful outside
of the xmlrules package, then consideration could
be given to
promoting the class to public.
Note however that any class or method declared
public (or protected) is
part of the public interface to a package, and
must:
(a) be documented much more thoroughly than
private/package classes
(b) be backwards-compatible in future releases
(c) be deprecated before removal
So a class really should only be public if it
needs to be.
Regards,
Simon
On Tue, 2003-10-21 at 10:02, Ricky Panaglucci
wrote:
hello,
why do classes like PatternRule have private
access?
now, for adding my own rules which may use
surrounding
pattern, i just copied the PatternRule source
[very
brown imho]
why not make them protected or public?
ricardo
Want to chat instantly with your online friends?
Get the FREE Yahoo!
Messenger http://mail.messenger.yahoo.co.uk
-
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]
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://mail.messenger.yahoo.co.uk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester/xmlrules DigesterLoader.java
rdonkin 2003/10/28 15:01:00
Modified:digester/src/java/org/apache/commons/digester Digester.java
digester/src/java/org/apache/commons/digester/xmlrules
DigesterLoader.java
Log:
Correct mistakes I made in javadocs (Doh!). Patch contributed by Simon Kitching.
Revision ChangesPath
1.85 +5 -5
jakarta-commons/digester/src/java/org/apache/commons/digester/Digester.java
Index: Digester.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/Digester.java,v
retrieving revision 1.84
retrieving revision 1.85
diff -u -r1.84 -r1.85
--- Digester.java 19 Oct 2003 19:35:40 - 1.84
+++ Digester.java 28 Oct 2003 23:01:00 - 1.85
@@ -604,7 +604,7 @@
/**
* Sets the logger used for logging SAX-related information.
* strongNote/strong the output is finely grained.
- * @param log Log, not null
+ * @param saxLog Log, not null
*/
public void setSAXLogger(Log saxLog) {
1.10 +5 -5
jakarta-commons/digester/src/java/org/apache/commons/digester/xmlrules/DigesterLoader.java
Index: DigesterLoader.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/xmlrules/DigesterLoader.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- DigesterLoader.java 22 Oct 2003 18:28:57 - 1.9
+++ DigesterLoader.java 28 Oct 2003 23:01:00 - 1.10
@@ -88,7 +88,7 @@
/**
* Creates a new digester and initializes it from the specified InputSource
- * @param inputSource load the xml rules from this InputSource
+ * @param rulesSource load the xml rules from this InputSource
* @return a new Digester initialized with the rules
*/
public static Digester createDigester(InputSource rulesSource) {
@@ -103,7 +103,7 @@
* This constructor allows the digester to be used to load the rules to be
specified.
* This allows properties to be configured on the Digester instance before it
is used.
*
- * @param inputSource load the xml rules from this InputSource
+ * @param rulesSource load the xml rules from this InputSource
* @param rulesDigester digester to load the specified XML file.
* @return a new Digester initialized with the rules
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] patch for javadoc build warnings
good catch simon. - robert On Monday, October 27, 2003, at 10:08 PM, Simon Kitching wrote: Hi, Two recent commits (to Digester.java and xmlrules/DigesterLoader.java) have introduced javadoc which generates a warning when built. example: [javadoc] /home/simon/apache/commons-cvs/jakarta- commons/digester/src/java/org/apache/commons/digester/xmlrules/DigesterLoader. java:94: warning - @param argument inputSource is not a parameter name. Attached is a (trivial) patch to fix these problems. Regards, Simon - 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]
Handling Yahoo redirect...
When loggin in to Yahoo mail, after a successful post of data the following URL is returned... http://login.yahoo.com/config/verify?.done=http%3a//my.yahoo.com When I redirect the connection to that URL then I get the exception... WARNING: Invalid Redirect URI from: http://login.yahoo.com:80/config/verify to: http://my.yahoo.com I understand I need to handle this manually, but I'm unsure how to proceed. Anyone solved this before me? Regards, Joe Ryburn Affiliated Foods Southwest 12103 Interstate 30 Little Rock, AR 72203-3627 501-455-3590 extension 6319
RE: [dbcp] Trying to track/find a connection leak in DBCP 1.1
I believe we have identified the problem and it is NOT a DBCP or POOL source
issue. I feel pretty sheepish/egg on the face/choose your favorite
embarassment metaphor. It turns out that our deployment script screwed up
and was bundling both 1.1 DBCP and 1.0 DBCP. The appserver was picking up
DBCP 1.0 instead of DBCP 1.1 and then picking up Pool 1.1. Pool 1.1 and
DBCP 1.0 is a BAD combination. Do NOT do this!!! Anyway, this solved the
problem on my system. Our perf/scalablity test team is starting a run
tonight. Tomorrow I will be able to confirm the result.
However, I did learn quite a bit about DBCP and Pool and see some areas
where improvements can be made.
Thanks for your attention and hopefully I did not waste too much of your
time.
ToddC
-Original Message-
From: Todd Carmichael [mailto:[EMAIL PROTECTED]
Sent: Monday, October 27, 2003 10:46 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [dbcp] Trying to track/find a connection leak in DBCP 1.1
I did perform this test. Perhaps the original email was not clear in
referencing the test of using JndiDataSourceFactory and that no leaks
occurred.
ToddC
-Original Message-
From: Juozas Baliuka [mailto:[EMAIL PROTECTED]
Sent: Monday, October 27, 2003 9:53 AM
To: Jakarta Commons Developers List
Subject: Re: [dbcp] Trying to track/find a connection leak in DBCP 1.1
Try to run app without pool first to find broken component. Most of
Connection leak problems are in applications and it is not easy to trust
this test.
- Original Message -
From: Todd Carmichael [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, October 27, 2003 7:32 PM
Subject: [dbcp] Trying to track/find a connection leak in DBCP 1.1
Our scalability tests against our web application (350 concurrent
users in
a
web application using Tomcat 4.1.24 with JDK 1.4.2) is failing due to
a continual leak of database connections. The test failed in that the
number
of database connections (reported by the DB server: MS SQL Server)
grew to over a thousand during an hour plus test (using the microsoft
sql jdbc driver though we have tried the i-net driver with similar
results). We
know
that it is not a problem in the application because we have performed
identical tests except to configure Torque to use the
JndiDatasourceFactory.
This in passes the connection pooling chores to the appserver. Both
SunOne
appserver and Weblogic appserver maintained a valid number of
connections
(
75). We are using Torque 3.1 with DBCP 1.1 (using the
org.apache.commons.dbcp.datasources.SharedPoolDataSource) and Pool
1.1.
Our settings in our torque.properties (which can passed down to the
SHaredPoolDataSource) are:
torque.dsfactory.default.pool.maxActive=100
torque.dsfactory.default.pool.testOnBorrow=0
torque.dsfactory.default.pool.testOnReturn=0
#no setting for maxIdle. It defaults to 8. Not optimal but code
should still work:
torque.dsfactory.default.pool.timeBetweenEvictionRunsMillis=6
torque.dsfactory.default.pool.numTestsPerEvictionRun=-1
torque.dsfactory.default.pool.minEvictableIdleTimeMillis=1000
torque.dsfactory.default.pool.testWhileIdle=false
I have begun some debugging of this problem. I have added some debug
output
in the torqueInstance.getConnection to track size of the pool.
iCountConnections++;
if ((iCountConnections % 100)==0)
{
SharedPoolDataSource spds =
(SharedPoolDataSource)dsf.getDataSource();
log.warn(Current Num Active Connections= +
String.valueOf(spds.getNumActive()));
log.warn(Current Num Idle Connections= +
String.valueOf(spds.getNumIdle()));
log.warn(Max Active = +
String.valueOf(spds.getMaxActive()));
log.warn(Max Idle = +
String.valueOf(spds.getMaxIdle()));
log.warn(Max Wait = +
String.valueOf(spds.getMaxWait()));
}
Here is a sample of the output when I run our scalability tests. At
this point the system is under heavy load and the db server is
reporting over
100
connections:
[WARN] TorqueInstance - -Current Num Active Connections=3 [WARN]
TorqueInstance - -Current Num Idle Connections=5 [WARN] TorqueInstance
- -Max Active =100 [WARN] TorqueInstance - -Max Idle =8
[WARN] TorqueInstance - -Max Wait =500
[WARN] TorqueInstance - -Current Num Active Connections=5
[WARN] TorqueInstance - -Current Num Idle Connections=3
[WARN] TorqueInstance - -Max Active =100
[WARN] TorqueInstance - -Max Idle =8
[WARN] TorqueInstance - -Max Wait =500
[WARN] TorqueInstance - -Current Num Active Connections=19
[WARN] TorqueInstance - -Current Num Idle Connections=0
[WARN] TorqueInstance - -Max Active =100
[WARN] TorqueInstance - -Max Idle =8
[WARN] TorqueInstance - -Max Wait =500
[WARN] TorqueInstance - -Current Num Active Connections=32
[WARN] TorqueInstance - -Current Num Idle Connections=0
[WARN] TorqueInstance - -Max Active =100
Re: [dbcp] Trying to track/find a connection leak in DBCP 1.1
I have been trying to reproduce using junit test but no luck yet.
So I have more questions:
Did you do your test with the JndiDataSourceFactory on the same multi CPU
system? On tomcat with the default datasource (BasicDataSource), settings?
Can you send me your complete tomcat/torque datasource configs?
To help debugging please download and use the following file:
http://cvs.apache.org/~dirkv/builds/KeyedCPDSConnectionFactory.java
I synchronized all methods and added some debug to stderr.
--- Dirk
Todd Carmichael wrote:
I did perform this test. Perhaps the original email was not clear in
referencing the test of using JndiDataSourceFactory and that no leaks
occurred.
ToddC
-Original Message-
From: Juozas Baliuka [mailto:[EMAIL PROTECTED]
Sent: Monday, October 27, 2003 9:53 AM
To: Jakarta Commons Developers List
Subject: Re: [dbcp] Trying to track/find a connection leak in DBCP 1.1
Try to run app without pool first to find broken component. Most of
Connection leak problems are in applications and it is not easy to trust
this test.
- Original Message -
From: Todd Carmichael [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, October 27, 2003 7:32 PM
Subject: [dbcp] Trying to track/find a connection leak in DBCP 1.1
Our scalability tests against our web application (350 concurrent
users in
a
web application using Tomcat 4.1.24 with JDK 1.4.2) is failing due to
a continual leak of database connections. The test failed in that the
number
of database connections (reported by the DB server: MS SQL Server)
grew to over a thousand during an hour plus test (using the microsoft
sql jdbc driver though we have tried the i-net driver with similar
results). We
know
that it is not a problem in the application because we have performed
identical tests except to configure Torque to use the
JndiDatasourceFactory.
This in passes the connection pooling chores to the appserver. Both
SunOne
appserver and Weblogic appserver maintained a valid number of
connections
(
75). We are using Torque 3.1 with DBCP 1.1 (using the
org.apache.commons.dbcp.datasources.SharedPoolDataSource) and Pool
1.1.
Our settings in our torque.properties (which can passed down to the
SHaredPoolDataSource) are:
torque.dsfactory.default.pool.maxActive=100
torque.dsfactory.default.pool.testOnBorrow=0
torque.dsfactory.default.pool.testOnReturn=0
#no setting for maxIdle. It defaults to 8. Not optimal but code
should still work:
torque.dsfactory.default.pool.timeBetweenEvictionRunsMillis=6
torque.dsfactory.default.pool.numTestsPerEvictionRun=-1
torque.dsfactory.default.pool.minEvictableIdleTimeMillis=1000
torque.dsfactory.default.pool.testWhileIdle=false
I have begun some debugging of this problem. I have added some debug
output
in the torqueInstance.getConnection to track size of the pool.
iCountConnections++;
if ((iCountConnections % 100)==0)
{
SharedPoolDataSource spds =
(SharedPoolDataSource)dsf.getDataSource();
log.warn(Current Num Active Connections= +
String.valueOf(spds.getNumActive()));
log.warn(Current Num Idle Connections= +
String.valueOf(spds.getNumIdle()));
log.warn(Max Active = +
String.valueOf(spds.getMaxActive()));
log.warn(Max Idle = +
String.valueOf(spds.getMaxIdle()));
log.warn(Max Wait = +
String.valueOf(spds.getMaxWait()));
}
Here is a sample of the output when I run our scalability tests. At
this point the system is under heavy load and the db server is
reporting over
100
connections:
[WARN] TorqueInstance - -Current Num Active Connections=3 [WARN]
TorqueInstance - -Current Num Idle Connections=5 [WARN] TorqueInstance
- -Max Active =100 [WARN] TorqueInstance - -Max Idle =8
[WARN] TorqueInstance - -Max Wait =500
[WARN] TorqueInstance - -Current Num Active Connections=5
[WARN] TorqueInstance - -Current Num Idle Connections=3
[WARN] TorqueInstance - -Max Active =100
[WARN] TorqueInstance - -Max Idle =8
[WARN] TorqueInstance - -Max Wait =500
[WARN] TorqueInstance - -Current Num Active Connections=19
[WARN] TorqueInstance - -Current Num Idle Connections=0
[WARN] TorqueInstance - -Max Active =100
[WARN] TorqueInstance - -Max Idle =8
[WARN] TorqueInstance - -Max Wait =500
[WARN] TorqueInstance - -Current Num Active Connections=32
[WARN] TorqueInstance - -Current Num Idle Connections=0
[WARN] TorqueInstance - -Max Active =100
[WARN] TorqueInstance - -Max Idle =8
[WARN] TorqueInstance - -Max Wait =500
[WARN] TorqueInstance - -Current Num Active Connections=39
[WARN] TorqueInstance - -Current Num Idle Connections=1
[WARN] TorqueInstance - -Max Active =100
[WARN] TorqueInstance - -Max Idle =8
[WARN] TorqueInstance - -Max Wait =500
[WARN] TorqueInstance - -Current Num Active Connections=40
[WARN] TorqueInstance - -Current Num Idle Connections=0
[WARN] TorqueInstance - -Max Active =100
[WARN] TorqueInstance - -Max Idle =8
[WARN] TorqueInstance -
cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester/plugins Declaration.java PluginCreateRule.java PluginDeclarationRule.java PluginManager.java PluginRules.java
rdonkin 2003/10/28 15:31:08
Modified:digester/src/java/org/apache/commons/digester/plugins
Declaration.java PluginCreateRule.java
PluginDeclarationRule.java PluginManager.java
PluginRules.java
Log:
Improvements to bring logging in line with the practice in the rest of digester.
Submitted by Simon Kitching.
Revision ChangesPath
1.5 +16 -9
jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/Declaration.java
Index: Declaration.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/Declaration.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Declaration.java 27 Oct 2003 13:37:35 - 1.4
+++ Declaration.java 28 Oct 2003 23:31:08 - 1.5
@@ -69,7 +69,6 @@
import org.apache.commons.beanutils.MethodUtils;
import org.apache.commons.digester.Digester;
import org.apache.commons.logging.Log;
-import org.apache.commons.logging.LogFactory;
/**
* Simple structure to store the set of attributes that can be present on
@@ -78,7 +77,6 @@
* @author Simon Kitching
*/
public class Declaration {
-private static Log log = LogFactory.getLog(Declaration.class);
/**
* The name of the method looked for on the plugin class and any
@@ -225,7 +223,11 @@
*/
public void init(Digester digester)
throws PluginWrappedException {
-log.debug(init being called!);
+Log log = digester.getLogger();
+boolean debug = log.isDebugEnabled();
+if (debug) {
+log.debug(init being called!);
+}
if (initialised_) {
throw new PluginAssertionError(Init called multiple times.);
@@ -292,7 +294,11 @@
public void configure(Digester digester, String pattern)
throws PluginWrappedException {
-log.debug(configure being called!);
+Log log = digester.getLogger();
+boolean debug = log.isDebugEnabled();
+if (debug) {
+log.debug(configure being called!);
+}
if (!initialised_) {
throw new PluginAssertionError(Not initialised.);
@@ -350,7 +356,7 @@
// look for rule class
{
-if (log.isDebugEnabled()) {
+if (debug) {
log.debug(plugin class type: + pluginClass_.getName());
}
String ruleClassName = pluginClass_.getName() + RuleInfo;
@@ -385,7 +391,7 @@
// try autoSetProperties
if (autoSetProperties_) {
-if (log.isDebugEnabled()) {
+if (debug) {
log.debug(adding autoset for pattern [ + pattern + ]);
}
digester.addSetProperties(pattern);
@@ -410,6 +416,7 @@
is.close();
}
catch(IOException ioe) {
+Log log = digester.getLogger();
log.warn(Unable to close stream after reading rules, ioe);
}
}
1.5 +19 -13
jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/PluginCreateRule.java
Index: PluginCreateRule.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/PluginCreateRule.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- PluginCreateRule.java 27 Oct 2003 13:37:35 - 1.4
+++ PluginCreateRule.java 28 Oct 2003 23:31:08 - 1.5
@@ -70,7 +70,6 @@
import org.apache.commons.digester.Rule;
import org.apache.commons.digester.Rules;
import org.apache.commons.logging.Log;
-import org.apache.commons.logging.LogFactory;
/**
* Allows the original rules for parsing the configuration file to define
@@ -81,8 +80,6 @@
*/
public class PluginCreateRule extends Rule implements InitializableRule {
-private static Log log = LogFactory.getLog(PluginCreateRule.class);
-
private static final String PLUGIN_CLASS_ATTR = plugin-class;
private static final String PLUGIN_ID_ATTR = plugin-id;
@@ -195,8 +192,12 @@
*/
public void postRegisterInit(String pattern)
throws PluginConfigurationException {
-log.debug(PluginCreateRule.postRegisterInit +
- : rule registered for pattern [ + pattern + ]);
+Log log = LogUtils.getLogger(digester);
+boolean debug = log.isDebugEnabled();
+if (debug) {
+log.debug(PluginCreateRule.postRegisterInit +
+ : rule registered for pattern [ + pattern + ]);
cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester/plugins LogUtils.java
rdonkin 2003/10/28 15:31:38 Added: digester/src/java/org/apache/commons/digester/plugins LogUtils.java Log: Improvements to bring logging in line with the practice in the rest of digester. Submitted by Simon Kitching. Revision ChangesPath 1.1 jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/LogUtils.java Index: LogUtils.java === /* * $Header: /home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/LogUtils.java,v 1.1 2003/10/28 23:31:38 rdonkin Exp $ * $Revision: 1.1 $ * $Date: 2003/10/28 23:31:38 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 2001-2003 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, *if any, must include the following acknowledgement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgement may appear in the software itself, *if and wherever such third-party acknowledgements normally appear. * * 4. The names Apache, 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, *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.digester.plugins; import org.apache.commons.digester.Digester; import org.apache.commons.logging.Log; /** * Simple utility class to assist in logging. * p * The Digester module has an interesting approach to logging: * all logging should be done via the Log object stored on the * digester instance that the object *doing* the logging is associated * with. * p * This is done because apparently some container-type applications * such as Avalon and Tomcat need to be able to configure different logging * for different iinstances/i of the Digester class which have been * loaded from the same ClassLoader [info from Craig McClanahan]. * Not only the logging of the Digester instance should be affected; all * objects associated with that Digester instance should obey the * reconfiguration of their owning Digester instance's logging. The current * solution is to force all objects to output logging info via a single * Log object stored on the Digester instance they are associated with. * p * Of course this causes problems if logging is attempted before an * object ihas/i a valid reference to its owning Digester. The * getLogging method provided here resolves this issue by returning a * Log object which silently discards all logging output in this * situation. * p * And it also implies that logging filtering can no longer be applied * to subcomponents of the
Re: [digester] plugins: patch for logging
On Monday, October 27, 2003, at 10:17 PM, Simon Kitching wrote: Hi, hi simon i'm not totally convinced that your patch is the best possible approach but i think that it's an improvement so i've committed it. it's pretty much the baseline required for compatibility with the rest of digester. we need another digester release sometime soonish so maybe this needs thinking about sooner rather than later. Robert: thanks for committing the plugins Exception patch. Here is a patch to convert the Plugins module logging to always use the Log object returned by digester.getLogger(). I still think that the way Digester centralizes logging is flawed. However I have more interest in getting plugins finished than debating logging, so this patch should resolve any arguments for the moment. nothings every finished :) at leastways, no open source code ever is. the only problem is energy (but i guess that's down to the second law of thermodynamics). Maybe sometime later I will think about the logging issue and put forward a more concrete proposal. At least now I think I understand the requirements that led to the current implementation. i've been thinking about this for a little while and i think that i now have some ideas about the way i'd prefer logging to work which should preserve backwards compatibility. (i'd like to put setters and getters for the logs on each class and then set then from parent to child as they are created. ) As the governor of California would say, I'll be back.. :-) i'll look forward to that. i'd certainly like to encourage you to stay involved with digester. Regards, Simon PS: I hope I've got the right licence header on new file LogUtils.java this time! did i miss one the other time? (i'm not convinced that there aren't a few more typos in the licenses but these are common to all of digester so i'll probably end up running some more of my scripts against them.) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [httpclient] Handling Yahoo redirect...
Hi Joe, This question is best asked on the HttpClient-dev list as that's where all the HttpClient developers hang out. Fortunately, the answer is pretty simple - you want to take a look at the documentation on our web page, specifically the Cross hosts redirect guide at http://jakarta.apache.org/commons/httpclient/redirects.html Regards, Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com -Original Message- From: Joe Ryburn [mailto:[EMAIL PROTECTED] Sent: Wednesday, 29 October 2003 8:24 AM To: [EMAIL PROTECTED] Subject: Handling Yahoo redirect... When loggin in to Yahoo mail, after a successful post of data the following URL is returned... http://login.yahoo.com/config/verify?.done=http%3a//my.yahoo.com When I redirect the connection to that URL then I get the exception... WARNING: Invalid Redirect URI from: http://login.yahoo.com:80/config/verify to: http://my.yahoo.com I understand I need to handle this manually, but I'm unsure how to proceed. Anyone solved this before me? Regards, Joe Ryburn Affiliated Foods Southwest 12103 Interstate 30 Little Rock, AR 72203-3627 501-455-3590 extension 6319 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [httpclient] Handling Yahoo redirect...
Shame on me. I could have sworn we actually had a redirect example on that
page, but apparently we don't. It appears we don't actually have an example
atm though you might get lucky in the examples directory even though there's
no specific example for redirects:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/
I don't have time to do up a full example at the moment but the structure
will be:
int status = -1;
String url = http://www.yahoo.com;;
while (status 200 || status = 300) {
// create method.
status = client.excute(method);
if (status == REDIRECT) { // check the redirects article for all the
redirect status codes
url = method.getResponseHeader(Location);
}
}
If that doesn't help give a yell on the HttpClient-dev list and someone
should be able to get a comprehensive example.
Regards,
Adrian Sutton, Software Engineer
Ephox Corporation
www.ephox.com
-Original Message-
From: Adrian Sutton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 29 October 2003 9:46 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [httpclient] Handling Yahoo redirect...
Hi Joe,
This question is best asked on the HttpClient-dev list as that's where all
the HttpClient developers hang out.
Fortunately, the answer is pretty simple - you want to take a look at the
documentation on our web page, specifically the Cross hosts redirect guide
at http://jakarta.apache.org/commons/httpclient/redirects.html
Regards,
Adrian Sutton, Software Engineer
Ephox Corporation
www.ephox.com
-Original Message-
From: Joe Ryburn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 29 October 2003 8:24 AM
To: [EMAIL PROTECTED]
Subject: Handling Yahoo redirect...
When loggin in to Yahoo mail, after a successful post of data the following
URL is returned...
http://login.yahoo.com/config/verify?.done=http%3a//my.yahoo.com
When I redirect the connection to that URL then I get the exception...
WARNING: Invalid Redirect URI from: http://login.yahoo.com:80/config/verify
to: http://my.yahoo.com
I understand I need to handle this manually, but I'm unsure how to proceed.
Anyone solved this before me?
Regards,
Joe Ryburn
Affiliated Foods Southwest
12103 Interstate 30
Little Rock, AR 72203-3627
501-455-3590 extension 6319
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections build.xml
scolebourne2003/10/28 16:06:25
Modified:collections/src/java/org/apache/commons/collections
AbstractDualBidiMap.java BidiMap.java
collections/src/test/org/apache/commons/collections
AbstractTestBidiMap.java
collections build.xml
Added: collections/src/java/org/apache/commons/collections
MapIterator.java
Log:
Add MapIterator to BidiMap
Revision ChangesPath
1.4 +66 -2
jakarta-commons/collections/src/java/org/apache/commons/collections/AbstractDualBidiMap.java
Index: AbstractDualBidiMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/AbstractDualBidiMap.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- AbstractDualBidiMap.java 10 Oct 2003 21:09:49 - 1.3
+++ AbstractDualBidiMap.java 29 Oct 2003 00:06:25 - 1.4
@@ -214,6 +214,10 @@
// BidiMap
//---
+public MapIterator mapIterator() {
+return new BidiMapIterator(this);
+}
+
public Object getKey(Object value) {
return maps[1].get(value);
}
@@ -435,6 +439,66 @@
public Object setValue(Object value) {
final Object oldValue = super.setValue(value);
+
+// Gets old key and pairs with new value
+final Object inverseKey = map.maps[1].remove(oldValue);
+map.maps[1].put(value, inverseKey);
+
+return oldValue;
+}
+}
+
+/**
+ * Inner class MapIterator.
+ */
+protected static class BidiMapIterator extends AbstractIteratorDecorator
implements MapIterator {
+
+protected final AbstractDualBidiMap map;
+private Map.Entry last = null;
+private boolean canRemove = false;
+
+protected BidiMapIterator(AbstractDualBidiMap map) {
+super(map.maps[0].entrySet().iterator());
+this.map = map;
+}
+
+public Object next() {
+last = new MapEntry((Map.Entry) super.next(), map);
+canRemove = true;
+return last.getKey();
+}
+
+public void remove() {
+if (canRemove == false) {
+throw new IllegalStateException(Iterator remove() can only be
called once after next());
+}
+// store value as remove may change the entry in the decorator
(eg.TreeMap)
+Object value = last.getValue();
+super.remove();
+map.maps[1].remove(value);
+last = null;
+canRemove = false;
+}
+
+public Object getKey() {
+if (last == null) {
+throw new IllegalStateException(Iterator getKey() can only be
called after next() and before remove());
+}
+return last.getKey();
+}
+
+public Object getValue() {
+if (last == null) {
+throw new IllegalStateException(Iterator getValue() can only be
called after next() and before remove());
+}
+return last.getValue();
+}
+
+public Object setValue(Object value) {
+if (last == null) {
+throw new IllegalStateException(Iterator setValue() can only be
called after next() and before remove());
+}
+Object oldValue = last.setValue(value);
// Gets old key and pairs with new value
final Object inverseKey = map.maps[1].remove(oldValue);
1.4 +20 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/BidiMap.java
Index: BidiMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/BidiMap.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- BidiMap.java 6 Oct 2003 23:47:17 - 1.3
+++ BidiMap.java 29 Oct 2003 00:06:25 - 1.4
@@ -70,8 +70,6 @@
* p
* Implementations should allow a value to be looked up from a key and
* a key to be looked up from a value with equal performance.
- * It should be noted that the quickest way to implement the codevalues/code
- * method is usually to return codeinverseBidiMap().keySet()/code.
*
* @see org.apache.commons.collections.DualHashBidiMap
* @since Commons Collections 3.0
@@ -80,6 +78,24 @@
* @author Stephen Colebourne
*/
public interface BidiMap extends Map {
+
+/**
+ * Obtains a
Re: add commons-primitives to nightly build
From: Craig R. McClanahan [EMAIL PROTECTED] commons-primitives seems to be buildable via ant and maven now. Note that it requires the commons-collections-testframework JAR now being generated by ant dist or maven dist on commons-collections. It can just use the one from running ant dist on the HEAD of collections, right? Yes, I just ran this and the commons-collections-testframework.jar is correct. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] plugins: patch for logging
On Wed, 2003-10-29 at 12:34, robert burrell donkin wrote: On Monday, October 27, 2003, at 10:17 PM, Simon Kitching wrote: Hi, hi simon i'm not totally convinced that your patch is the best possible approach but i think that it's an improvement so i've committed it. it's pretty much the baseline required for compatibility with the rest of digester. we need another digester release sometime soonish so maybe this needs thinking about sooner rather than later. Aha! Good to see that you're thinking about logging too :-) By the not convinced comment, do you mean that I am not complying with the current Digester conventions correctly, or do you mean that the current Digester conventions aren't right? Regarding a new release, I think it would be nice to get something out before Christmas. I've seen lots of small fixes go in over the last few months. Is plugins sufficiently accepted to become part of this new release? I haven't heard anyone raise any objections to it, or suggest it should be removed so I hope so. What I would suggest is: (a) I need to submit patches for: (1) Assertion -- RuntimeException (coming today) (2) setting attribute which specifies plugin, eg foo classe-de-plugin=.../ (3) A change to the way autoSetProperties works. I want to have a pluggable strategy parameter instead of a boolean, for more flexibility. (b) If no-one has any more issues with plugins, I will port my (ECN's) commercial app over to the new library and run tests. This will be a good test of both the API and the implementation. This should take only a day of actual work, but with my current workload, it will probably take about 1 week elapsed time. Of course I only want to do this if there is a pretty good chance that plugins will stay in Digester (c) Do a release, or release candidate. Any logging changes (if something can be agreed on) might go in the mix too. On a related note, I went through the outstanding digester bugs/enhancements in buzgilla a while ago and added some comments. Unfortunately nothing happened. I think that almost all the outstanding entries can be closed, which would be cool to do before the next release. nothings every finished :) Good point! i've been thinking about this for a little while and i think that i now have some ideas about the way i'd prefer logging to work which should preserve backwards compatibility. (i'd like to put setters and getters for the logs on each class and then set then from parent to child as they are created. ) I'm not sure this will work. In order to have a proper hierarchy of categories, the same Log object can't just be passed to the child. I've been thinking about enhancing commons-logging so that a LogFactory object can be placed in thread-local storage, and the static LogFactory method will look there first, and delegate if there is one. For containers which dedicate a thread to a subsystem, this would work. For containers which use thread pools, the container would need to install the correct LogFactory object before using the thread to do work in a specific contained app. Yes, that's logging-specific work. But so is calling the setLog method on Digester or similar. Well, those are just initial thoughts. I was intending to think it through a bit more before suggesting any ideas, but as you are looking at logging, I had better put it forward now.. As the governor of California would say, I'll be back.. :-) i'll look forward to that. i'd certainly like to encourage you to stay involved with digester. I'd be happy to. Once the new release is out, I would like to start looking at some of the other apache projects to determine which of them don't use Digester, and why. Maybe we can then roll extra functionality they need into the base Digester. In particular, Ceki Gulcu (log4j) has a sandbox project Joran, which sounds very digester-like. I think it would be great if we could merge the projects. Any comments? BTW, I'm currently learning Ruby, and decided to practice by porting Digester to Ruby. It's coming along very well (and turned out to be an excellent learning experience). Look for xmldigester coming to RubyForge soon! Any Rubyish types watching this email list are welcome to join in. I'll post an email here when the code is up, or you can contact me directly. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/dbutils/src/java/org/apache/commons/dbutils QueryRunner.java
dgraham 2003/10/28 16:49:56
Modified:dbutils/src/java/org/apache/commons/dbutils QueryRunner.java
Log:
Added a protected prepareStatement() method so
subclasses can override PreparedStatement initialization.
For example, they might want to call:
conn.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS)
instead of the standard initialization.
Revision ChangesPath
1.13 +25 -5
jakarta-commons-sandbox/dbutils/src/java/org/apache/commons/dbutils/QueryRunner.java
Index: QueryRunner.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/dbutils/src/java/org/apache/commons/dbutils/QueryRunner.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- QueryRunner.java 24 Oct 2003 04:25:25 - 1.12
+++ QueryRunner.java 29 Oct 2003 00:49:56 - 1.13
@@ -139,6 +139,26 @@
}
/**
+ * Factory method that creates and initializes a
+ * codePreparedStatement/code object for the given SQL.
+ * codeQueryRunner/code methods always call this method to prepare
+ * statements for them. Subclasses can override this method to provide
+ * special PreparedStatement configuration if needed. This implementation
+ * simply calls codeconn.prepareStatement(sql)/code.
+ *
+ * @param conn The codeConnection/code used to create the
+ * codePreparedStatement/code
+ * @param sql The SQL statement to prepare.
+ * @return An initialized codePreparedStatement/code.
+ * @throws SQLException
+ */
+protected PreparedStatement prepareStatement(Connection conn, String sql)
+throws SQLException {
+
+return conn.prepareStatement(sql);
+}
+
+/**
* Execute an SQL SELECT query with a single replacement parameter. The
* caller is responsible for connection cleanup.
*
@@ -182,7 +202,7 @@
Object result = null;
try {
-stmt = conn.prepareStatement(sql);
+stmt = this.prepareStatement(conn, sql);
this.fillStatement(stmt, params);
rs = this.wrap(stmt.executeQuery());
@@ -367,7 +387,7 @@
int rows = 0;
try {
-stmt = conn.prepareStatement(sql);
+stmt = this.prepareStatement(conn, sql);
this.fillStatement(stmt, params);
rows = stmt.executeUpdate();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/dbutils/src/java/org/apache/commons/dbutils BasicRowProcessor.java
dgraham 2003/10/28 16:57:50
Modified:dbutils/src/java/org/apache/commons/dbutils
BasicRowProcessor.java
Log:
Added more toBean() javadocs.
Revision ChangesPath
1.5 +33 -7
jakarta-commons-sandbox/dbutils/src/java/org/apache/commons/dbutils/BasicRowProcessor.java
Index: BasicRowProcessor.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/dbutils/src/java/org/apache/commons/dbutils/BasicRowProcessor.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- BasicRowProcessor.java26 Oct 2003 00:34:49 - 1.4
+++ BasicRowProcessor.java29 Oct 2003 00:57:50 - 1.5
@@ -130,8 +130,21 @@
/**
* Convert a codeResultSet/code row into a JavaBean. This
- * implementation use reflection and codeBeanInfo/code classes to
- * match column names to bean property names.
+ * implementation uses reflection and codeBeanInfo/code classes to
+ * match column names to bean property names. Properties are matched to
+ * columns based on several factors:
+ * br/
+ * ol
+ * li
+ * The class has a writable property with the same name as a column.
+ * The name comparison is case insensitive.
+ * /li
+ *
+ * li
+ * The property's set method parameter type matches the column
+ * type. If the datatypes do not match, the setter will not be called.
+ * /li
+ * /ol
* @see org.apache.commons.dbutils.RowProcessor#toBean(java.sql.ResultSet,
java.lang.Class)
*/
public Object toBean(ResultSet rs, Class type) throws SQLException {
@@ -165,8 +178,21 @@
/**
* Convert a codeResultSet/code into a List of JavaBeans. This
- * implementation use reflection and codeBeanInfo/code classes to
- * match column names to bean property names.
+ * implementation uses reflection and codeBeanInfo/code classes to
+ * match column names to bean property names. Properties are matched to
+ * columns based on several factors:
+ * br/
+ * ol
+ * li
+ * The class has a writable property with the same name as a column.
+ * The name comparison is case insensitive.
+ * /li
+ *
+ * li
+ * The property's set method parameter type matches the column
+ * type. If the datatypes do not match, the setter will not be called.
+ * /li
+ * /ol
* @see org.apache.commons.dbutils.RowProcessor#toBeanList(java.sql.ResultSet,
java.lang.Class)
*/
public List toBeanList(ResultSet rs, Class type) throws SQLException {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[digester] assertions throw RuntimeException not Error
Hi,
As agreed on the list, here is a patch to change the assertions in
plugins to throw an object subclassing RuntimeException rather than
Error.
File plugins/PluginAssertionError.java can now be deleted.
It has been replaced by PluginAssertionFailure (attached).
I decided not to name the thrown class PluginAssertionException because
this patch actually shows the disadvantage of naming the class by its
inherited type! If you prefer, feel free to
s/PluginAssertionFailure/PluginAssertionException/
in all relevant files.
Regards,
Simon
/*
* $Header: /home/cvspublic/jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/PluginAssertionError.java,v 1.3 2003/10/09 21:09:48 rdonkin Exp $
* $Revision: 1.3 $
* $Date: 2003/10/09 21:09:48 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2001-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution,
*if any, must include the following acknowledgement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgement may appear in the software itself,
*if and wherever such third-party acknowledgements normally appear.
*
* 4. The names Apache, 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,
*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.digester.plugins;
/**
* Thrown when a bug is detected in the plugins code.
* p
* This class is intended to be used in assertion statements, similar to
* the way that java 1.4's native assertion mechanism is used. However there
* is a difference: when a java 1.4 assertion fails, an AssertionError
* is thrown, which is a subclass of Error; here, the PluginAssertionFailure
* class extends RuntimeException rather than Error.
* p
* This difference in design is because throwing Error objects is not
* good in a container-based architecture.
* p
* Example:
* pre
* if (impossibleCondition) {
* throw new PluginAssertionFailure(
* internal error: impossible condition is true);
* }
* /pre
* p
* Note that PluginAssertionFailure should inot/i be thrown when user
* input is bad, or when code external to the Digester module passes invalid
* parameters to a plugins method. It should be used only in checks for
* problems which indicate internal bugs within the plugins module.
*
* @author Simon Kitching
*/
public class PluginAssertionFailure extends RuntimeException {
private Throwable cause = null;
/**
* @param cause underlying exception that caused this to be thrown
*/
public PluginAssertionFailure(Throwable cause) {
this(cause.getMessage());
this.cause = cause;
}
/**
* @param msg describes the reason this exception is being thrown.
*/
public PluginAssertionFailure(String msg) {
super(msg);
}
cvs commit: jakarta-commons-sandbox/dbutils/src/java/org/apache/commons/dbutils BasicRowProcessor.java
dgraham 2003/10/28 17:05:57
Modified:dbutils/src/java/org/apache/commons/dbutils
BasicRowProcessor.java
Log:
Added toArray() and toMap() javadocs.
Revision ChangesPath
1.6 +19 -7
jakarta-commons-sandbox/dbutils/src/java/org/apache/commons/dbutils/BasicRowProcessor.java
Index: BasicRowProcessor.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/dbutils/src/java/org/apache/commons/dbutils/BasicRowProcessor.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- BasicRowProcessor.java29 Oct 2003 00:57:50 - 1.5
+++ BasicRowProcessor.java29 Oct 2003 01:05:56 - 1.6
@@ -113,7 +113,13 @@
super();
}
-// See interface for javadoc.
+/**
+ * Convert a codeResultSet/code row into an codeObject[]/code.
+ * This implementation copies column values into the array in the same
+ * order they're returned from the codeResultSet/code. Array elements
+ * will be set to codenull/code if the column was SQL NULL.
+ * @see org.apache.commons.dbutils.RowProcessor#toArray(java.sql.ResultSet)
+ */
public Object[] toArray(ResultSet rs) throws SQLException {
ResultSetMetaData meta = rs.getMetaData();
int cols = meta.getColumnCount();
@@ -177,8 +183,8 @@
}
/**
- * Convert a codeResultSet/code into a List of JavaBeans. This
- * implementation uses reflection and codeBeanInfo/code classes to
+ * Convert a codeResultSet/code into a codeList/code of JavaBeans.
+ * This implementation uses reflection and codeBeanInfo/code classes to
* match column names to bean property names. Properties are matched to
* columns based on several factors:
* br/
@@ -265,7 +271,13 @@
return columnNameToIndex;
}
-// See interface for javadoc.
+/**
+ * Convert a codeResultSet/code row into a codeMap/code. This
+ * implementation returns a codeMap/code with case insensitive column
+ * names as keys. Calls to codemap.get(COL)/code and
+ * codemap.get(col)/code return the same value.
+ * @see org.apache.commons.dbutils.RowProcessor#toMap(java.sql.ResultSet)
+ */
public Map toMap(ResultSet rs) throws SQLException {
Map result = new CaseInsensitiveHashMap();
ResultSetMetaData rsmd = rs.getMetaData();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2 CommandLine.java ArgumentImpl.java ArgumentBuilder.java
jkeyes 2003/10/28 17:28:17
Modified:cli/src/test/org/apache/commons/cli2 ArgumentTest.java
cli/src/java/org/apache/commons/cli2 CommandLine.java
ArgumentImpl.java ArgumentBuilder.java
Log:
- support for default value(s) at definition stage
(Bug 24042)
Revision ChangesPath
1.4 +70 -6
jakarta-commons-sandbox/cli/src/test/org/apache/commons/cli2/ArgumentTest.java
Index: ArgumentTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/cli/src/test/org/apache/commons/cli2/ArgumentTest.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ArgumentTest.java 25 Oct 2003 15:02:05 - 1.3
+++ ArgumentTest.java 29 Oct 2003 01:28:16 - 1.4
@@ -61,6 +61,7 @@
package org.apache.commons.cli2;
import java.text.ParseException;
+import java.util.ArrayList;
import java.util.Arrays;
import java.util.HashSet;
import java.util.Iterator;
@@ -85,11 +86,12 @@
'\0',
'\0',
null,
-ArgumentImpl.DEFAULT_CONSUME_REMAINING);
+ArgumentImpl.DEFAULT_CONSUME_REMAINING,
+null);
}
public static Argument buildHostArgument() {
- return new ArgumentImpl(host, The host name, 2, 3, '\0', ',',
null, null);
+ return new ArgumentImpl(host, The host name, 2, 3, '\0', ',',
null, null, null);
}
public static Argument buildPathArgument() {
@@ -101,7 +103,8 @@
'=',
';',
null,
- ArgumentImpl.DEFAULT_CONSUME_REMAINING);
+ ArgumentImpl.DEFAULT_CONSUME_REMAINING,
+null);
}
public static Argument buildDateLimitArgument() {
@@ -113,6 +116,7 @@
'=',
'\0',
new DateValidator(DateValidatorTest._MM_YY),
+null,
null);
}
@@ -125,6 +129,7 @@
'\0',
',',
null,
+null,
null);
}
@@ -139,6 +144,7 @@
'=',
'\0',
new DateValidator(DateValidatorTest._MM_YY),
+null,
null);
}
catch(IllegalArgumentException e){
@@ -146,6 +152,39 @@
}
}
+public static Argument buildSizeArgument() {
+List defaults = new ArrayList();
+defaults.add(10);
+
+return new ArgumentImpl(
+size,
+The number of units,
+1,
+1,
+'\0',
+'\0',
+null,
+ArgumentImpl.DEFAULT_CONSUME_REMAINING,
+defaults);
+}
+
+public static Argument buildBoundsArgument() {
+List defaults = new ArrayList();
+defaults.add(5);
+defaults.add(10);
+
+return new ArgumentImpl(
+size,
+The number of units,
+2,
+2,
+'\0',
+'\0',
+null,
+ArgumentImpl.DEFAULT_CONSUME_REMAINING,
+defaults);
+}
+
/* (non-Javadoc)
* @see org.apache.commons.cli2.ArgumentTestCase#testPreProcess()
*/
@@ -491,5 +530,30 @@
assertTrue(commandLine.getValues(option).isEmpty());
assertFalse(iterator.hasNext());
+}
+
+public void testProcess_DefaultValue() throws OptionException {
+final Option size = buildSizeArgument();
+final List args = list(-size);
+final CommandLine commandLine = commandLine(size, args);
+final ListIterator iterator = args.listIterator();
+
+size.process(commandLine, iterator);
+
+assertEquals(commandLine.getValue(size), 10);
+}
+
+public void testProcess_DefaultValues() throws OptionException {
+final Option bounds = buildBoundsArgument();
+final List args = list(-bounds);
+final CommandLine commandLine = commandLine(bounds, args);
+final ListIterator iterator = args.listIterator();
+
+bounds.process(commandLine, iterator);
+
+List values = new ArrayList();
+values.add(5);
+values.add(10);
+assertEquals(values, commandLine.getValues(bounds));
}
}
1.6 +41 -12
jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2/CommandLine.java
Index: CommandLine.java
===
RCS file:
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang StringUtilsTest.java
ggregory2003/10/28 17:50:15
Modified:lang/src/test/org/apache/commons/lang StringUtilsTest.java
Log:
Added public static String removeStart(String str, String remove).
Revision ChangesPath
1.53 +18 -1
jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsTest.java
Index: StringUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsTest.java,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -r1.52 -r1.53
--- StringUtilsTest.java 21 Aug 2003 22:13:24 - 1.52
+++ StringUtilsTest.java 29 Oct 2003 01:50:14 - 1.53
@@ -986,5 +986,22 @@
assertNotNull(StringUtils.EMPTY);
assertEquals(, StringUtils.EMPTY);
}
+
+public void testRemoveStart() {
+// StringUtils.removeStart(, *)=
+assertNull(StringUtils.removeStart(null, null));
+assertNull(StringUtils.removeStart(null, ));
+assertNull(StringUtils.removeStart(null, a));
+
+// StringUtils.removeStart(*, null) = *
+assertEquals(StringUtils.removeStart(, null), );
+assertEquals(StringUtils.removeStart(, ), );
+assertEquals(StringUtils.removeStart(, a), );
+
+// All others:
+assertEquals(StringUtils.removeStart(www.domain.com, www.),
domain.com);
+assertEquals(StringUtils.removeStart(domain.com, www.), domain.com);
+assertEquals(StringUtils.removeStart(domain.com, ), domain.com);
+}
}
-
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
ggregory2003/10/28 18:16:15
Modified:lang/src/java/org/apache/commons/lang StringUtils.java
Log:
Added public static String removeEnd(String str, String remove).
Reimpl'd removeStart.
Revision ChangesPath
1.114 +40 -5
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.113
retrieving revision 1.114
diff -u -r1.113 -r1.114
--- StringUtils.java 29 Oct 2003 01:49:47 - 1.113
+++ StringUtils.java 29 Oct 2003 02:16:15 - 1.114
@@ -202,6 +202,7 @@
* instance to operate./p
*/
public StringUtils() {
+// no init.
}
// Empty checks
@@ -2801,7 +2802,8 @@
lastIdx--;
}
} else if (last == '\r') {
-
+// why is this block empty?
+// just to skip incrementing the index?
} else {
lastIdx++;
}
@@ -4381,11 +4383,44 @@
if (remove == null || remove.length() == 0) {
return str;
}
-int pos = str.indexOf(remove);
-if (pos == -1) {
+if (str.startsWith(remove)){
+return str.substring(remove.length());
+}
+return str;
+}
+
+/**
+ * pRemoves a substring only if it is at the end of a source string,
otherwise returns the source string.
+ *
+ * pA codenull/code source string will return codenull/code.
+ * An empty () source string will return the empty string.
+ * A codenull/code search string will return the source string./p
+ *
+ * pre
+ * StringUtils.removeEnd(null, *) = null
+ * StringUtils.removeEnd(, *)=
+ * StringUtils.removeEnd(*, null) = *
+ * StringUtils.removeEnd(www.domain.com, .com.) = www,domain
+ * StringUtils.removeEnd(www.domain.com, .com) = www.domain
+ * StringUtils.removeEnd(abc, )= abc
+ * /pre
+ *
+ * @param string the source String to search, may be null
+ * @param remove the String to search for, may be null
+ * @return the substring after the optional occurrence of the separator,
+ * codenull/code if null String input
+ */
+public static String removeEnd(String str, String remove) {
+if (str == null || str.length() == 0) {
+return str;
+}
+if (remove == null || remove.length() == 0) {
return str;
}
-return str.substring(pos + remove.length());
+if (str.endsWith(remove)) {
+return str.substring(0, str.length() - remove.length());
+}
+return str;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang StringUtilsTest.java
ggregory2003/10/28 18:16:30
Modified:lang/src/test/org/apache/commons/lang StringUtilsTest.java
Log:
Added public static String removeEnd(String str, String remove).
Revision ChangesPath
1.54 +18 -3
jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsTest.java
Index: StringUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsTest.java,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- StringUtilsTest.java 29 Oct 2003 01:50:14 - 1.53
+++ StringUtilsTest.java 29 Oct 2003 02:16:30 - 1.54
@@ -277,8 +277,6 @@
assertEquals(foo2, StringUtils.concatenate(MIXED_TYPE_LIST));
}
-
-
public void testSplit_String() {
assertEquals(null, StringUtils.split(null));
assertEquals(0, StringUtils.split().length);
@@ -1002,6 +1000,23 @@
assertEquals(StringUtils.removeStart(www.domain.com, www.),
domain.com);
assertEquals(StringUtils.removeStart(domain.com, www.), domain.com);
assertEquals(StringUtils.removeStart(domain.com, ), domain.com);
+}
+
+public void testRemoveEnd() {
+// StringUtils.removeEnd(, *)=
+assertNull(StringUtils.removeEnd(null, null));
+assertNull(StringUtils.removeEnd(null, ));
+assertNull(StringUtils.removeEnd(null, a));
+
+// StringUtils.removeEnd(*, null) = *
+assertEquals(StringUtils.removeEnd(, null), );
+assertEquals(StringUtils.removeEnd(, ), );
+assertEquals(StringUtils.removeEnd(, a), );
+
+// All others:
+assertEquals(StringUtils.removeEnd(www.domain.com, .com), www.domain);
+assertEquals(StringUtils.removeEnd(www.domain, .com), www.domain);
+assertEquals(StringUtils.removeEnd(domain.com, ), domain.com);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: SoTimeout setting
If I might inject a comment from a users viewpoint. We use HttpClient in our VXML interpreter. For any given fetch the application developer can provide a timeout for the fetch. When a method is generated we would need to pass this timeout down to the connection the method uses. Dennis, Allow me try to clarify a few things. I assume you are saying that certain methods that need to fetch larger content may take longer to execute and therefore need a different (perhaps greater) timeout value. Is that right? The problem is that SO_TIMEOUT value does not help here at all. SO_TIMEOUT does not define the maximum duration a method may take. Please correct me if am wrong, but SO_TIMEOUT defines the maximum period of time a read operation may block the socket when expecting input. In other words, SO_TIMEOUT defines the maximum period of inactivity between two consecutive reads. As such SO_TIMEOUT simply does not make sense on a per method basis. It is a socket (connection) property, not that of a method. Regards, Oleg -Original Message- From: Dennis Cook [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 01:43 To: 'Commons HttpClient Project' Subject: RE: SoTimeout setting If I might inject a comment from a users viewpoint. We use HttpClient in our VXML interpreter. For any given fetch the application developer can provide a timeout for the fetch. When a method is generated we would need to pass this timeout down to the connection the method uses. Dennis Cook BeVocal, Inc. tel: 650-641-1424 fax: 650-210-9275 -Original Message- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 3:13 PM To: Commons HttpClient Project Subject: Re: SoTimeout setting Mike, I see what you mean. Still, no matter how I look at it, socket/connection timeout parameters on the HttpMethod level does not seem right. Let's approach the issue from a different angle. You seem to dislike the idea of exposing HttpConnection objects contained by MultiThreadedHttpConnectionManager. What if we allowed HttpConnectionParams instance(s) to be retrieved given a host configuration (enumerated), not the HttpConnection instance(s) itself(themselves)? Besides, if I understand Fabio right, his issue is with inability to set different socket/connection timeout parameters per connection. Setting these parameters per method, if I understand things correctly, was proposed merely as a work-around On Mon, 2003-10-27 at 19:31, Michael Becke wrote: Mike, Why do you think that providing an ability to enumerate of HTTP connection would break this pattern? I think that adding this functionality could be okay depending on the use. My worry is that it opens up a whole host of possible invalid uses. This was not the concern I was trying to convey in my previous statement though. I intended to discourage major connection configuration (timeout, send buffer, etc.) as part of the connection retrieval/release process. I think this should be handled by the methods/HttpClient. What good would that make? You can always get HttpConnectionParams from the HttpConnection. Am I missing something? I was looking at this from the perspective of Fabio's question. He needs to be able to set the SO_TIMEOUT on a per method execution basis. Since he doesn't have direct access to the connection being used, my though was that HttpClient could handle this configuration using passed in params. This is just one possible solution, I'm sure there are others. Mike - 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 24012] - Ability to ignore (reject) cookies altogether
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=24012. 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=24012 Ability to ignore (reject) cookies altogether --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 08:42 --- Mike, I think there's a little more elegant solution. All it takes is a cookie policy that overrides CookieSpec#parse method and simply returns an empty array of cookies without actually parsing the header. That is it. No need for the COOKIE_PARSING_ENABLED. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SoTimeout setting
Dennis Cook wrote: If I might inject a comment from a users viewpoint. We use HttpClient in our VXML interpreter. For any given fetch the application developer can provide a timeout for the fetch. When a method is generated we would need to pass this timeout down to the connection the method uses. So the REAL problem is not how to set a timeout on the underlying connection, BUT to have a means to ABORT an executing method! That way you could easily realize the timeout on the user side (or even inside HttpClient) without even having to care about the connection. So I propose to focus on HttpMethod::abort. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SoTimeout setting
Mike, This is a possibility, though I get the impression that people still want to specify things at the request level. There are things that people want even though they do not make sense. SO_TIMEOUT on a per request basis IMHO falls into this category. The more I think about this the more I feel like our current options are not really what we're looking for. It seems like we need a new level of functionality for configuring/preparing connections between the time they are checked out of a connection manager and the time they are used in a method. Any thoughts? What are you thinking in regard to the HttpConnectionParams/host config mapping? I have (what appears to me at) a fairly straight-forward approach: allow HttpConnectionParams to be created and customized before physical HttpConnection instance is allocated, when connection manager allocates a connection it can look corresponding parameter object up from a hash map, and, if found, assign it to the connection. End of the story. Cheers Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SoTimeout setting
Kalnichevski, Oleg wrote: I have (what appears to me at) a fairly straight-forward approach: allow HttpConnectionParams to be created and customized before physical HttpConnection instance is allocated, when connection manager allocates a connection it can look corresponding parameter object up from a hash map, and, if found, assign it to the connection. End of the story. With the intent to clarify my previous suggestions: this could be the right approach, for setting a timeout on a per-method base is actually a workaround as Oleg pointed out. A control on the HttpConnecction level would be more suitable. But, if I understand well your intent here and the global httpclient architecture, tieing the customization of HttpConnectionParams to a specific HostConfiguration would prevent different method execution attempts on a host from having different (increasing) timeouts.. Am I missing something? Cheers Fabio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24012] - Ability to ignore (reject) cookies altogether
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=24012. 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=24012 Ability to ignore (reject) cookies altogether --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 10:37 --- Hello Oleg, while there is no strict need to have a COOKIE_PARSING_ENABLED flag, I still feel it is more elegant to have one. Not because it achieves a different result than a no-cookies policy, but because it points out that cookie parsing is an optional feature that can be switched *off*, as opposed to having a pass-through-without-effect mode. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SoTimeout setting
Fabio, Mike has a good point. Allowing the user to have direct access to the underlying HttpConnection bears significant risks, as it may open possibility for all sorts of misuses and abuses. So, basically you are right. Same HttpConnectionParams would apply to all the connections with the same HostConfiguration. If that poses a problem for you, HttpConnectionParams on a per request method seems the only way out. It's conceptually wrong and ugly, but seems the only possibility to achieve the desired effect without having direct access to the underlying HttpConnection instance. Cheers Oleg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 11:45 To: Commons HttpClient Project Subject: Re: SoTimeout setting Kalnichevski, Oleg wrote: I have (what appears to me at) a fairly straight-forward approach: allow HttpConnectionParams to be created and customized before physical HttpConnection instance is allocated, when connection manager allocates a connection it can look corresponding parameter object up from a hash map, and, if found, assign it to the connection. End of the story. With the intent to clarify my previous suggestions: this could be the right approach, for setting a timeout on a per-method base is actually a workaround as Oleg pointed out. A control on the HttpConnecction level would be more suitable. But, if I understand well your intent here and the global httpclient architecture, tieing the customization of HttpConnectionParams to a specific HostConfiguration would prevent different method execution attempts on a host from having different (increasing) timeouts.. Am I missing something? Cheers Fabio - 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 24012] - Ability to ignore (reject) cookies altogether
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=24012. 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=24012 Ability to ignore (reject) cookies altogether --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 11:03 --- Roland, I respectfully disagree. What good does it make to have a cookie policy in place and to not parse cookie headers? One would send a cookie to the target server only to end up ignoring it when it comes back with the response. I can't think of a case where this kind of setup would be of any use. Cheers Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24012] - Ability to ignore (reject) cookies altogether
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=24012. 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=24012 Ability to ignore (reject) cookies altogether --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 12:03 --- Hello Oleg, you're right that the cookie policy becomes pointless if cookie parsing is disabled. Like the bass and treble knobs on my old amplifier become useless if I enable the CD Direct mode. What about cases when you want to disable cookie parsing for some methods, but have a cookie policy in place for those that do parse cookies? For my application, it doesn't matter in which way cookie parsing is disabled. It will have to handle cookies anyway, because they need to be stored outside of the HTTP Client's HttpState, and I don't want to create a new HttpState object for each request. But I still find the *off* switch preferable. I may even be able to rely on the HTTP Client's cookie parsing manually, without having cookies stored in the state. regards, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24012] - Ability to ignore (reject) cookies altogether
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=24012. 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=24012 Ability to ignore (reject) cookies altogether --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 12:25 --- What about cases when you want to disable cookie parsing for some methods, but have a cookie policy in place for those that do parse cookies? Roland, that should not be a problem, as the cookie policy applies on per method basis. But I still find the *off* switch preferable. I may even be able to rely on the HTTP Client's cookie parsing manually, without having cookies stored in the state. You can instantiate any cookie spec of your liking and use it to parse cookie headers manually. Tastes differ, of course, but I personally do not see a lot value in having COOKIE_PARSING_ENABLED option. Again, it's just an opinion which may well be wrong. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24178] New: - HttpRecoverableException doesn't preserve causing exception.
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=24178. 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=24178 HttpRecoverableException doesn't preserve causing exception. Summary: HttpRecoverableException doesn't preserve causing exception. Product: Commons Version: 2.0 Beta 2 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: HttpClient AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When HttpRecoverableException is thrown it looses the cause (I mean the getCause() method returns a null value). It's not very comfortable when you need more sophisticated error handling. The solution that works for me is to add HttpRecoverableException(Throwable t, String message) constructor and replace all reasonable occurrences of “throw new HttpRecoverableException(“some info”)” with the new one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24178] - HttpRecoverableException doesn't preserve causing exception.
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=24178. 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=24178 HttpRecoverableException doesn't preserve causing exception. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 12:40 --- Karol, the problem is already fixed in the CVS HEAD. In fact the entire exception handling framework in HttpClient has been redesigned. The fix will be publicly avaliable as of release 2.1 Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24012] - Ability to ignore (reject) cookies altogether
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=24012. 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=24012 Ability to ignore (reject) cookies altogether --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 13:28 --- Oleg, Unfortunately I think you are correct:) A new cookie policy is more appropriate. Expect a new patch later today. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SoTimeout setting
On Oct 28, 2003, at 3:57 AM, Kalnichevski, Oleg wrote: I have (what appears to me at) a fairly straight-forward approach: allow HttpConnectionParams to be created and customized before physical HttpConnection instance is allocated, when connection manager allocates a connection it can look corresponding parameter object up from a hash map, and, if found, assign it to the connection. End of the story. I think we are fairly nearly talking about the same thing. The only possible difference I see is how the instance of HttpConnectionParams is obtained. My thought is to pass the instance into HttpClient as a param to executeMethod() or something similar. How do you envision controlling access to the hash map of params? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SoTimeout setting
I think we are fairly nearly talking about the same thing. The only possible difference I see is how the instance of HttpConnectionParams is obtained. My thought is to pass the instance into HttpClient as a param to executeMethod() or something similar. Mike, this is certainly a possibility. What tortures me is realization that with this kind of setup HttpConnection (and possibly HttpConnectionManager) should not have been HttpParams-enabled after all. My initial plan was to enable the user to enumerate HttpConnections contained by the multithreaded connection manager. I guess the plan was ill-conceived How do you envision controlling access to the hash map of params? I was thinking about some additional methods on the HttpConnectionManager interface, something like HttpConnectionManager#getParamsFor(HostConfiguration). Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SoTimeout setting
Mike, this is certainly a possibility. What tortures me is realization that with this kind of setup HttpConnection (and possibly HttpConnectionManager) should not have been HttpParams-enabled after all. My initial plan was to enable the user to enumerate HttpConnections contained by the multithreaded connection manager. I guess the plan was ill-conceived We may be coming at this from the wrong angle, but I also think having the connection configuration is a good thing. My gut reaction at the moment is that we're trying to do too much with the connection managers. I was thinking about some additional methods on the HttpConnectionManager interface, something like HttpConnectionManager#getParamsFor(HostConfiguration). This is a possibility, though for the simple connection manager it seems like overkill. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: cactus-13-1.5-rc and commons-httpclient-2.0-rc2.jar works on jdk1.4 and above only?
On Tue, 2003-10-28 at 21:54, Vincent Massol wrote: Hi, I've released Cactus 1.5-rc1 last week end. I bundle commons-httpclient 2.0 rc2 in it. I've just received this email below from a cactus user. Is it true, as Ajay says, that commons-httpclient would only work on JDK 1.4 onwards (see end of email below)? Vincent, This is not the case. HttpClient requires Java 1.2.2 only (one would have to have JSSE and/or JCE installed in order to be able to use SSL/NTLM). I know it for a fact as I develop HttpClient on Sun JDK 1.2.2. Unfortunately the stack trace appears garbled. I can't figure exactly what method of which class is not available. Is it HttpState#toString? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FW: cactus-13-1.5-rc and commons-httpclient-2.0-rc2.jar workson jdk1.4 and above only?
Ok. Thanks Oleg. I'll follow that up with Ajay. I just wanted a quick confirmation which you gave me. Thanks -Vincent -Original Message- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: 28 October 2003 23:01 To: Commons HttpClient Project Subject: Re: FW: cactus-13-1.5-rc and commons-httpclient-2.0-rc2.jar workson jdk1.4 and above only? On Tue, 2003-10-28 at 21:54, Vincent Massol wrote: Hi, I've released Cactus 1.5-rc1 last week end. I bundle commons-httpclient 2.0 rc2 in it. I've just received this email below from a cactus user. Is it true, as Ajay says, that commons-httpclient would only work on JDK 1.4 onwards (see end of email below)? Vincent, This is not the case. HttpClient requires Java 1.2.2 only (one would have to have JSSE and/or JCE installed in order to be able to use SSL/NTLM). I know it for a fact as I develop HttpClient on Sun JDK 1.2.2. Unfortunately the stack trace appears garbled. I can't figure exactly what method of which class is not available. Is it HttpState#toString? Oleg - To unsubscribe, e-mail: commons-httpclient-dev- [EMAIL PROTECTED] For additional commands, e-mail: commons-httpclient-dev- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cactus-13-1.5-rc and commons-httpclient-2.0-rc2.jar works on jdk1.4 and above only?
On 29/10/03 8:12 AM, Michael Becke [EMAIL PROTECTED] wrote: I think I've found the problem. In 1.4, Sun added StringBuffer.append(StringBuffer) to compliment the existing StringBuffer.append(Object). The problem is that STUPID me ran maven for this release with 1.4. The method call was bound to the append(StringBuffer) method, since it is the best option in 1.4. It looks like the build will have to be regenerated with 1.2.2. That's probably the best option for redoing the rc2 release, however we should change the code to be something like: StringBuffer buf1 = new StringBuffer(); ... buf1.append(getOtherStringBuffer().toString()); The .toString() will make sure that we always use the .append(String) method regardless of which JVM the build is compiled on, thus avoiding this problem in the future. Does anyone what JVM is used for nightlies? I would have thought it would be 1.4 so that projects which depend on 1.4 would compile correctly, besides GUMP is all about using the latest of everything. Mike Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24012] - Ability to ignore (reject) cookies altogether
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=24012. 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=24012 Ability to ignore (reject) cookies altogether --- Additional Comments From [EMAIL PROTECTED] 2003-10-29 03:56 --- I've just started to write a new RejectAllCookiesSpec(or something like that) and I have a question. What do we want to do about cookie formatting and matching? My plan was to extend CookieSpecBase and just override parse(). This means that cookies can still be sent, they just won't be parsed. What about if we need to send cookies in the RFC2109 format? Other than creating a different non-parsing spec for each real spec, I think we may have to use the previous COOKIE_PARSING_ENABLED patch. What does everyone think? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24012] - Ability to ignore (reject) cookies altogether
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=24012. 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=24012 Ability to ignore (reject) cookies altogether --- Additional Comments From [EMAIL PROTECTED] 2003-10-29 05:03 --- Created an attachment (id=8797) Patch 2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24012] - Ability to ignore (reject) cookies altogether
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=24012. 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=24012 Ability to ignore (reject) cookies altogether --- Additional Comments From [EMAIL PROTECTED] 2003-10-29 05:06 --- Here's another patch. This one disables cookie parsing using a new cookie policy. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cactus-13-1.5-rc and commons-httpclient-2.0-rc2.jar works on jdk1.4 and above only?
I've created a new build and uploaded it to http://www.apache.org/~mbecke/httpclient-2.0-rc2/. This build is identical to the original RC2 build except for the following: - the distribution was created with JDK 1.2.2 - HttpState has been changed to ensure that StringBuffer.append(StringBuffer) is not used Please take a look and let me know. Mike On Oct 28, 2003, at 10:05 PM, Michael Becke wrote: Okay. I will apply a small patch to 2.0 and HEAD shortly that should take care of this problem. Afterwards I will regenerate the 2.0RC2 release, hopefully with 1.2.2. I have had some trouble generating the distribution with 1.22 in the past, but I'll give it a try. Mike On Oct 28, 2003, at 8:13 PM, Adrian Sutton wrote: On 29/10/03 8:12 AM, Michael Becke [EMAIL PROTECTED] wrote: I think I've found the problem. In 1.4, Sun added StringBuffer.append(StringBuffer) to compliment the existing StringBuffer.append(Object). The problem is that STUPID me ran maven for this release with 1.4. The method call was bound to the append(StringBuffer) method, since it is the best option in 1.4. It looks like the build will have to be regenerated with 1.2.2. That's probably the best option for redoing the rc2 release, however we should change the code to be something like: StringBuffer buf1 = new StringBuffer(); ... buf1.append(getOtherStringBuffer().toString()); The .toString() will make sure that we always use the .append(String) method regardless of which JVM the build is compiled on, thus avoiding this problem in the future. Does anyone what JVM is used for nightlies? I would have thought it would be 1.4 so that projects which depend on 1.4 would compile correctly, besides GUMP is all about using the latest of everything. Mike Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24012] - Ability to ignore (reject) cookies altogether
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=24012. 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=24012 Ability to ignore (reject) cookies altogether --- Additional Comments From [EMAIL PROTECTED] 2003-10-29 06:31 --- Or else we could have two cookie spec params, one for parsing and one for formatting. Then you define a new policy which neither parses nor formats cookies, and folks can mix and match different specs at will. I thought for a few seconds about having a default cookie spec for both and defining an optional second parameter for the parsing case, but things would get unnecessarily complicated. Having two parameters treats formatting and parsing as two different options that can be configured independently, which seems more appropriate to me. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
