TimerMap
Commons Developers,
The attached class is a very simple implementation of the java.util.Map
interface that gives each key a TTL (time to live) in the map. I've
found this extremely useful as a backing store for certain types of
caches (where you want to expire items based on time in cache, as
opposed to LRU, etc..) and for tracking services that I want check the
availability of. It's called TimerMap and takes a long TTL in the
constructor.
I'd love to donate this code to the commons, please let me know if you
find it useful.
-Joe
Joseph Rosenblum | 25th Street Networks
Easy, Reliable Web Hosting @ http://www.25thstreet.net/
package net.twentyfifth.util;
import java.util.*;
/**
* This class will expire the keys in a given map after the interval
* specified in the constructor. Note: the behavior of this class is such
* that if you configure a TimerMap with a 5 minute timeout, and if 4:59
* after you add a certain key, you re-add a duplicate of that key, the
* original TimerTask to remove the key will run 1 second later (and then
* again 5 minutes later).
*
* @author Joseph Rosenblum [EMAIL PROTECTED]
*/
public class TimerMap implements Map {
protected final long delay;
private final Map timerMap = Collections.synchronizedMap(new HashMap());
private Timer timer;
public TimerMap(long delay) {
this.delay = delay;
timer = new Timer();
}
public void finalize() {
timer.cancel();
}
public long getDelay(Object key) {
return delay;
}
public int size() {
return this.timerMap.size();
}
public boolean isEmpty() {
return this.timerMap.isEmpty();
}
public boolean containsKey(Object key) {
return this.timerMap.containsKey(key);
}
public boolean containsValue(Object value) {
return this.timerMap.containsValue(value);
}
public Object get(Object key) {
return this.timerMap.get(key);
}
public Object put(Object key, Object value) {
Object prevKey = this.timerMap.put(key, value);
timer.schedule(new TimedMapKey(key), delay);
return prevKey;
}
public Object remove(Object key) {
return this.timerMap.remove(key);
}
public void putAll(Map t) {
Iterator i = t.keySet().iterator();
while (i.hasNext()) {
Object key = i.next();
Object val = t.get(key);
this.put(key, val);
}
}
public void clear() {
}
public Set keySet() {
return this.timerMap.keySet();
}
public Collection values() {
return this.timerMap.values();
}
public Set entrySet() {
return this.timerMap.entrySet();
}
/**
* Basically wraps map keys in a TimerTask that
* will remove them from the timerMap after the delay
* interval has expired.
*/
public final class TimedMapKey extends TimerTask {
private final Object key;
TimedMapKey(Object key) {
this.key = key;
}
public void run() {
timerMap.remove(key);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] remove old ant build system
On Sun, 23 Nov 2003, Henri Yandell [EMAIL PROTECTED] wrote: I've gone ahead and done this. One thing that you have to be aware of is that under some - unknown to me - circumstances maven ant puts strange, absolute (specifc to your machine) paths into the generated build file. See http://gump.covalent.net/log/commons-io.html ;-) Maybe dIon can help you out as he's been able to fix it whenever that has happened in the past. He may even be able to tell us how to avoid it, hi dIon 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24936] New: - Partial support of space characters in Service Name
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=24936. 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=24936 Partial support of space characters in Service Name Summary: Partial support of space characters in Service Name Product: Commons Version: 1.0 Alpha Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Daemon AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When you install a service, using this syntax: tomcat.exe //IS//Tomcat 5.0.14 Everything looks fine, except that in the Windows service properties, the Path to executable is: tomcat.exe //RS//Tomcat 5.0.14 As the quotes are missing, only //RS//Tomcat is read, and this service is not found. If you manually add the quotes afterwards, the start can be achieved. Workaround: Use only one word, such as Tomcat5014, until the bug is fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/digester XMLIntrospectorHelper.java
mvdb2003/11/24 01:20:13 Modified:betwixt/src/java/org/apache/commons/betwixt/digester XMLIntrospectorHelper.java Log: Fixing bug http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23324 Thanx to Lari Hotari for spotting this. Revision ChangesPath 1.27 +12 -12 jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/digester/XMLIntrospectorHelper.java Index: XMLIntrospectorHelper.java === RCS file: /home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/digester/XMLIntrospectorHelper.java,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- XMLIntrospectorHelper.java9 Oct 2003 20:52:04 - 1.26 +++ XMLIntrospectorHelper.java24 Nov 2003 09:20:13 - 1.27 @@ -619,14 +619,14 @@ return false; } return type.getName().startsWith( java.lang. ) -|| type.isAssignableFrom( Number.class ) -|| type.isAssignableFrom( String.class ) -|| type.isAssignableFrom( Date.class ) -|| type.isAssignableFrom( java.sql.Date.class ) -|| type.isAssignableFrom( java.sql.Time.class ) -|| type.isAssignableFrom( java.sql.Timestamp.class ) -|| type.isAssignableFrom( java.math.BigDecimal.class ) -|| type.isAssignableFrom( java.math.BigInteger.class ); +|| Number.class.isAssignableFrom( type ) +|| String.class.isAssignableFrom( type ) +|| Date.class.isAssignableFrom( type ) +|| java.sql.Date.class.isAssignableFrom( type ) +|| java.sql.Time.class.isAssignableFrom( type ) +|| java.sql.Timestamp.class.isAssignableFrom( type ) +|| java.math.BigDecimal.class.isAssignableFrom( type ) +|| java.math.BigInteger.class.isAssignableFrom( type ); } // Implementation methods - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23324] - Wrong use of Class.isAssignableFrom in XMLIntrospectorHelper.isPrimitiveType
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=23324. 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=23324 Wrong use of Class.isAssignableFrom in XMLIntrospectorHelper.isPrimitiveType [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 09:20 --- Fixed in cvs. Thanx for the patch! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/xdocs tasks.xml
mvdb2003/11/24 01:23:13 Modified:betwixt/xdocs tasks.xml Log: Fixing typo spotted by Rob Leland. Revision ChangesPath 1.25 +1 -1 jakarta-commons/betwixt/xdocs/tasks.xml Index: tasks.xml === RCS file: /home/cvs/jakarta-commons/betwixt/xdocs/tasks.xml,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- tasks.xml 8 Sep 2003 21:41:48 - 1.24 +++ tasks.xml 24 Nov 2003 09:23:13 - 1.25 @@ -340,7 +340,7 @@ /ul /subsection /section -section name='Symantic Changes' +section name='Semantic Changes' subsection name='Since 1.0-Alpha 1 Release' ul li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22536] - maven xdocs/tasks.xml
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=22536. 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=22536 maven xdocs/tasks.xml [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 09:23 --- Fixed typo.. Thanx. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] CaseInsensitiveHashMap
On Sun, 2003-11-23 at 21:53, Phil Steitz wrote: A few weeks back, David Graham submitted code for a CaseInsensitiveHashMap here: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24537 This looks like a good addition to [collections] to me. Any objections to my coding up some tests and adding this class to the map package? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] It might be best to use an instance of o.a.c.c.decorators.TransformedMap with a lower case key transformer and a null value transformer to implement this class. Even though the posted implementation is simple, using the decorator removes the need to have the 'plumbing' code currently present -- and illustrates the use of the collections library. -Janek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] CaseInsensitiveHashMap
On Sun, 2003-11-23 at 22:25, Brian S O'Neill wrote: This implementation converts the key to lowercase on every get and put, which adds a bit of object allocation overhead. Also, simply converting to lowercase does not make it fully case-insensitive. There is a comment in String.regionMatches that brings up something about the Georgian alphabet. What I always do when I want a case-insensitive map is to construct a TreeMap with String.CASE_INSENSITIVE_ORDER. This Georgian issue could be avoided by allowing CaseInsensitiveHashMap to restrict it's scope to Sql naming standards for columns and leaving it in DbUtils. -Janek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23229] - File Upload Not Compatible With IE 5.2.3 MacOS X
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=23229. 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=23229 File Upload Not Compatible With IE 5.2.3 MacOS X --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 12:58 --- Created an attachment (id=9261) Diff of fix for Mac IE using file upload - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23229] - File Upload Not Compatible With IE 5.2.3 MacOS X
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=23229. 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=23229 File Upload Not Compatible With IE 5.2.3 MacOS X --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 12:59 --- Created an attachment (id=9262) Code with Mac IE fix in place - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Contribution to o.a.c.math.distribution - NormalDistribution
Hello! I would like to contribute to the o.a.c.math.distribution package the implementation of Normal distribution. I've implemented two algorithms for calculation of a cummulative distribution function - one of them (NormalCDFFastAlgorithm.java) is fast but less precise then the other one (NormalCDFPreciseAlgorithm.java). I think that having alternative in this case is useful since we have the standard (precise) algorithm available but when we need speed, we can use the other one - so the java is slow people would not have an occasion to mess around. In fact the fast algorithm is precise enough to be used in a majority of real-life applications (especially in social sciences). Code which calculates CDF is in the mentioned files, the code for the inverse CDF is in the NormalDistributionImpl.java. This is what really matters. I've organized the classes so that the precise algorithm is used as a default, but it is easy to switch to the other one: z = DistributionFactory.newInstance().createNormalDistribution(mean, standardDev); z.setCdfAlgorithm(new NormalCDFFastAlgorithm()); You might not like the way I've implemented the alternative algorithms - this is just the Strategy Pattern, but one can achieve the same aim differently, maybe in a better way - I wanted to stick as close as possible to the current implementation of ContinousDistribution and be user friendly at the same time. I am not sure if the file names are the best one can think of too. I have adopted the convention that for standard deviation equal to zero cumulative distribution is always 0 and inverse CDF equals to the mean value. I am not quite convinced that for probability p=0 and p=1 inverse CDF should return NaN, maybe a better solution would be to return Double.NEGATIVE_INFINITY for p=0 and Double.POSITIVE_INFINITY for p=1. Any suggestions? Hope you'll find it useful Regards Piotr Kochanski, Warsaw University NormalDistribution.zip Description: Zip archive - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TimerMap
Howdy, I like it: simple, practical idea. Yoav Shapira Millennium ChemInformatics -Original Message- From: Joseph Rosenblum [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 2:04 AM To: [EMAIL PROTECTED] Subject: TimerMap Commons Developers, The attached class is a very simple implementation of the java.util.Map interface that gives each key a TTL (time to live) in the map. I've found this extremely useful as a backing store for certain types of caches (where you want to expire items based on time in cache, as opposed to LRU, etc..) and for tracking services that I want check the availability of. It's called TimerMap and takes a long TTL in the constructor. I'd love to donate this code to the commons, please let me know if you find it useful. -Joe Joseph Rosenblum | 25th Street Networks Easy, Reliable Web Hosting @ http://www.25thstreet.net/ This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TimerMap
A good idea! I would recommend making this a decorator as opposed to a full-blown implementation. I do not have your original source here, so I don't know if that's what you did or not. If you made it a decorator, you could nest maps to combine different implementation benefits. For example, I could create a cache that is both TTL and LRU based. -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 8:44 AM To: Jakarta Commons Developers List Subject: RE: TimerMap Howdy, I like it: simple, practical idea. Yoav Shapira Millennium ChemInformatics -Original Message- From: Joseph Rosenblum [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 2:04 AM To: [EMAIL PROTECTED] Subject: TimerMap Commons Developers, The attached class is a very simple implementation of the java.util.Map interface that gives each key a TTL (time to live) in the map. I've found this extremely useful as a backing store for certain types of caches (where you want to expire items based on time in cache, as opposed to LRU, etc..) and for tracking services that I want check the availability of. It's called TimerMap and takes a long TTL in the constructor. I'd love to donate this code to the commons, please let me know if you find it useful. -Joe Joseph Rosenblum | 25th Street Networks Easy, Reliable Web Hosting @ http://www.25thstreet.net/ This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24941] New: - LocaleBeanUtils.populate() doesn't accept localized input map
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=24941. 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=24941 LocaleBeanUtils.populate() doesn't accept localized input map Summary: LocaleBeanUtils.populate() doesn't accept localized input map Product: Commons Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Bean Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When you try to populate a bean with a map of values with String in localized format an exception occurs. Seems like it tryes to parse the input based on BeanUtils (not localized). I read the code and proposed a path which I am sending here as soon as I finish my tests. Specifically, I am trying to handle internationalized input from a Struts form (I will send another patch for Struts concerning his RequestUtils). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Current plan?
I haven't been able to work on [io] for awhile. The last thing I was doing was looking at the Clover report and trying to improve the test coverage. For example. EndianUtils is a class that has 0 tests -- but I didn't have a good enough understanding of it to write any. The tasks page contains the same TODO list as the STATUS.html file. I think these items are all still accurate. FileUtils contains a lot of deprecated methods that need to be removed. The plans were to create a FilenameUtils class that contained a lot of similar methods to FileUtils, but took a String as a parameter instead of a java.io.File. Then there may be implementations behind the scenes for URLs, local or remote files. Henri Yandell wrote: Clover's already on the IO site :) Idiot me. Hen On Sun, 23 Nov 2003, Henri Yandell wrote: Just in case it's of use, I knocked out a clover report for IO. Have recently reinstalled the machine, so the commons licence for clover is not setup. http://www.apache.org/~bayard/io-clover/ Hen On Sun, 23 Nov 2003, Henri Yandell wrote: Jeremias et al, Just wanted to ask what the current plan was for Commons IO. Do you have a todo list anywhere that you're working from? Is there anywhere I can help? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] remove old ant build system
I've had this happen when I had references to ${basedir} in the
project.xml. I think this is supposed to be fixed in maven 1.0-rc1?
Stefan Bodewig wrote:
On Sun, 23 Nov 2003, Henri Yandell [EMAIL PROTECTED] wrote:
I've gone ahead and done this.
One thing that you have to be aware of is that under some - unknown to
me - circumstances maven ant puts strange, absolute (specifc to your
machine) paths into the generated build file.
See http://gump.covalent.net/log/commons-io.html
;-)
Maybe dIon can help you out as he's been able to fix it whenever that
has happened in the past. He may even be able to tell us how to avoid
it, hi dIon 8-)
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DBCP problem with Oracle 9i and default isolation settings
Hi! I am currently porting Jakarta-Slide's DB backend to Oracle 9i using DBCP. The problem is Oracle expects the setting of the isolation level to be the first in a transaction. When using default isolation levels in ctor of PoolableConnectionFactory activateObject first sets autocommit and readonly, then isolation. If this is reversed, i.e. first set isolation then the other stuff, things work. Could someone please check? Thanks in advance, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP problem with Oracle 9i and default isolation settings
Ooops, forgot to mention: The problem is not autocommit, but readonly... Oliver Oliver Zeigermann wrote: Hi! I am currently porting Jakarta-Slide's DB backend to Oracle 9i using DBCP. The problem is Oracle expects the setting of the isolation level to be the first in a transaction. When using default isolation levels in ctor of PoolableConnectionFactory activateObject first sets autocommit and readonly, then isolation. If this is reversed, i.e. first set isolation then the other stuff, things work. Could someone please check? Thanks in advance, Oliver - 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: [collections] CaseInsensitiveHashMap
--- Brian S O'Neill [EMAIL PROTECTED] wrote: This implementation converts the key to lowercase on every get and put, which adds a bit of object allocation overhead. How else would you accomplish the class' goal? Also, simply converting to lowercase does not make it fully case-insensitive. There is a comment in String.regionMatches that brings up something about the Georgian alphabet. I couldn't find any such comment in the javadocs http://java.sun.com/j2se/1.4.2/docs/api/java/lang/String.html#regionMatches(boolean, int, java.lang.String, int, int) What I always do when I want a case-insensitive map is to construct a TreeMap with String.CASE_INSENSITIVE_ORDER. We don't want a sorted Map implementation, just an implementation with case insensitive Strings as keys. Also, TreeMap is known to be much slower than HashMap. David Phil Steitz wrote: A few weeks back, David Graham submitted code for a CaseInsensitiveHashMap here: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24537 This looks like a good addition to [collections] to me. Any objections to my coding up some tests and adding this class to the map package? Phil - 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!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] CaseInsensitiveHashMap
--- Janek Bogucki [EMAIL PROTECTED] wrote: On Sun, 2003-11-23 at 21:53, Phil Steitz wrote: A few weeks back, David Graham submitted code for a CaseInsensitiveHashMap here: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24537 This looks like a good addition to [collections] to me. Any objections to my coding up some tests and adding this class to the map package? Phil It might be best to use an instance of o.a.c.c.decorators.TransformedMap with a lower case key transformer and a null value transformer to implement this class. Even though the posted implementation is simple, using the decorator removes the need to have the 'plumbing' code currently present -- and illustrates the use of the collections library. That's a good idea. I was not aware of TransformedMap or the Transformer interface. It seems like they were designed to avoid writing classes like CaseInsensitiveHashMap :-). However, it only transforms objects on put() calls and not on get(). That behavior would need to change. David -Janek __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [betwixt] Betwixt troubles...
Ok cool. Thanks for looking into this for me. (don't worry about it being late, not a big deal. I just had to use Castor for the unmarshalling and Betwixt for the Marshalling - not really the most elegant but it did the trick temporarily. It's actually funny, because I tried just switching to Castor completely, but was unable to do the complex marshalling with it, however it did manage to handle the unmarshalling well. ;-) 1) Somehow I got it in my head that the name attribute was optional if the property attribute was present, and that the property this would cause the name of the element/attribute to be the default value (based off the property). 2) Ok. So what is the best thing to do. Should I grab a CVS snapshot? Is this pretty stable (comparable to the 2/2003 snapshot, and/or alpha 1 release - btw I view those as stable enough to use in prod)? Thanks, Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 9:09 PM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Hi Mike, A lot later than anticipated, but finally got some time for betwixt last night :) The reason why it doesn't work for you has 2 reasons : 1) Your .betwixt is incorrect (explaining the exceptions) (see CVS for a good one). You HAVE to have the name property in an element and attribute element. 2) There was indeed a bug in betwixt that prevented elements without any updater (in your case a setBody() , to set the attribute values in the bean (in your case setName and setStatus). Betwixt now checks to see if there are any attributes present and tries to set values in that scenario. Hope this helps and not too late ;) Mvgr, Martin On Wed, 2003-11-12 at 15:37, Mike Stanley wrote: ok. and yes you have permission to use it in any way that matters. I just looked it over though, and I accidentally included copyright disclaimers at the top of some of the files. I will resend them without the disclaimers. It was written from scratch, no real world code used, completely fictitious -- my class templates include the disclaimer and I just forgot to remove it in some places. I can either resend it with this stuff removed - or - give you permission to remove it and add the APL to it. Whatever satisfies the legal requirement. Your call. Thanks, and like I said before I'd be more than happy to look into / patch the issue(s). Just waiting for confirmation. - Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 9:21 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... I'll try to find some time to confirm it tonight, but since a lot of family matters atm, that time can be consumed by that.. Do we have permission (when needed) to add your scenario to the betwixt CVS tree ? (and therefor give it an apache license?) Mvgr, Martin On Wed, 2003-11-12 at 15:12, Mike Stanley wrote: Please confirm this is a bug, or please offer some advice on what I'm doing wrong. If this isn't sufficient to confirm the bug please let me know, and I will modify the example. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2003 2:07 PM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... here is a zipped up eclipse project (minus the jar dependencies). There is a unit test that demonstrates the bug that I'm talking about. The unit test has to test methods, testGetAsXml which passes, and testParseMsg which fails. Aside from the betwixt dependencies, this project is also dependent on log4j, and commons-lang. Hope this provides a decent enough demo of the bugs. Note: I've tried this with the alpha release of betwixt, as well as the snapshot from 2/11/2003. When using the snapshot, the testGetAsXml fails with a null pointer exception. The alpha release shows the marshalling/unmarshalling behavior noted in this thread. I also tried variations on the parser configurations. Thanks for the help. - Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Sunday, November 09, 2003 12:14 PM To: Jakarta Commons Developers List Subject: RE: Betwixt troubles... Can you supply us with a tescase that shows us the bahaviour (esp that you believe it is a bug), since there is too little info in the mail to test this (we needs the beans / bean. One thing I know is that eg Bean.betwixt files only supplies beaninfo for Bean.java and not for any classes embedded in Bean.java. Mvgr, Martin On
Re: [collections] CaseInsensitiveHashMap
On Mon, 2003-11-24 at 10:15, David Graham wrote: --- Janek Bogucki [EMAIL PROTECTED] wrote: On Sun, 2003-11-23 at 21:53, Phil Steitz wrote: A few weeks back, David Graham submitted code for a CaseInsensitiveHashMap here: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24537 This looks like a good addition to [collections] to me. Any objections to my coding up some tests and adding this class to the map package? Phil It might be best to use an instance of o.a.c.c.decorators.TransformedMap with a lower case key transformer and a null value transformer to implement this class. Even though the posted implementation is simple, using the decorator removes the need to have the 'plumbing' code currently present -- and illustrates the use of the collections library. That's a good idea. I was not aware of TransformedMap or the Transformer interface. It seems like they were designed to avoid writing classes like CaseInsensitiveHashMap :-). However, it only transforms objects on put() calls and not on get(). That behavior would need to change. David Umm, I didn't notice #get did not apply the transformation. Perhaps not such a good idea to use TransformedMap after all. This behaviour is certainly different to my expectations (although the documentation is clear enough on this point). I wonder what the original use-case for TransformedMap was. If the database client code restricts itself to using lowercase names (an aspect you are in control of) TransformedMap could still be useful but hardly as convenient as the original case insensitive map. -Janek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration]Resolving constants
Hi,
I had an idea for another small enhancement and want to ask if you find
it useful.
I had sometimes the problem that I had to store a value in a
configuration file that was defined as a constant in a Java class. E.g.
let there be the following declaration in a class:
public static final int ANSWER_TO_ALL = 42;
It would now be nice (for the sake of consistency and readability) to
write something in a configuration file like
myProperty = ${mypackage.MyClass.ANSWER_TO_ALL}
instead of a more cryptic myProperty = 42. I think, this is quite easy
to implement. I would modify AbstractConfiguration.addProperty() to call
a new resolve() method. This resolve() Method would check for string
properties if they match a certain pattern (like the ant notation
${...}) and if yes, try to fetch the constant value via reflection. Do
you think this feature is worth to be added to configuration?
What are you planning to change to make configuration ready for the
first release? I was thinking about this, too, and came up with two
points that could be improved:
1. Exception handling: There are some methods (especially for loading
configuration files) that have a throws Exception clause. This is quite
ugly in my opinion and should be replaced, maybe by a new
ConfigurationException. Though I am not sure about the best strategy.
For server sided applications, when an exception during loading
configuration files usually means a deloyment problem, throwing a
runtime exception might be sufficient. But other use cases will have
probably other requirements.
2. Sometimes inconsistent interfaces: This refers to some of the
concrete subclasses of AbstractConfiguration. Some of them have load()
methods with different signatures, some have save() methods, others
don't. It would be nice to have a common pattern here, but I don't
consider this very critical.
Oli
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [betwixt] Betwixt troubles...
On Mon, 2003-11-24 at 16:40, Mike Stanley wrote: Ok cool. Thanks for looking into this for me. (don't worry about it being late, not a big deal. I just had to use Castor for the unmarshalling and Betwixt for the Marshalling - not really the most elegant but it did the trick temporarily. It's actually funny, because I tried just switching to Castor completely, but was unable to do the complex marshalling with it, however it did manage to handle the unmarshalling well. ;-) 1) Somehow I got it in my head that the name attribute was optional if the property attribute was present, and that the property this would cause the name of the element/attribute to be the default value (based off the property). 2) Ok. So what is the best thing to do. Should I grab a CVS snapshot? Is this pretty stable (comparable to the 2/2003 snapshot, and/or alpha 1 release - btw I view those as stable enough to use in prod)? Don't know if Robert has anything in the pipeline for betwixt (haven't spoken to him yet), but I think it is pretty solid. I still have to look at the todo's that are present and 2 bug that is pending (if a value is null an empty element or attribute will be created, which results in an empty string when marshalling, instead of not setting the variable) and commons-sql has some issue with betwixt too, but I think I fixed that with my commit from last night. It's probably time for a release anyway (eg alpha-2), since a lot of things got fixed since the last release. Since the last release also a big refactor took place, but the test coverage has almost doubled, so I am pretty confident in the stability.. Hope this helps.. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [betwixt] Betwixt troubles...
One other question: You said something about Bean.betwixt files only supplies beaninfo for Bean.java and not classes embedded in Bean.java. If I have BeanA.java and BeanA.betwixt. I also have BeanB.java and BeanB.betwixt. My BeanA class has a property of type BeanB. Will Betwixt be able to marshall/unmarshall this correctly? i.e. beanA beanB propertyXvalue/propertyX /beanB /beanA --- but again, I will need the betwixt files to map beans to the XML (which I need to conform to and is out of my control). Thanks for the help. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 10:41 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Ok cool. Thanks for looking into this for me. (don't worry about it being late, not a big deal. I just had to use Castor for the unmarshalling and Betwixt for the Marshalling - not really the most elegant but it did the trick temporarily. It's actually funny, because I tried just switching to Castor completely, but was unable to do the complex marshalling with it, however it did manage to handle the unmarshalling well. ;-) 1) Somehow I got it in my head that the name attribute was optional if the property attribute was present, and that the property this would cause the name of the element/attribute to be the default value (based off the property). 2) Ok. So what is the best thing to do. Should I grab a CVS snapshot? Is this pretty stable (comparable to the 2/2003 snapshot, and/or alpha 1 release - btw I view those as stable enough to use in prod)? Thanks, Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 9:09 PM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Hi Mike, A lot later than anticipated, but finally got some time for betwixt last night :) The reason why it doesn't work for you has 2 reasons : 1) Your .betwixt is incorrect (explaining the exceptions) (see CVS for a good one). You HAVE to have the name property in an element and attribute element. 2) There was indeed a bug in betwixt that prevented elements without any updater (in your case a setBody() , to set the attribute values in the bean (in your case setName and setStatus). Betwixt now checks to see if there are any attributes present and tries to set values in that scenario. Hope this helps and not too late ;) Mvgr, Martin On Wed, 2003-11-12 at 15:37, Mike Stanley wrote: ok. and yes you have permission to use it in any way that matters. I just looked it over though, and I accidentally included copyright disclaimers at the top of some of the files. I will resend them without the disclaimers. It was written from scratch, no real world code used, completely fictitious -- my class templates include the disclaimer and I just forgot to remove it in some places. I can either resend it with this stuff removed - or - give you permission to remove it and add the APL to it. Whatever satisfies the legal requirement. Your call. Thanks, and like I said before I'd be more than happy to look into / patch the issue(s). Just waiting for confirmation. - Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 9:21 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... I'll try to find some time to confirm it tonight, but since a lot of family matters atm, that time can be consumed by that.. Do we have permission (when needed) to add your scenario to the betwixt CVS tree ? (and therefor give it an apache license?) Mvgr, Martin On Wed, 2003-11-12 at 15:12, Mike Stanley wrote: Please confirm this is a bug, or please offer some advice on what I'm doing wrong. If this isn't sufficient to confirm the bug please let me know, and I will modify the example. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2003 2:07 PM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... here is a zipped up eclipse project (minus the jar dependencies). There is a unit test that demonstrates the bug that I'm talking about. The unit test has to test methods, testGetAsXml which passes, and testParseMsg which fails. Aside from the betwixt dependencies, this project is also dependent on log4j, and commons-lang. Hope this provides a decent enough demo of the bugs. Note: I've tried this with the alpha release of betwixt, as well as the snapshot from 2/11/2003. When using the snapshot, the testGetAsXml
RE: [betwixt] Betwixt troubles...
That should be possible :) You cannot however from BeanA.betwixt also format the content of BeanB.java.. That was one of the mistakes I made when first started using betwixt.. Mvgr, Martin On Mon, 2003-11-24 at 16:57, Mike Stanley wrote: One other question: You said something about Bean.betwixt files only supplies beaninfo for Bean.java and not classes embedded in Bean.java. If I have BeanA.java and BeanA.betwixt. I also have BeanB.java and BeanB.betwixt. My BeanA class has a property of type BeanB. Will Betwixt be able to marshall/unmarshall this correctly? i.e. beanA beanB propertyXvalue/propertyX /beanB /beanA --- but again, I will need the betwixt files to map beans to the XML (which I need to conform to and is out of my control). Thanks for the help. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 10:41 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Ok cool. Thanks for looking into this for me. (don't worry about it being late, not a big deal. I just had to use Castor for the unmarshalling and Betwixt for the Marshalling - not really the most elegant but it did the trick temporarily. It's actually funny, because I tried just switching to Castor completely, but was unable to do the complex marshalling with it, however it did manage to handle the unmarshalling well. ;-) 1) Somehow I got it in my head that the name attribute was optional if the property attribute was present, and that the property this would cause the name of the element/attribute to be the default value (based off the property). 2) Ok. So what is the best thing to do. Should I grab a CVS snapshot? Is this pretty stable (comparable to the 2/2003 snapshot, and/or alpha 1 release - btw I view those as stable enough to use in prod)? Thanks, Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 9:09 PM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Hi Mike, A lot later than anticipated, but finally got some time for betwixt last night :) The reason why it doesn't work for you has 2 reasons : 1) Your .betwixt is incorrect (explaining the exceptions) (see CVS for a good one). You HAVE to have the name property in an element and attribute element. 2) There was indeed a bug in betwixt that prevented elements without any updater (in your case a setBody() , to set the attribute values in the bean (in your case setName and setStatus). Betwixt now checks to see if there are any attributes present and tries to set values in that scenario. Hope this helps and not too late ;) Mvgr, Martin On Wed, 2003-11-12 at 15:37, Mike Stanley wrote: ok. and yes you have permission to use it in any way that matters. I just looked it over though, and I accidentally included copyright disclaimers at the top of some of the files. I will resend them without the disclaimers. It was written from scratch, no real world code used, completely fictitious -- my class templates include the disclaimer and I just forgot to remove it in some places. I can either resend it with this stuff removed - or - give you permission to remove it and add the APL to it. Whatever satisfies the legal requirement. Your call. Thanks, and like I said before I'd be more than happy to look into / patch the issue(s). Just waiting for confirmation. - Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 9:21 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... I'll try to find some time to confirm it tonight, but since a lot of family matters atm, that time can be consumed by that.. Do we have permission (when needed) to add your scenario to the betwixt CVS tree ? (and therefor give it an apache license?) Mvgr, Martin On Wed, 2003-11-12 at 15:12, Mike Stanley wrote: Please confirm this is a bug, or please offer some advice on what I'm doing wrong. If this isn't sufficient to confirm the bug please let me know, and I will modify the example. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2003 2:07 PM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... here is a zipped up eclipse project (minus the jar dependencies). There is a unit test that demonstrates the bug that I'm talking about. The unit test has to test methods, testGetAsXml which passes, and
RE: [betwixt] Betwixt troubles...
Ah, Cool. Thanks. -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 11:07 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... That should be possible :) You cannot however from BeanA.betwixt also format the content of BeanB.java.. That was one of the mistakes I made when first started using betwixt.. Mvgr, Martin On Mon, 2003-11-24 at 16:57, Mike Stanley wrote: One other question: You said something about Bean.betwixt files only supplies beaninfo for Bean.java and not classes embedded in Bean.java. If I have BeanA.java and BeanA.betwixt. I also have BeanB.java and BeanB.betwixt. My BeanA class has a property of type BeanB. Will Betwixt be able to marshall/unmarshall this correctly? i.e. beanA beanB propertyXvalue/propertyX /beanB /beanA --- but again, I will need the betwixt files to map beans to the XML (which I need to conform to and is out of my control). Thanks for the help. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 10:41 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Ok cool. Thanks for looking into this for me. (don't worry about it being late, not a big deal. I just had to use Castor for the unmarshalling and Betwixt for the Marshalling - not really the most elegant but it did the trick temporarily. It's actually funny, because I tried just switching to Castor completely, but was unable to do the complex marshalling with it, however it did manage to handle the unmarshalling well. ;-) 1) Somehow I got it in my head that the name attribute was optional if the property attribute was present, and that the property this would cause the name of the element/attribute to be the default value (based off the property). 2) Ok. So what is the best thing to do. Should I grab a CVS snapshot? Is this pretty stable (comparable to the 2/2003 snapshot, and/or alpha 1 release - btw I view those as stable enough to use in prod)? Thanks, Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 9:09 PM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Hi Mike, A lot later than anticipated, but finally got some time for betwixt last night :) The reason why it doesn't work for you has 2 reasons : 1) Your .betwixt is incorrect (explaining the exceptions) (see CVS for a good one). You HAVE to have the name property in an element and attribute element. 2) There was indeed a bug in betwixt that prevented elements without any updater (in your case a setBody() , to set the attribute values in the bean (in your case setName and setStatus). Betwixt now checks to see if there are any attributes present and tries to set values in that scenario. Hope this helps and not too late ;) Mvgr, Martin On Wed, 2003-11-12 at 15:37, Mike Stanley wrote: ok. and yes you have permission to use it in any way that matters. I just looked it over though, and I accidentally included copyright disclaimers at the top of some of the files. I will resend them without the disclaimers. It was written from scratch, no real world code used, completely fictitious -- my class templates include the disclaimer and I just forgot to remove it in some places. I can either resend it with this stuff removed - or - give you permission to remove it and add the APL to it. Whatever satisfies the legal requirement. Your call. Thanks, and like I said before I'd be more than happy to look into / patch the issue(s). Just waiting for confirmation. - Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 9:21 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... I'll try to find some time to confirm it tonight, but since a lot of family matters atm, that time can be consumed by that.. Do we have permission (when needed) to add your scenario to the betwixt CVS tree ? (and therefor give it an apache license?) Mvgr, Martin On Wed, 2003-11-12 at 15:12, Mike Stanley wrote: Please confirm this is a bug, or please offer some advice on what I'm doing wrong. If this isn't sufficient to confirm the bug please let me know, and I will modify the example. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, November 10,
RE: [betwixt] Betwixt troubles...
I'm sorry - I'm turning into a pain in the ass --- how about properties of properties i.e. attribute name=name property=beanB.name/ -- would this be handled beanA.getBeanB().getName() appropriately? Figured, I'd ask while I have your ear ;-) -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 11:07 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... That should be possible :) You cannot however from BeanA.betwixt also format the content of BeanB.java.. That was one of the mistakes I made when first started using betwixt.. Mvgr, Martin On Mon, 2003-11-24 at 16:57, Mike Stanley wrote: One other question: You said something about Bean.betwixt files only supplies beaninfo for Bean.java and not classes embedded in Bean.java. If I have BeanA.java and BeanA.betwixt. I also have BeanB.java and BeanB.betwixt. My BeanA class has a property of type BeanB. Will Betwixt be able to marshall/unmarshall this correctly? i.e. beanA beanB propertyXvalue/propertyX /beanB /beanA --- but again, I will need the betwixt files to map beans to the XML (which I need to conform to and is out of my control). Thanks for the help. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 10:41 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Ok cool. Thanks for looking into this for me. (don't worry about it being late, not a big deal. I just had to use Castor for the unmarshalling and Betwixt for the Marshalling - not really the most elegant but it did the trick temporarily. It's actually funny, because I tried just switching to Castor completely, but was unable to do the complex marshalling with it, however it did manage to handle the unmarshalling well. ;-) 1) Somehow I got it in my head that the name attribute was optional if the property attribute was present, and that the property this would cause the name of the element/attribute to be the default value (based off the property). 2) Ok. So what is the best thing to do. Should I grab a CVS snapshot? Is this pretty stable (comparable to the 2/2003 snapshot, and/or alpha 1 release - btw I view those as stable enough to use in prod)? Thanks, Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 9:09 PM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Hi Mike, A lot later than anticipated, but finally got some time for betwixt last night :) The reason why it doesn't work for you has 2 reasons : 1) Your .betwixt is incorrect (explaining the exceptions) (see CVS for a good one). You HAVE to have the name property in an element and attribute element. 2) There was indeed a bug in betwixt that prevented elements without any updater (in your case a setBody() , to set the attribute values in the bean (in your case setName and setStatus). Betwixt now checks to see if there are any attributes present and tries to set values in that scenario. Hope this helps and not too late ;) Mvgr, Martin On Wed, 2003-11-12 at 15:37, Mike Stanley wrote: ok. and yes you have permission to use it in any way that matters. I just looked it over though, and I accidentally included copyright disclaimers at the top of some of the files. I will resend them without the disclaimers. It was written from scratch, no real world code used, completely fictitious -- my class templates include the disclaimer and I just forgot to remove it in some places. I can either resend it with this stuff removed - or - give you permission to remove it and add the APL to it. Whatever satisfies the legal requirement. Your call. Thanks, and like I said before I'd be more than happy to look into / patch the issue(s). Just waiting for confirmation. - Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 9:21 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... I'll try to find some time to confirm it tonight, but since a lot of family matters atm, that time can be consumed by that.. Do we have permission (when needed) to add your scenario to the betwixt CVS tree ? (and therefor give it an apache license?) Mvgr, Martin On Wed, 2003-11-12 at 15:12, Mike Stanley wrote: Please confirm this is a bug, or please offer some advice on what I'm doing wrong. If this isn't sufficient to
[RESULT] Re: [PROPOSAL] emeritus committers?
With 6 binding +1s [Rodney Waldhoff, David Graham, Yoav Shapira, Martin Cooper, Gary Gregory, Robert Burrell Donkin] and no -1s, this vote has passed. As noted in the thread, Arun and Ted have been otherwise active, so that leaves the following 14 committers being moved to emeritus status: arron - Arron Bates conor - Conor MacNeill dsale - Doug Sale dwinterfeldt - David Winterfeldt hammant - Paul Hammant jariw - jariw AT hyperlink-interactive DOT co DOT uk jefft - Jeff Turner marcsaeg - Marc Saegesser mas - Michael Smith nacho - Ignacio J. Ortega noel - Noel J. Bergman paulo - Paulo Gaspar serge - Serge Knystautas vmassol - Vincent Massol I can set up the emeritus committers page today, but I don't think I've got karma for modifying the avail file. Can someone volunteer to take care of the avail file? On Thu, 13 Nov 2003, Rodney Waldhoff wrote: There is a perception in some circles that Jakarta as a whole, and Jakarta Commons in particular, is too large for sufficient PMC oversight. In my opinion, particularly with respect to Jakarta Commons, this is not the case, but one way to combat that perception is to recognize that although the CVS avail file lists 72 committers for the jakarta-commons repository (see http://cvs.apache.org/~rwaldhoff/jakarta/jakarta-committers.html), not all of those folks are actively working in Jakarta Commons anymore. Removing inactive committers from the avail file (and naming them emeritus committers) is one way to recognize that fact. The jakarta guidelines state At times, Committers may go inactive for a variety of reasons. A Committer that has been inactive for 6 months or more may lose their status as a Committer. Getting access back is as simple as re-requesting it on the project's Developer mailing list. http://jakarta.apache.org/site/roles.html The following 16 folks are listed in the CVS avail file, but have not made any commits in the past year (since 13 Nov 2002): amamment - Arun Mammen Thomas arron - Arron Bates conor - Conor MacNeill dsale - Doug Sale dwinterfeldt - David Winterfeldt hammant - Paul Hammant husted - Ted Husted jariw - jariw AT hyperlink-interactive DOT co DOT uk jefft - Jeff Turner marcsaeg - Marc Saegesser mas - Michael Smith nacho - Ignacio J. Ortega noel - Noel J. Bergman paulo - Paulo Gaspar serge - Serge Knystautas vmassol - Vincent Massol It may be that some of these folks have been active in non-CVS ways, for instance, by posting to the commons-user or commons-dev lists, I haven't checked (nor am I exactly sure how I could programmaticly check that). Removing those 16 would reduce the number of active committers to 56, a more that 20% reduction in the perceived size of jakarta-commons (by that metric at least). Just to clarify, I have no issues with any or all of those folks maintaining access to the jakarta-commons CVS module, nor is this some sort of judgment of a lack of activity (indeed there are a number of folks on that list that I have a lot of respect for). Rather, this is a recognition that those folks have moved on for the time being and an attempt to make the perceived size of Jakarta Commons more accurately reflect the reality of the matter. As the guidelines state, a simple post to commons-dev would be all that is needed to restore direct CVS access and reverse the inactive status. The Proposal: Unless anyone on that list wants to declare themselves active right now (or someone else can vouch for some sort of commons related activity in the past year or so), let's invoke that paragraph of the jakarta guidelines and declare these folks inactive committers. Specifically, let's: (1) remove those folks from the avail file and (2) add an emeritus committers page (or section of some existing page) to the jakarta-commons website that acknowledges their contributions and indicates the mechanism by which they can once again get CVS access. -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [betwixt] Betwixt troubles...
Don't think that works, since I cannot remember any code that resolves the dot in betwixt (I written a library who can handle this though, which is not betwixt related..), so maybe someday :) Mvgr, Martin On Mon, 2003-11-24 at 17:16, Mike Stanley wrote: I'm sorry - I'm turning into a pain in the ass --- how about properties of properties i.e. attribute name=name property=beanB.name/ -- would this be handled beanA.getBeanB().getName() appropriately? Figured, I'd ask while I have your ear ;-) -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 11:07 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... That should be possible :) You cannot however from BeanA.betwixt also format the content of BeanB.java.. That was one of the mistakes I made when first started using betwixt.. Mvgr, Martin On Mon, 2003-11-24 at 16:57, Mike Stanley wrote: One other question: You said something about Bean.betwixt files only supplies beaninfo for Bean.java and not classes embedded in Bean.java. If I have BeanA.java and BeanA.betwixt. I also have BeanB.java and BeanB.betwixt. My BeanA class has a property of type BeanB. Will Betwixt be able to marshall/unmarshall this correctly? i.e. beanA beanB propertyXvalue/propertyX /beanB /beanA --- but again, I will need the betwixt files to map beans to the XML (which I need to conform to and is out of my control). Thanks for the help. - Mike -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 10:41 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Ok cool. Thanks for looking into this for me. (don't worry about it being late, not a big deal. I just had to use Castor for the unmarshalling and Betwixt for the Marshalling - not really the most elegant but it did the trick temporarily. It's actually funny, because I tried just switching to Castor completely, but was unable to do the complex marshalling with it, however it did manage to handle the unmarshalling well. ;-) 1) Somehow I got it in my head that the name attribute was optional if the property attribute was present, and that the property this would cause the name of the element/attribute to be the default value (based off the property). 2) Ok. So what is the best thing to do. Should I grab a CVS snapshot? Is this pretty stable (comparable to the 2/2003 snapshot, and/or alpha 1 release - btw I view those as stable enough to use in prod)? Thanks, Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 9:09 PM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... Hi Mike, A lot later than anticipated, but finally got some time for betwixt last night :) The reason why it doesn't work for you has 2 reasons : 1) Your .betwixt is incorrect (explaining the exceptions) (see CVS for a good one). You HAVE to have the name property in an element and attribute element. 2) There was indeed a bug in betwixt that prevented elements without any updater (in your case a setBody() , to set the attribute values in the bean (in your case setName and setStatus). Betwixt now checks to see if there are any attributes present and tries to set values in that scenario. Hope this helps and not too late ;) Mvgr, Martin On Wed, 2003-11-12 at 15:37, Mike Stanley wrote: ok. and yes you have permission to use it in any way that matters. I just looked it over though, and I accidentally included copyright disclaimers at the top of some of the files. I will resend them without the disclaimers. It was written from scratch, no real world code used, completely fictitious -- my class templates include the disclaimer and I just forgot to remove it in some places. I can either resend it with this stuff removed - or - give you permission to remove it and add the APL to it. Whatever satisfies the legal requirement. Your call. Thanks, and like I said before I'd be more than happy to look into / patch the issue(s). Just waiting for confirmation. - Mike -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 9:21 AM To: Jakarta Commons Developers List Subject: RE: [betwixt] Betwixt troubles... I'll try to find some time to confirm it tonight, but since a lot of family matters atm,
cvs commit: jakarta-commons/docs contributors.html
rwaldhoff2003/11/24 08:57:57 Modified:xdocscontributors.xml docs contributors.html Log: add emeritus section, update committer list Revision ChangesPath 1.17 +83 -29jakarta-commons/xdocs/contributors.xml Index: contributors.xml === RCS file: /home/cvs/jakarta-commons/xdocs/contributors.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- contributors.xml 2 Nov 2003 19:27:55 - 1.16 +++ contributors.xml 24 Nov 2003 16:57:57 - 1.17 @@ -8,37 +8,91 @@ section name=Contributors pWe are the participants in Commons:/p ul -liStephen Colebourne/li -liMartin Cooper/li -liMorgan Delagrange/li -lidIon Gillard/li -liDavid Graham/li -liMatthew Hawthorne/li -liB.C. Holmes/li -liTed Husted/li -liConor MacNeill/li -liGeir Magnusson Jr./li -liCostin Manolache/li -liVincent Massol/li -liRemy Maucherat/li -liCraig R. McClanahan/li -liTim O'Brien/li -liIgnacio J. Ortega/li -liSung-Gu Park/li -liJuergen Pill/li -liDoug Sale/li -liScott Sanders/li -liYoav Shapira/li -liRichard A. Sitze/li -liPhil Steitz/li -liJames Strachan/li -liDirk Verbeeck/li -liRodney Waldhoff/li -liDavid Weinrich/li -liJari Worsley/li -liHenri Yandell/li +!-- alpha by userid, feel free to sort otherwise -- +liAdrian Sutton (adrian)/li +liAlex Chaffee (alex)/li +liArun Mammen Thomas (amamment)/li +liJuozas Baliuka (baliuka)/li +liHenri Yandell (bayard)/li +liJeff Brekke (brekke)/li +liBruno D'Avanzo (brudav)/li +liCostin Manolache (costin)/li +liCraig R. McClanahan (craigmcc)/li +liDaniel F. Savarese (dfs)/li +liDavid Graham (dgraham)/li +liDavanum Srinivas (dims)/li +liDion Gillard (dion)/li +liDirk Verbeeck (dirkv)/li +liDaniel Rall (dlr)/li +liDmitri Plotnikov (dmitri)/li +liFredrik Westermarck (fredrik)/li +liGeir Magnusson Jr. (geirm)/li +liGary Gregory (ggregory)/li +liGlenn Nielsen (glenn)/li +liTed Husted (husted)/li +liSung-Gu Park (jericho)/li +liJean-Frederic Clere (jfclere)/li +liJohn Keyes (jkeyes)/li +liJohn McNally (jmcnally)/li +liJon Stevens (jon)/li +liJeff Dever (jsdever)/li +liJames Strachan (jstrachan)/li +liJason van Zyl (jvanzyl)/li +liJan Luehe (luehe)/li +liMartin Cooper (martinc)/li +liMatthew Hawthorne (matth)/li +liMichael Becke (mbecke)/li +liMark R. Diggory (mdiggory)/li +liMorgan Delagrange (morgand)/li +liMartin Poeschl (mpoeschl)/li +liMladen Turk (mturk)/li +liMartin van den Bemt (mvdb)/li +liOrtwin Gluck (oglueck)/li +liOleg Kalnichevski (olegk)/li +liPatrick Luby (patrickl)/li +liPeter Royal (proyal)/li +liPhil Steitz (psteitz)/li +liRobert Burrell Donkin (rdonkin)/li +liRemy Maucherat (remm)/li +liRobert Leland (rleland)/li +liRichard Sitze (rsitze)/li +liRodney Waldhoff (rwaldhoff)/li +liScott Sanders (sanders)/li +liSteve Cohen (scohen)/li +liStephen Colebourne (scolebourne)/li +liShawn Bayern (shawn)/li +liSteven Caswell (stevencaswell)/li +liSean Sullivan (sullis)/li +liTim O'Brien (tobrien)/li +liJames Turner (turner)/li +liBob McWhirter (werken)/li +liYoav Shapira (yoavs)/li /ul pJoin us!/p +/section +section name=Emeritus Committers + p + The following committers have made a number of contributions to Jakarta Commons, but have + been inactive for some time. Following the Jakarta project's a href=http://jakarta.apache.org/site/roles.html;guidelines/a, + they have been named emeritus committers. These individuals may be restored to active committer status + simply by requesting it on the commons-dev mailing list. + /p + ul +liArron Bates (arron)/li +liConor MacNeill (conor)/li +liDoug Sale (dsale)/li +liDavid Winterfeldt (dwinterfeldt)/li +liPaul Hammant (hammant)/li +li(jariw)/li +liJeff Turner (jefft)/li +liMarc Saegesser (marcsaeg)/li +liMichael Smith (mas)/li +liIgnacio J. Ortega (nacho)/li +liNoel J. Bergman (noel)/li +liPaulo Gaspar (paulo)/li +liSerge Knystautas (serge)/li +liVincent Massol (vmassol)/li + /ul /section /body /document 1.93 +94 -29jakarta-commons/docs/contributors.html Index: contributors.html === RCS file: /home/cvs/jakarta-commons/docs/contributors.html,v retrieving revision 1.92 retrieving revision 1.93 diff -u -r1.92 -r1.93 ---
cvs commit: jakarta-commons/docs contributors.html
rwaldhoff2003/11/24 09:02:02 Modified:xdocscontributors.xml docs contributors.html Log: move noel and serge to active Revision ChangesPath 1.18 +2 -2 jakarta-commons/xdocs/contributors.xml Index: contributors.xml === RCS file: /home/cvs/jakarta-commons/xdocs/contributors.xml,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- contributors.xml 24 Nov 2003 16:57:57 - 1.17 +++ contributors.xml 24 Nov 2003 17:02:02 - 1.18 @@ -47,6 +47,7 @@ liMartin Poeschl (mpoeschl)/li liMladen Turk (mturk)/li liMartin van den Bemt (mvdb)/li +liNoel J. Bergman (noel)/li liOrtwin Gluck (oglueck)/li liOleg Kalnichevski (olegk)/li liPatrick Luby (patrickl)/li @@ -58,6 +59,7 @@ liRichard Sitze (rsitze)/li liRodney Waldhoff (rwaldhoff)/li liScott Sanders (sanders)/li +liSerge Knystautas (serge)/li liSteve Cohen (scohen)/li liStephen Colebourne (scolebourne)/li liShawn Bayern (shawn)/li @@ -88,9 +90,7 @@ liMarc Saegesser (marcsaeg)/li liMichael Smith (mas)/li liIgnacio J. Ortega (nacho)/li -liNoel J. Bergman (noel)/li liPaulo Gaspar (paulo)/li -liSerge Knystautas (serge)/li liVincent Massol (vmassol)/li /ul /section 1.94 +2 -2 jakarta-commons/docs/contributors.html Index: contributors.html === RCS file: /home/cvs/jakarta-commons/docs/contributors.html,v retrieving revision 1.93 retrieving revision 1.94 diff -u -r1.93 -r1.94 --- contributors.html 24 Nov 2003 16:57:57 - 1.93 +++ contributors.html 24 Nov 2003 17:02:02 - 1.94 @@ -255,6 +255,7 @@ liMartin Poeschl (mpoeschl)/li liMladen Turk (mturk)/li liMartin van den Bemt (mvdb)/li +liNoel J. Bergman (noel)/li liOrtwin Gluck (oglueck)/li liOleg Kalnichevski (olegk)/li liPatrick Luby (patrickl)/li @@ -266,6 +267,7 @@ liRichard Sitze (rsitze)/li liRodney Waldhoff (rwaldhoff)/li liScott Sanders (sanders)/li +liSerge Knystautas (serge)/li liSteve Cohen (scohen)/li liStephen Colebourne (scolebourne)/li liShawn Bayern (shawn)/li @@ -307,9 +309,7 @@ liMarc Saegesser (marcsaeg)/li liMichael Smith (mas)/li liIgnacio J. Ortega (nacho)/li -liNoel J. Bergman (noel)/li liPaulo Gaspar (paulo)/li -liSerge Knystautas (serge)/li liVincent Massol (vmassol)/li /ul /blockquote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
/PROPOSAL 1/ Additions to IteratorUtils
I'd like to propose the following simple additions to the
o.a.c.c.IteratorUtils
class.
The following is a simple convenience method for counting the number of
elements
in an iteration, something that I find myself recreating somewhat
frequently:
public static
int countElements (final Iterator iter) {
int cnt = 0;
while (iter.hasNext ()) {
cnt ++;
}
return cnt;
}
There isn't an EnumeratorUtils present that might contain an equivalent:
public static
int countElements (final Enumerator enum) {
int cnt = 0;
while (enum.hasNext ()) {
cnt ++;
}
return cnt;
}
Or the slightly less performant:
public static
int countElements (final Enumerator enum) {
return IteratorUtils.countElements (asIterator (enum));
}
Thoughts?
--lee
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24369] - Validator.validate() exception handling for ValidatorException
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=24369. 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=24369 Validator.validate() exception handling for ValidatorException --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 17:34 --- I understand that the suggested approach would create an incompatible behavior change. A more thorough analysis of exception handling may take a while to complete. Could we consider changing the assumptions a bit to accommodate an interim solution, as in the following: 1) ValidatorExceptions are propagated as is. 2) Other exceptions continue to work as they do now - i.e., they return false. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] Re: /PROPOSAL 1/ Additions to IteratorUtils
( Remember to prefix subject with [collections] )
In the current CVS HEAD, you can do
IteratorUtils.toArray(Iterator).length
or
IteratorUtils.toList(Iterator).size()
But, your suggestion may be a good addition also.
Also, I think that the method definitions you've provided will all cause
infinite loops -- hasNext() will always return true if you don't call
next(). We'd need to find a way to copy the iterator so we don't modify
it's state when we count the elements.
Anyone else have an opinion?
Lee Crawford wrote:
I'd like to propose the following simple additions to the
o.a.c.c.IteratorUtils
class.
The following is a simple convenience method for counting the number of
elements
in an iteration, something that I find myself recreating somewhat
frequently:
public static
int countElements (final Iterator iter) {
int cnt = 0;
while (iter.hasNext ()) {
cnt ++;
}
return cnt;
}
There isn't an EnumeratorUtils present that might contain an equivalent:
public static
int countElements (final Enumerator enum) {
int cnt = 0;
while (enum.hasNext ()) {
cnt ++;
}
return cnt;
}
Or the slightly less performant:
public static
int countElements (final Enumerator enum) {
return IteratorUtils.countElements (asIterator (enum));
}
Thoughts?
--lee
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] unexpected StringUtils.split behavior (was RE: suggestion for new StringUtils.method)
I also know that this is more than you intended, but any thought of incorporating the
split on string into the new StringTokenizer replacement as well? I think that would
be pretty useful. (It's behaviour in two places, but implementation could certainly
delegate)
-AMT
-Original Message-
From: Al Chou [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2003 10:22 PM
To: Jakarta Commons Developers List
Subject: [lang] unexpected StringUtils.split behavior (was RE: suggestion for new
StringUtils.method)
I guess my previous post got lost in the noise, so I'm reposting. I have two new
StringUtils.split methods that can split a string at occurrences of a substring rather
than splitting at the individual characters in the specified delimiter string.
While testing, I discovered that my expectations for the behavior of the split( *,
..., int max ) methods didn't match their actual behavior. I expected to get a
maximum of max substrings, all of which were delimited in the parent string by the
specified delimiters. Instead, what you get is max - 1 such substrings, plus the
rest of the parent string as the final result substring.
This behavior seems counter to what StringTokenizer would do, which is surprising,
given the Javadoc comments about using the split methods as alternatives to
StringTokenizer.
Currently, my tests reflect my expectations for the behavior, and I modified the
existing split( String, String, int ) method to match my expectations. I didn't want
to submit such a change as a proposed patch without first getting feedback from the
community about whether my expectations are wrong. I am happy to submit only code
that does not change the behavior of the existing methods, if need be.
Al
--- Al Chou [EMAIL PROTECTED] wrote:
This thread is a good entree for my question. I was adding a new
StringUtils.split method that can split a string using a whole string
as the delimiter, rather than the characters within that string. In
running my JUnit tests, I discovered unexpected behavior in the
existing method:
String stringToSplitOnNulls = ab de fg ;
String[] splitOnNullExpectedResults = { ab, de } ;
String[] splitOnNullResults = StringUtils.split( stringToSplitOnNulls,
null, 2
) ;
assertEquals( splitOnNullExpectedResults.length,
splitOnNullResults.length ) ; for ( int i = 0 ; i
splitOnNullExpectedResults.length ; i+= 1 ) {
assertEquals( splitOnNullExpectedResults[i], splitOnNullResults[i] ) ;
}
The result of the split call is
ab, de fg
and it doesn't look to me like StringTokenizer's documentation implies
this behavior
Al
=
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
=
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: TimerMap
Seems like a cool idea However, I'm concerned about the following points in the implementation: If the timer expires after an iterator on the keys or values is obtained, the underlying map is modified directly - this means that the next access to the iterator (see HashMap javadoc) will throw a ConcurrentModificationException. To my mind, this makes iteration over this map fairly difficult, particularly as many algorithms which use maps probably do use iterators to access the data in the map. A possible solution - provide wrapping implementations of Set/Collection which return FilterIterators that filter out expired items during iteration - only deleting those items after all existing iterators have completed iteration or have been destroyed. This gets complicated quickly, however. It seems (perhaps I'm missing something) to be overkill to synchronize all accesses to the TimerMap. I'm not quite sure why this is necessary - I don't think the implementation can guarantee that an object will be expired at the instant the timer runs out - I don't believe TimerTask provides this guarantee. Therefore, the synchronization seems to be unneeded - the expired object will be removed soon after the expiry time is reached. Cheers, -AMT -Original Message- From: Joseph Rosenblum [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 11:04 PM To: [EMAIL PROTECTED] Subject: TimerMap Commons Developers, The attached class is a very simple implementation of the java.util.Map interface that gives each key a TTL (time to live) in the map. I've found this extremely useful as a backing store for certain types of caches (where you want to expire items based on time in cache, as opposed to LRU, etc..) and for tracking services that I want check the availability of. It's called TimerMap and takes a long TTL in the constructor. I'd love to donate this code to the commons, please let me know if you find it useful. -Joe Joseph Rosenblum | 25th Street Networks Easy, Reliable Web Hosting @ http://www.25thstreet.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TimerMap
I wouldn't worry so much about the iterator issue. Remember, this map implementation is to be used in specific cases. And, when somebody uses it, they should probably understand that there are multiple threads modifying the map. I would say that you can get by with a warning in the JavaDoc on this one. No need to get overly complicated here IMHO. -Original Message- From: Arun Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 1:24 PM To: Jakarta Commons Developers List Subject: RE: TimerMap Seems like a cool idea However, I'm concerned about the following points in the implementation: If the timer expires after an iterator on the keys or values is obtained, the underlying map is modified directly - this means that the next access to the iterator (see HashMap javadoc) will throw a ConcurrentModificationException. To my mind, this makes iteration over this map fairly difficult, particularly as many algorithms which use maps probably do use iterators to access the data in the map. A possible solution - provide wrapping implementations of Set/Collection which return FilterIterators that filter out expired items during iteration - only deleting those items after all existing iterators have completed iteration or have been destroyed. This gets complicated quickly, however. It seems (perhaps I'm missing something) to be overkill to synchronize all accesses to the TimerMap. I'm not quite sure why this is necessary - I don't think the implementation can guarantee that an object will be expired at the instant the timer runs out - I don't believe TimerTask provides this guarantee. Therefore, the synchronization seems to be unneeded - the expired object will be removed soon after the expiry time is reached. Cheers, -AMT -Original Message- From: Joseph Rosenblum [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 11:04 PM To: [EMAIL PROTECTED] Subject: TimerMap Commons Developers, The attached class is a very simple implementation of the java.util.Map interface that gives each key a TTL (time to live) in the map. I've found this extremely useful as a backing store for certain types of caches (where you want to expire items based on time in cache, as opposed to LRU, etc..) and for tracking services that I want check the availability of. It's called TimerMap and takes a long TTL in the constructor. I'd love to donate this code to the commons, please let me know if you find it useful. -Joe Joseph Rosenblum | 25th Street Networks Easy, Reliable Web Hosting @ http://www.25thstreet.net/ - 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: [collections] CaseInsensitiveHashMap
--- Janek Bogucki [EMAIL PROTECTED] wrote: On Mon, 2003-11-24 at 10:15, David Graham wrote: --- Janek Bogucki [EMAIL PROTECTED] wrote: On Sun, 2003-11-23 at 21:53, Phil Steitz wrote: A few weeks back, David Graham submitted code for a CaseInsensitiveHashMap here: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24537 This looks like a good addition to [collections] to me. Any objections to my coding up some tests and adding this class to the map package? Phil It might be best to use an instance of o.a.c.c.decorators.TransformedMap with a lower case key transformer and a null value transformer to implement this class. Even though the posted implementation is simple, using the decorator removes the need to have the 'plumbing' code currently present -- and illustrates the use of the collections library. That's a good idea. I was not aware of TransformedMap or the Transformer interface. It seems like they were designed to avoid writing classes like CaseInsensitiveHashMap :-). However, it only transforms objects on put() calls and not on get(). That behavior would need to change. David Umm, I didn't notice #get did not apply the transformation. Perhaps not such a good idea to use TransformedMap after all. This behaviour is certainly different to my expectations (although the documentation is clear enough on this point). I wonder what the original use-case for TransformedMap was. If the database client code restricts itself to using lowercase names (an aspect you are in control of) TransformedMap could still be useful but hardly as convenient as the original case insensitive map. It's a requirement that DbUtils clients use whatever case they want to refer to column names in a Map so TransformedMap as it is now won't work. Regardless, DbUtils doesn't have a dependency on collections and shouldn't add one just for this feature. The implementation of CaseInsensitiveHashMap is trivial enough to maintain in DbUtils. I opened the enhancement against collections in case anyone else had a need for this kind of Map. If TransformedMap doesn't change then I think adding CaseInsensitiveMap is the best solution. -Janek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24369] - Validator.validate() exception handling for ValidatorException
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=24369. 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=24369 Validator.validate() exception handling for ValidatorException --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 18:40 --- Sounds good to me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24949] New: - LocaleBeanUtils.getInstance() returns null when called
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=24949. 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=24949 LocaleBeanUtils.getInstance() returns null when called Summary: LocaleBeanUtils.getInstance() returns null when called Product: Commons Version: unspecified Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Bean Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I call the LocaleBeanUtils.getInstance() it returns an null value instead of creating a new instance if required. I am making a patch for solving this singleton problem in the same way as BeanUtils.getInstance(). Soon I will be posting this here... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core ConstantPredicate.java
rwaldhoff2003/11/24 12:31:20 Modified:functor/src/test/org/apache/commons/functor/adapter TestBinaryFunctionBinaryPredicate.java TestFunctionPredicate.java TestUnaryFunctionUnaryPredicate.java functor/src/test/org/apache/commons/functor/core TestIsInstanceOf.java TestIsNotEqual.java TestIsNotNull.java TestConstantPredicate.java TestIsNull.java TestIsEqual.java functor/src/test/org/apache/commons/functor/core/collection TestIsElementOf.java TestPredicatedIterator.java functor/src/test/org/apache/commons/functor/core/composite TestBinaryNot.java TestTransposedPredicate.java TestOr.java TestNot.java TestUnaryOr.java TestUnaryAnd.java TestAnd.java TestBinaryAnd.java TestUnaryNot.java TestBinaryOr.java functor/src/java/org/apache/commons/functor/core ConstantPredicate.java Log: rename ConstantPredicate static methods Revision ChangesPath 1.3 +3 -3 jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/adapter/TestBinaryFunctionBinaryPredicate.java Index: TestBinaryFunctionBinaryPredicate.java === RCS file: /home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/adapter/TestBinaryFunctionBinaryPredicate.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- TestBinaryFunctionBinaryPredicate.java28 Jan 2003 12:00:30 - 1.2 +++ TestBinaryFunctionBinaryPredicate.java24 Nov 2003 20:31:19 - 1.3 @@ -136,7 +136,7 @@ BinaryPredicate p = new BinaryFunctionBinaryPredicate(new ConstantFunction(Boolean.TRUE)); assertEquals(p,p); assertObjectsAreEqual(p,new BinaryFunctionBinaryPredicate(new ConstantFunction(Boolean.TRUE))); -assertObjectsAreNotEqual(p,ConstantPredicate.getTruePredicate()); +assertObjectsAreNotEqual(p,ConstantPredicate.trueInstance()); assertObjectsAreNotEqual(p,new BinaryFunctionBinaryPredicate(null)); assertObjectsAreNotEqual(p,new BinaryFunctionBinaryPredicate(new ConstantFunction(Boolean.FALSE))); assertObjectsAreEqual(new BinaryFunctionBinaryPredicate(null),new BinaryFunctionBinaryPredicate(null)); 1.2 +3 -3 jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/adapter/TestFunctionPredicate.java Index: TestFunctionPredicate.java === RCS file: /home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/adapter/TestFunctionPredicate.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- TestFunctionPredicate.java27 Jan 2003 19:33:41 - 1.1 +++ TestFunctionPredicate.java24 Nov 2003 20:31:19 - 1.2 @@ -136,7 +136,7 @@ Predicate p = new FunctionPredicate(new ConstantFunction(Boolean.TRUE)); assertEquals(p,p); assertObjectsAreEqual(p,new FunctionPredicate(new ConstantFunction(Boolean.TRUE))); -assertObjectsAreNotEqual(p,ConstantPredicate.getTruePredicate()); +assertObjectsAreNotEqual(p,ConstantPredicate.trueInstance()); assertObjectsAreNotEqual(p,new FunctionPredicate(null)); assertObjectsAreNotEqual(p,new FunctionPredicate(new ConstantFunction(Boolean.FALSE))); assertObjectsAreEqual(new FunctionPredicate(null),new FunctionPredicate(null)); 1.3 +3 -3 jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/adapter/TestUnaryFunctionUnaryPredicate.java Index: TestUnaryFunctionUnaryPredicate.java === RCS file: /home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/adapter/TestUnaryFunctionUnaryPredicate.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- TestUnaryFunctionUnaryPredicate.java 28 Jan 2003 12:00:30 - 1.2 +++ TestUnaryFunctionUnaryPredicate.java 24 Nov 2003 20:31:19 - 1.3 @@ -136,7 +136,7 @@ UnaryPredicate p = new UnaryFunctionUnaryPredicate(new ConstantFunction(Boolean.TRUE)); assertEquals(p,p); assertObjectsAreEqual(p,new UnaryFunctionUnaryPredicate(new ConstantFunction(Boolean.TRUE))); -assertObjectsAreNotEqual(p,ConstantPredicate.getTruePredicate()); +assertObjectsAreNotEqual(p,ConstantPredicate.trueInstance()); assertObjectsAreNotEqual(p,new UnaryFunctionUnaryPredicate(null)); assertObjectsAreNotEqual(p,new
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server RequestLine.java
oglueck 2003/11/24 12:39:26
Modified:httpclient/src/test/org/apache/commons/httpclient/server
Tag: HTTPCLIENT_2_0_BRANCH RequestLine.java
Log:
made immutable
Revision ChangesPath
No revision
No revision
1.1.2.2 +4 -15
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/RequestLine.java
Index: RequestLine.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/RequestLine.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- RequestLine.java 18 Nov 2003 12:26:38 - 1.1.2.1
+++ RequestLine.java 24 Nov 2003 20:39:26 - 1.1.2.2
@@ -68,6 +68,7 @@
/**
* Defines a HTTP request-line, consisting of method name, URI and protocol.
+ * Instances of this class are immutable.
*
* @author Christian Kohlschuetter
*/
@@ -107,18 +108,6 @@
return uri;
}
-public void setMethod(String string) {
-method = string;
-}
-
-public void setProtocol(String string) {
-protocol = string;
-}
-
-public void setUri(String string) {
-uri = string;
-}
-
public String toString() {
StringBuffer sb = new StringBuffer();
if(method != null) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: TimerMap
Hey there,
Thanks for all the feedback! Ideally, I think this makes the most sense
as a Map --since it's most common use cases are as a Map-- and the
javadoc would spell out usage scenarios and challenges (something I
will work on).
I've changed two points: TimedMapKey is now private and the backing
store is no longer synchronized (as per Arun's suggestions).
Synchronization can be left to the client developer.
Even though I wouldn't want to have client code accessing entries via
iterator in normal usage, I don't think calling keySet() should throw
an UnsupportedOperationException since examining the keySet of such a
map could be very useful in debugging caching issues.
Thanks,
-Joe
Joseph Rosenblum | 25th Street Networks
Easy, Reliable Web Hosting @ http://www.25thstreet.net/
package net.twentyfifth.util;
import java.util.*;
/**
* This class will expire the keys in a given map after the interval
* specified in the constructor. Note: the behavior of this class is such
* that if you configure a TimerMap with a 5 minute timeout, and if 4:59
* after you add a certain key, you re-add a duplicate of that key, the
* original TimerTask to remove the key will run 1 second later (and then
* again 5 minutes later).
*
* @author Joseph Rosenblum [EMAIL PROTECTED]
*/
public class TimerMap implements Map {
protected final long delay;
private final Map timerMap = new HashMap();
private Timer timer;
public TimerMap(long delay) {
this.delay = delay;
timer = new Timer();
}
public void finalize() {
timer.cancel();
}
public long getDelay(Object key) {
return delay;
}
public int size() {
return this.timerMap.size();
}
public boolean isEmpty() {
return this.timerMap.isEmpty();
}
public boolean containsKey(Object key) {
return this.timerMap.containsKey(key);
}
public boolean containsValue(Object value) {
return this.timerMap.containsValue(value);
}
public Object get(Object key) {
return this.timerMap.get(key);
}
public Object put(Object key, Object value) {
Object prevKey = this.timerMap.put(key, value);
timer.schedule(new TimedMapKey(key), delay);
return prevKey;
}
public Object remove(Object key) {
return this.timerMap.remove(key);
}
public void putAll(Map t) {
Iterator i = t.keySet().iterator();
while (i.hasNext()) {
Object key = i.next();
Object val = t.get(key);
this.put(key, val);
}
}
public void clear() {
}
public Set keySet() {
return this.timerMap.keySet();
}
public Collection values() {
return this.timerMap.values();
}
public Set entrySet() {
return this.timerMap.entrySet();
}
/**
* Basically wraps map keys in a TimerTask that
* will remove them from the timerMap after the delay
* interval has expired.
*/
private final class TimedMapKey extends TimerTask {
private final Object key;
TimedMapKey(Object key) {
this.key = key;
}
public void run() {
timerMap.remove(key);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server ResponseWriter.java SimpleHttpServerConnection.java GenericResponse.java HttpRequestHandler.java SimpleHttpServer.java HttpRequestHandlerChain.java
oglueck 2003/11/24 12:41:11
Modified:httpclient/src/test/org/apache/commons/httpclient/server
Tag: HTTPCLIENT_2_0_BRANCH ResponseWriter.java
SimpleHttpServerConnection.java
GenericResponse.java HttpRequestHandler.java
SimpleHttpServer.java HttpRequestHandlerChain.java
Log:
refactored code to be more OO and flexible enough for our needs
Revision ChangesPath
No revision
No revision
1.1.2.2 +3 -57
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/ResponseWriter.java
Index: ResponseWriter.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/ResponseWriter.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- ResponseWriter.java 18 Nov 2003 12:26:39 - 1.1.2.1
+++ ResponseWriter.java 24 Nov 2003 20:41:11 - 1.1.2.2
@@ -78,7 +78,6 @@
public class ResponseWriter extends FilterWriter {
public static final String CRLF = \r\n;
public static final String ISO_8859_1 = ISO-8859-1;
-private boolean modified = false;
private OutputStream outStream;
private String encoding;
@@ -100,7 +99,6 @@
public void close() throws IOException {
if(out != null) {
-modified = true;
super.close();
out = null;
}
@@ -118,69 +116,17 @@
public void write(byte b) throws IOException {
super.flush();
-modified = true;
outStream.write((int)b);
}
public void write(byte[] b) throws IOException {
super.flush();
-modified = true;
outStream.write(b);
}
public void write(byte[] b, int off, int len) throws IOException {
super.flush();
-modified = true;
outStream.write(b,off,len);
}
-/* (non-Javadoc)
- * @see java.io.Writer#write(char[], int, int)
- */
-public void write(char[] cbuf, int off, int len) throws IOException {
-modified = true;
-super.write(cbuf, off, len);
-}
-
-/* (non-Javadoc)
- * @see java.io.Writer#write(int)
- */
-public void write(int c) throws IOException {
-modified = true;
-super.write(c);
-}
-
-/* (non-Javadoc)
- * @see java.io.Writer#write(java.lang.String, int, int)
- */
-public void write(String str, int off, int len) throws IOException {
-modified = true;
-super.write(str, off, len);
-}
-
-/* (non-Javadoc)
- * @see java.io.Writer#write(char[])
- */
-public void write(char[] cbuf) throws IOException {
-modified = true;
-super.write(cbuf);
-}
-
-/* (non-Javadoc)
- * @see java.io.Writer#write(java.lang.String)
- */
-public void write(String str) throws IOException {
-modified = true;
-super.write(str);
-}
-
-/**
- * Checks if this PrintWriter has been called
- *
- * @return true/false
- */
-public boolean isModified() {
-return modified;
-}
-
public void print(String s) throws IOException {
if (s == null) {
s = null;
1.1.2.3 +34 -18
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/SimpleHttpServerConnection.java
Index: SimpleHttpServerConnection.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/SimpleHttpServerConnection.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- SimpleHttpServerConnection.java 19 Nov 2003 00:23:30 - 1.1.2.2
+++ SimpleHttpServerConnection.java 24 Nov 2003 20:41:11 - 1.1.2.3
@@ -65,6 +65,8 @@
import java.io.IOException;
import java.io.InputStream;
+import java.io.OutputStream;
+import java.io.UnsupportedEncodingException;
import java.net.Socket;
import java.net.SocketException;
@@ -86,18 +88,21 @@
private SimpleHttpServer server;
private Socket socket;
private InputStream in;
-private ResponseWriter out;
+private OutputStream out;
private int requestNo = 0;
private boolean keepAlive = false;
+ private RequestLine requestLine;
+
+ private Header[] headers;
+
public SimpleHttpServerConnection(SimpleHttpServer server, Socket socket)
throws IOException {
this.server = server;
this.socket = socket;
RE: TimerMap
Maybe you could just go ahead and throw UnsupportedOperationException on keySet(), but implement a generic debugCachingIssues() method! ;-) -Original Message- From: Joseph Rosenblum [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 3:40 PM To: Jakarta Commons Developers List Subject: Re: TimerMap Hey there, Thanks for all the feedback! Ideally, I think this makes the most sense as a Map --since it's most common use cases are as a Map-- and the javadoc would spell out usage scenarios and challenges (something I will work on). I've changed two points: TimedMapKey is now private and the backing store is no longer synchronized (as per Arun's suggestions). Synchronization can be left to the client developer. Even though I wouldn't want to have client code accessing entries via iterator in normal usage, I don't think calling keySet() should throw an UnsupportedOperationException since examining the keySet of such a map could be very useful in debugging caching issues. Thanks, -Joe Joseph Rosenblum | 25th Street Networks Easy, Reliable Web Hosting @ http://www.25thstreet.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TimerMap
Oh, what about making it extend AbstractMapDecorator? -Original Message- From: Joseph Rosenblum [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 3:40 PM To: Jakarta Commons Developers List Subject: Re: TimerMap Hey there, Thanks for all the feedback! Ideally, I think this makes the most sense as a Map --since it's most common use cases are as a Map-- and the javadoc would spell out usage scenarios and challenges (something I will work on). I've changed two points: TimedMapKey is now private and the backing store is no longer synchronized (as per Arun's suggestions). Synchronization can be left to the client developer. Even though I wouldn't want to have client code accessing entries via iterator in normal usage, I don't think calling keySet() should throw an UnsupportedOperationException since examining the keySet of such a map could be very useful in debugging caching issues. Thanks, -Joe Joseph Rosenblum | 25th Street Networks Easy, Reliable Web Hosting @ http://www.25thstreet.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TimerMap
Actually, I'm only concerned about keySet().iterator() and values().iterator(). Not about keySet() and values() :) Perhaps something that can be worked in as we move forward? I think this (the ill-formedness of the iterators) could be something captured in docs today and implemented explicitly moving forward. Perhaps I'll take a shot once we've got it checked in Now if only I can find my password for CVS :) I should be able to check it in -AMT -Original Message- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 12:42 PM To: 'Jakarta Commons Developers List' Subject: RE: TimerMap Maybe you could just go ahead and throw UnsupportedOperationException on keySet(), but implement a generic debugCachingIssues() method! ;-) -Original Message- From: Joseph Rosenblum [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 3:40 PM To: Jakarta Commons Developers List Subject: Re: TimerMap Hey there, Thanks for all the feedback! Ideally, I think this makes the most sense as a Map --since it's most common use cases are as a Map-- and the javadoc would spell out usage scenarios and challenges (something I will work on). I've changed two points: TimedMapKey is now private and the backing store is no longer synchronized (as per Arun's suggestions). Synchronization can be left to the client developer. Even though I wouldn't want to have client code accessing entries via iterator in normal usage, I don't think calling keySet() should throw an UnsupportedOperationException since examining the keySet of such a map could be very useful in debugging caching issues. Thanks, -Joe Joseph Rosenblum | 25th Street Networks Easy, Reliable Web Hosting @ http://www.25thstreet.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Contribution to o.a.c.math.distribution - NormalDistribution
Piotr, I will add these in, I'd like to work to see us move to have a separate package for CDF's (I expect to place the Gamma and Beta functions there as well and to unify all these CDF style functions under one interface. Basically we would have: o.a.c.math.function Beta Gamma Normal FastNormal PreciseNormal ... o.a.c.math.distribution Normal Gamma Binomial Piotr Kochaski wrote: Hello! I would like to contribute to the o.a.c.math.distribution package the implementation of Normal distribution. I've implemented two algorithms for calculation of a cummulative distribution function - one of them (NormalCDFFastAlgorithm.java) is fast but less precise then the other one (NormalCDFPreciseAlgorithm.java). I think that having alternative in this case is useful since we have the standard (precise) algorithm available but when we need speed, we can use the other one - so the java is slow people would not have an occasion to mess around. I think we want to provide alternate implementations so people have multiple options available. In fact the fast algorithm is precise enough to be used in a majority of real-life applications (especially in social sciences). Code which calculates CDF is in the mentioned files, the code for the inverse CDF is in the NormalDistributionImpl.java. This is what really matters. Is it logical to consider having the inverse available in the Function interface and not the Distribution? I've organized the classes so that the precise algorithm is used as a default, but it is easy to switch to the other one: z = DistributionFactory.newInstance().createNormalDistribution(mean, standardDev); z.setCdfAlgorithm(new NormalCDFFastAlgorithm()); You might not like the way I've implemented the alternative algorithms - this is just the Strategy Pattern, but one can achieve the same aim differently, maybe in a better way - I wanted to stick as close as possible to the current implementation of ContinousDistribution and be user friendly at the same time. I think is acceptable, my interest is in seeing consistent interfaces for the functions and distributions, thats my only criticism I am not sure if the file names are the best one can think of too. I have adopted the convention that for standard deviation equal to zero cumulative distribution is always 0 and inverse CDF equals to the mean value. I am not quite convinced that for probability p=0 and p=1 inverse CDF should return NaN, maybe a better solution would be to return Double.NEGATIVE_INFINITY for p=0 and Double.POSITIVE_INFINITY for p=1. Any suggestions? Well in the mathematical solution they would be infinite, wouldn't they? In such case this may be logical. I suspect if p0 or p1 they should be NaN. Looking good Piotr, Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/generator Generator.java
rwaldhoff2003/11/24 13:13:15
Modified:functor/src/java/org/apache/commons/functor/generator
Generator.java
Log:
remove extra space
Revision ChangesPath
1.5 +3 -3
jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/generator/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/generator/Generator.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Generator.java12 Nov 2003 00:50:44 - 1.4
+++ Generator.java24 Nov 2003 21:13:15 - 1.5
@@ -65,7 +65,7 @@
/**
* @version $Revision$ $Date$
- * @author Jason Horman ([EMAIL PROTECTED])
+ * @author Jason Horman ([EMAIL PROTECTED])
* @author Rodney Waldhoff
*/
public interface Generator {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/collection TestSize.java
rwaldhoff2003/11/24 13:29:28
Modified:functor/src/java/org/apache/commons/functor/core/collection
Size.java
functor/src/test/org/apache/commons/functor/core/collection
TestSize.java
Log:
support Strings and arrays in Size function, add tests
Revision ChangesPath
1.3 +29 -4
jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/collection/Size.java
Index: Size.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/collection/Size.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Size.java 24 Nov 2003 20:12:17 - 1.2
+++ Size.java 24 Nov 2003 21:29:28 - 1.3
@@ -57,11 +57,14 @@
package org.apache.commons.functor.core.collection;
import java.io.Serializable;
+import java.lang.reflect.Array;
import java.util.Collection;
import org.apache.commons.functor.UnaryFunction;
/**
+ * Returns the size of the specified Collection, or the length
+ * of the specified array or String.
* @version $Revision$ $Date$
* @author Rodney Waldhoff
*/
@@ -73,7 +76,17 @@
public Size() { }
public Object evaluate(Object obj) {
-return new Integer(((Collection)obj).size());
+if(obj instanceof Collection) {
+return evaluate((Collection)obj);
+} else if(obj instanceof String) {
+return evaluate((String)obj);
+} else if(null != obj obj.getClass().isArray()) {
+return evaluateArray(obj);
+} else if(null == obj){
+throw new NullPointerException(Argument must not be null);
+} else {
+throw new ClassCastException(Expected Collection, String or Array,
found + obj);
+}
}
/**
@@ -100,7 +113,19 @@
public static final Size instance() {
return INSTANCE;
}
+
+private Object evaluate(Collection col) {
+return new Integer(col.size());
+}
+
+private Object evaluate(String str) {
+return new Integer(str.length());
+}
+
+private Object evaluateArray(Object array) {
+return new Integer(Array.getLength(array));
+}
private static final Size INSTANCE = new Size();
-
+
}
1.3 +9 -3
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/collection/TestSize.java
Index: TestSize.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/collection/TestSize.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TestSize.java 24 Nov 2003 20:12:17 - 1.2
+++ TestSize.java 24 Nov 2003 21:29:28 - 1.3
@@ -139,7 +139,7 @@
}
}
-public void testTestNonCollection() throws Exception {
+public void testEvaluateNonCollection() throws Exception {
try {
Size.instance().evaluate(new Integer(3));
fail(Expected ClassCastException);
@@ -148,6 +148,12 @@
}
}
+public void testEvaluateArray() throws Exception {
+assertEquals(new Integer(10),Size.instance().evaluate(new int[10]));
+assertEquals(new Integer(7),Size.instance().evaluate(new String[7]));
+assertEquals(new
Integer(xyzzy.length()),Size.instance().evaluate(xyzzy));
+}
+
public void testEquals() throws Exception {
UnaryFunction f = new Size();
assertEquals(f,f);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/collection TestSize.java
rwaldhoff2003/11/24 13:31:30
Modified:functor/src/test/org/apache/commons/functor/core/collection
TestSize.java
Log:
split test
Revision ChangesPath
1.4 +5 -2
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/collection/TestSize.java
Index: TestSize.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/collection/TestSize.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- TestSize.java 24 Nov 2003 21:29:28 - 1.3
+++ TestSize.java 24 Nov 2003 21:31:30 - 1.4
@@ -151,6 +151,9 @@
public void testEvaluateArray() throws Exception {
assertEquals(new Integer(10),Size.instance().evaluate(new int[10]));
assertEquals(new Integer(7),Size.instance().evaluate(new String[7]));
+}
+
+public void testEvaluateString() throws Exception {
assertEquals(new
Integer(xyzzy.length()),Size.instance().evaluate(xyzzy));
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/collection IsEmpty.java
rwaldhoff2003/11/24 13:38:39
Modified:functor/src/test/org/apache/commons/functor/core/collection
TestIsEmpty.java
functor/src/java/org/apache/commons/functor/core/collection
IsEmpty.java
Log:
support Strings and arrays in IsEmpty predicate, add tests
Revision ChangesPath
1.4 +14 -2
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/collection/TestIsEmpty.java
Index: TestIsEmpty.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/collection/TestIsEmpty.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- TestIsEmpty.java 24 Nov 2003 20:12:17 - 1.3
+++ TestIsEmpty.java 24 Nov 2003 21:38:39 - 1.4
@@ -143,6 +143,18 @@
}
}
+public void testTestArray() throws Exception {
+assertTrue(! IsEmpty.instance().test(new int[10]));
+assertTrue(! IsEmpty.instance().test(new Object[10]));
+assertTrue(IsEmpty.instance().test(new int[0]));
+assertTrue(IsEmpty.instance().test(new Object[0]));
+}
+
+public void testTestString() throws Exception {
+assertTrue(! IsEmpty.instance().test(xyzzy));
+assertTrue(IsEmpty.instance().test());
+}
+
public void testEquals() throws Exception {
UnaryPredicate p = new IsEmpty();
assertEquals(p,p);
1.3 +35 -3
jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/collection/IsEmpty.java
Index: IsEmpty.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/collection/IsEmpty.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- IsEmpty.java 24 Nov 2003 20:12:17 - 1.2
+++ IsEmpty.java 24 Nov 2003 21:38:39 - 1.3
@@ -57,6 +57,7 @@
package org.apache.commons.functor.core.collection;
import java.io.Serializable;
+import java.lang.reflect.Array;
import java.util.Collection;
import org.apache.commons.functor.UnaryPredicate;
@@ -71,9 +72,22 @@
//
public IsEmpty() { }
+
+// instance methods
+//
public boolean test(Object obj) {
-return ((Collection)obj).isEmpty();
+if(obj instanceof Collection) {
+return test((Collection)obj);
+} else if(obj instanceof String) {
+return test((String)obj);
+} else if(null != obj obj.getClass().isArray()) {
+return testArray(obj);
+} else if(null == obj){
+throw new NullPointerException(Argument must not be null);
+} else {
+throw new ClassCastException(Expected Collection, String or Array,
found + obj);
+}
}
/**
@@ -97,9 +111,27 @@
return IsEmpty();
}
+private boolean test(Collection col) {
+return col.isEmpty();
+}
+
+private boolean test(String str) {
+return 0 == str.length();
+}
+
+private boolean testArray(Object array) {
+return 0 == Array.getLength(array);
+}
+
+// class methods
+//
+
public static final IsEmpty instance() {
return INSTANCE;
}
+
+// class variables
+//
private static final IsEmpty INSTANCE = new IsEmpty();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/collection IsElementOf.java
rwaldhoff2003/11/24 13:56:43
Modified:functor/src/test/org/apache/commons/functor/core/collection
TestIsElementOf.java
functor/src/java/org/apache/commons/functor/core/collection
IsElementOf.java
Log:
support Arrays in isElementOf, add tests
Revision ChangesPath
1.6 +50 -5
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/collection/TestIsElementOf.java
Index: TestIsElementOf.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/collection/TestIsElementOf.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- TestIsElementOf.java 24 Nov 2003 20:31:20 - 1.5
+++ TestIsElementOf.java 24 Nov 2003 21:56:43 - 1.6
@@ -96,7 +96,7 @@
// Tests
//
-public void testTest() throws Exception {
+public void testTestCollection() throws Exception {
ArrayList list = new ArrayList();
list.add(new Integer(5));
list.add(new Integer(10));
@@ -112,12 +112,57 @@
}
-public void testNullWrapper() {
+public void testTestArray() throws Exception {
+int[] list = new int[] { 5, 10, 15 };
+
+UnaryPredicate p = IsElementOf.instance(list);
+assertTrue(p.test(new Integer(5)));
+assertTrue(p.test(new Integer(10)));
+assertTrue(p.test(new Integer(15)));
+
+assertTrue(!p.test(new Integer(4)));
+assertTrue(!p.test(new Integer(11)));
+}
+
+public void testTestArrayWithNull() throws Exception {
+assertTrue(! IsElementOf.instance().test(null,new int[] { 5, 10, 15 }));
+assertTrue(IsElementOf.instance().test(null,new Integer[] { new Integer(5),
null, new Integer(15) }));
+assertTrue(IsElementOf.instance().test(new Integer(15),new Integer[] { new
Integer(5), null, new Integer(15) }));
+}
+
+public void testWrapNull() {
try {
IsElementOf.instance(null);
+fail(expected NullPointerException);
+} catch (NullPointerException e) {
+// expected
+}
+}
+
+public void testWrapNonCollection() {
+try {
+IsElementOf.instance(new Integer(3));
+fail(expected IllegalArgumentException);
+} catch (IllegalArgumentException e) {
+// expected
+}
+}
+
+public void testTestNull() {
+try {
+IsElementOf.instance().test(new Integer(5),null);
+fail(expected NullPointerException);
+} catch (NullPointerException e) {
+// expected
+}
+}
+
+public void testTestNonCollection() {
+try {
+IsElementOf.instance().test(new Integer(5),new Long(5));
fail(expected IllegalArgumentException);
} catch (IllegalArgumentException e) {
-// good
+// expected
}
}
1.4 +40 -11
jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/collection/IsElementOf.java
Index: IsElementOf.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/collection/IsElementOf.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- IsElementOf.java 24 Nov 2003 20:29:23 - 1.3
+++ IsElementOf.java 24 Nov 2003 21:56:43 - 1.4
@@ -58,6 +58,7 @@
package org.apache.commons.functor.core.collection;
import java.io.Serializable;
+import java.lang.reflect.Array;
import java.util.Collection;
import org.apache.commons.functor.BinaryPredicate;
@@ -85,13 +86,17 @@
//---
public boolean test(Object obj, Object col) {
-return test(obj,(Collection)col);
+if(col instanceof Collection) {
+return testCollection(obj,(Collection)col);
+} else if(null != col col.getClass().isArray()) {
+return testArray(obj,col);
+} else if(null == col) {
+throw new NullPointerException(Right side argument must not be null.);
+} else {
+throw new IllegalArgumentException(Expected Collection or Array, found
+ col.getClass());
+}
}
-public boolean test(Object obj, Collection col) {
-return col.contains(obj);
-}
-
public boolean equals(Object obj) {
return (obj instanceof IsElementOf);
}
@@ -104,6 +109,25 @@
cvs commit: jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/collection CollectionAlgorithms.java
rwaldhoff2003/11/24 13:59:30
Modified:functor/src/test/org/apache/commons/functor/core/collection
TestCollectionAlgorithms.java
functor/src/test/org/apache/commons/functor/example
QuicksortExample.java
functor/src/java/org/apache/commons/functor/core/collection
CollectionAlgorithms.java
Log:
deprecate CollectionAlgorithms, replaced by Algorithms
Revision ChangesPath
1.7 +3 -2
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/collection/TestCollectionAlgorithms.java
Index: TestCollectionAlgorithms.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/collection/TestCollectionAlgorithms.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- TestCollectionAlgorithms.java 24 Nov 2003 20:12:17 - 1.6
+++ TestCollectionAlgorithms.java 24 Nov 2003 21:59:30 - 1.7
@@ -78,6 +78,7 @@
/**
* @version $Revision$ $Date$
+ * @deprecated The CollectionAlgorithms class has been deprecated
* @author Rodney Waldhoff
*/
public class TestCollectionAlgorithms extends TestCase {
1.5 +5 -5
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/example/QuicksortExample.java
Index: QuicksortExample.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/example/QuicksortExample.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- QuicksortExample.java 24 Nov 2003 20:12:16 - 1.4
+++ QuicksortExample.java 24 Nov 2003 21:59:30 - 1.5
@@ -69,7 +69,7 @@
import org.apache.commons.functor.UnaryFunction;
import org.apache.commons.functor.adapter.RightBoundPredicate;
import org.apache.commons.functor.core.ConstantFunction;
-import org.apache.commons.functor.core.collection.CollectionAlgorithms;
+import org.apache.commons.functor.Algorithms;
import org.apache.commons.functor.core.collection.IsEmpty;
import org.apache.commons.functor.core.comparator.IsGreaterThanOrEqual;
import org.apache.commons.functor.core.comparator.IsLessThan;
@@ -501,7 +501,7 @@
*/
private BinaryFunction lesserTail = new ObjectListFunction() {
public Object evaluate(Object head, List tail) {
-return CollectionAlgorithms.select(
+return Algorithms.select(
tail.iterator(),
RightBoundPredicate.bind(
IsLessThan.getIsLessThan(),
@@ -516,7 +516,7 @@
*/
private BinaryFunction greaterTail = new BinaryFunction() {
public Object evaluate(Object head, Object tail) {
-return CollectionAlgorithms.select(
+return Algorithms.select(
((List)tail).iterator(),
RightBoundPredicate.bind(
IsGreaterThanOrEqual.instance(),
1.4 +3 -2
jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/collection/CollectionAlgorithms.java
Index: CollectionAlgorithms.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/collection/CollectionAlgorithms.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- CollectionAlgorithms.java 19 Feb 2003 12:34:20 - 1.3
+++ CollectionAlgorithms.java 24 Nov 2003 21:59:30 - 1.4
@@ -71,6 +71,7 @@
* Utility methods and algorithms for applying functors
* to [EMAIL PROTECTED] Collection Collections}.
*
+ * @deprecated Replaced by, or to be replaced by
org.apache.commons.functor.Algorithms
* @version $Revision$ $Date$
* @author Rodney Waldhoff
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] remove old ant build system
Quoting Jeremias Maerki [EMAIL PROTECTED]: Nope, I guess not. On 23.11.2003 10:34:38 Henri Yandell wrote: As the site is using maven, is there any need to keep the old build system? [build.properties, build.properties.sample, build.xml] It'll only get out of date if maven is the main build system [and vice versa]. Jeremias Maerki If you want your jakarta-commons nightly builds to continue to work, you'll need to keep the old build mechanism -- updating my scripts to work with the packages that are Maven-built versus not is on my TODO list, but nowhere near the top of the priorities. Keeping build.xml in sync is straightforward (since Maven will generate one for you), but is still a necessary step for this purpose. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] RE: DBCP - ReapingObjectPool
Just out of curiosity, What sort of situation do you have that objects get borrowed, but then forgotten? This is an interesting side-effect of pooling. worse is better -Original Message- From: Dirk Verbeeck [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 5:20 PM To: Jakarta Commons Developers List Subject: Re: DBCP - ReapingObjectPool Actually we already have something similar: AbandonedObjectPool. http://jakarta.apache.org/commons/dbcp/xref/org/apache/commons/dbcp/Abandone dObjectPool.html Many enhancements are possible, I have been playing around the java.lang.ref package to see if it can provide a safe way to recover abandoned objects. Contributing is as simple as posting your improvements to the list. A whole new file or a patch for existing files. If there isn't a committer around then you can also make a bugzilla item for it. Writing comments to make the review easier helps and if you have junit tests then you can be sure your contribution won't go unnoticed. If you're thinking about doing a lot of work then first discuss it on the list just to make sure we are on the same line. Contributions are always welcome, bugfixes, enhancements, website updates, documentation, you name it... Cheers Dirk Juan Ignacio Cidre wrote: I was needing an ObjectPool that 'remembers' the borrowed objects so it can recollect them if not returned after a while. Is there something like that arround? I've extended GenericObjectPool to have that functionallity. I can give it to the project if there is not a better option than mine. Since this would be my first contribution to the project, and I don't know the customs, I would need some help (I've read all the on-line guides, already, ) N. - 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: [digester] [PATCH] Adding Ant-like properties support
i've finally found time to consider both proposals (apologies for the
delay).
1. i think that i like some parts of remy's solution but would prefer
the actual implementation to be pluggable through a strategy interface
(probably implemented as an abstract class). i know that this is a
little slower but i think that in the long term, it's better for
digester not to be tied to a particular implementation (no matter how
good ;)
2. i think that simon's correct that the right place to do this is in
digester rather than in particular rules. coding this into rules is
just going to cause confusion for users and difficulties when some
rules support it and some don't.
3. i'd prefer not to subclass and instead use a seamless substitution.
i'd probably start with just the attribute values and provide just the
behaviour in remy's post.
4. for the stock implementation of the strategy, i'd like to use remy's
algorithm.
5. extra features (and more flexible behaviour) can be added later as
necessary.
remy - is there any chance of a unit test (or two) so that i can ensure
that implementation hasn't missed anything?
i'll hold off starting this till tommorrow so other people have a
chance to comment (and find any holes in my logic ;) before i start
work.
- robert
On 11 Nov 2003, at 18:40, Remy Maucherat wrote:
Hi,
I described the feature a couple weeks ago, and here's my patch.
It currently only replaces attributes processed by the setProperties
rule. This did sound good enough to me. I read about processing text
nodes too (does Ant do this also ?), so maybe we can improve this
patch/feature more.
Remy
/*
* $Header:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/
digester/SetPropertyRule.java,v 1.14 2003/10/09 21:09:46 rdonkin Exp $
* $Revision: 1.14 $
* $Date: 2003/10/09 21:09:46 $
*
*
*
* 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;
/**
* This maps provides properties mapping to system classes. This base
* implementation lookups properties in the system properties.
*
* @author Remy Maucherat
* @version $Revision: 1.14 $ $Date: 2003/10/09 21:09:46 $
*/
public class PropertySource {
public String getProperty(String key) {
return System.getProperty(key);
}
}
Index:
RE: [dbcp] PoolableConnectionFactory validation and synchronized methods
Hello Dirk, We have build dbcp with the synchronization removed and it removed the bottleneck from dbcp. We've only used our modified dbcp in our testing environment. I wanted to check with the list to see if we were overlooking something when modifying the synchronization. I'll probably post our patch to the list tomorrow. It is a really small change. Thanks, Brad Johnson -Original Message- From: Dirk Verbeeck dirk.verbeeck-at-pandora.be |jakarta-commons| [mailto:[EMAIL PROTECTED] Sent: Saturday, November 22, 2003 7:35 AM To: Johnson, Brad Subject: Re: [dbcp] PoolableConnectionFactory validation and synchronized methods Hello Brad, There is indeed no technical reason why PoolableConnectionFactory should be synchronized but I didn't want to include this change in 1.1. First it should be tested by multiple people / multiple database systems to see how the system reacts in the real world. There is indeed a good chance that the change boosts performance without any negative effects. If you are able and have the time to do some performance tests then please do so, I can assist if needed (make test build,...). Regards Dirk Brad Johnson wrote: Hello Dirk, Well, we are trying to get as much concurrency out of our application as we can (uPortal running on Tomcat). Seems that allowing concurrent connections to the database should help performance, and might allow your code to perform well enough that it exposes a bottleneck in the database. Then the problem is really with the database. So, I really don't see any drawback of removing synchronized from the code on these methods. Am I missing something here? thanks, Brad Johnson Texas Tech University - From: Dirk Verbeeck Subject: Re: JDBC AbandonedObjectPool and PoolableConnectionFactory Date: Sun, 28 Sep 2003 11:24:40 -0700 You can remove the synchronization of the validateObject method in PoolableConnectionFactory but be carefull. If the query is slow because the database is overloaded then allowing more validationQueries will increase the problem. For the next release I'm thinking about monitoring SQLExceptions thrown by the connection and invalidating the connection before it is returned to the pool. This will cover broken connections. Combined with a testOnBorrowOldConnection it can replace the current testOnBorrow. Dirk --- http://www.mail-archive.com/[EMAIL PROTECTED]/msg27029.html - 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: [collections] Re: /PROPOSAL 1/ Additions to IteratorUtils
It seems like an odd thing to want to do. If you need to know the size, hold
the data in a collection.
Stephen
- Original Message -
In the current CVS HEAD, you can do
IteratorUtils.toArray(Iterator).length
or
IteratorUtils.toList(Iterator).size()
But, your suggestion may be a good addition also.
Also, I think that the method definitions you've provided will all cause
infinite loops -- hasNext() will always return true if you don't call
next(). We'd need to find a way to copy the iterator so we don't modify
it's state when we count the elements.
Anyone else have an opinion?
Lee Crawford wrote:
I'd like to propose the following simple additions to the
o.a.c.c.IteratorUtils
class.
The following is a simple convenience method for counting the number of
elements
in an iteration, something that I find myself recreating somewhat
frequently:
public static
int countElements (final Iterator iter) {
int cnt = 0;
while (iter.hasNext ()) {
cnt ++;
}
return cnt;
}
There isn't an EnumeratorUtils present that might contain an equivalent:
public static
int countElements (final Enumerator enum) {
int cnt = 0;
while (enum.hasNext ()) {
cnt ++;
}
return cnt;
}
Or the slightly less performant:
public static
int countElements (final Enumerator enum) {
return IteratorUtils.countElements (asIterator (enum));
}
Thoughts?
--lee
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/scaffold/xdocs - New directory
dirkv 2003/11/24 14:51:34 jakarta-commons-sandbox/scaffold/xdocs - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] [PATCH] Adding Ant-like properties support
On Tue, 2003-11-25 at 11:32, robert burrell donkin wrote:
i've finally found time to consider both proposals (apologies for the
delay).
1. i think that i like some parts of remy's solution but would prefer
the actual implementation to be pluggable through a strategy interface
(probably implemented as an abstract class). i know that this is a
little slower but i think that in the long term, it's better for
digester not to be tied to a particular implementation (no matter how
good ;)
Could you expand on this strategy interface a little, Robert? I'm not
quite sure what you mean here.
Are you suggesting something like this?
interface VarExpander {
/** expand any variable references in the string */
String expand(String raw);
}
and
Digester.setVarExpander(VarExpander varExpander)
so that the user can control exactly how variables are detected in
strings, and how the replacement data is located?
That sounds good to me. The default could be Remy's implementation which
requires the syntax ${xxx} and which always draws from one source. My
suggestion of an enhanced version that allows more flexible variable
detection and multiple sources could be provided as an alternative
[provided anyone thinks it is useful enough to add to the Digester
base]. This seems symmetrical with the BaseRules/ExtendedBaseRules
approach.
2. i think that simon's correct that the right place to do this is in
digester rather than in particular rules. coding this into rules is
just going to cause confusion for users and difficulties when some
rules support it and some don't.
I was actually working on this last night. I've come up with the idea of
a lazy evaluation wrapper for the org.xml.sax.Attributes class, which
only checks attribute values for variables when the attribute value is
asked for.
I hope to be able to post this to the list in about 24 hours time.
This hopefully solves Remy's (quite correct) objection about performance
with the code I originally posted.
3. i'd prefer not to subclass and instead use a seamless substitution.
i'd probably start with just the attribute values and provide just the
behaviour in remy's post.
Is this in reference to the implementation I posted which subclassed
Digester in order to provide this functionality? That was never intended
to be a final solution; it's just what I currently have in production.
For production code, I don't like modifying libraries :-). I agree that
var expansion should really be integrated into the existing digester
stuff without subclassing Digester.
The stuff I posted wasn't a prepared patch; I just grabbed some stuff I
already had floating around and sent it out as an alternative
suggestion. Sorry if that wasn't clear.
If you meant something else by prefer not to subclass please let me
know.
4. for the stock implementation of the strategy, i'd like to use remy's
algorithm.
5. extra features (and more flexible behaviour) can be added later as
necessary.
remy - is there any chance of a unit test (or two) so that i can ensure
that implementation hasn't missed anything?
i'll hold off starting this till tommorrow so other people have a
chance to comment (and find any holes in my logic ;) before i start
work.
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] TimerMap
This sounds good from the discssions. I would definitely want to to extend AbstractMapDecorator if it is a decorator. One solution to troublesome iteration issues can be to clone the data into an ArrayList in the constructor of the iterator. The iterator can then access the data safely. This solution has to be javadocced of course. Stephen - Original Message - From: Arun Thomas [EMAIL PROTECTED] Actually, I'm only concerned about keySet().iterator() and values().iterator(). Not about keySet() and values() :) Perhaps something that can be worked in as we move forward? I think this (the ill-formedness of the iterators) could be something captured in docs today and implemented explicitly moving forward. Perhaps I'll take a shot once we've got it checked in Now if only I can find my password for CVS :) I should be able to check it in -AMT -Original Message- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 12:42 PM To: 'Jakarta Commons Developers List' Subject: RE: TimerMap Maybe you could just go ahead and throw UnsupportedOperationException on keySet(), but implement a generic debugCachingIssues() method! ;-) -Original Message- From: Joseph Rosenblum [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 3:40 PM To: Jakarta Commons Developers List Subject: Re: TimerMap Hey there, Thanks for all the feedback! Ideally, I think this makes the most sense as a Map --since it's most common use cases are as a Map-- and the javadoc would spell out usage scenarios and challenges (something I will work on). I've changed two points: TimedMapKey is now private and the backing store is no longer synchronized (as per Arun's suggestions). Synchronization can be left to the client developer. Even though I wouldn't want to have client code accessing entries via iterator in normal usage, I don't think calling keySet() should throw an UnsupportedOperationException since examining the keySet of such a map could be very useful in debugging caching issues. Thanks, -Joe Joseph Rosenblum | 25th Street Networks Easy, Reliable Web Hosting @ http://www.25thstreet.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] CaseInsensitiveHashMap
I would like to propose an alternative solution to the problem that IMO fits well with current [collections] direction. Consider a new Map implementation that acts as a direct replacement for HashMap, call it HashMapA (A for apache ;-). This class contains basically the same code as HashMap, although it must be written without using cut and paste (ie from scratch - Sun licence issues). HashMapA differs from HashMap in that the hashing algorithm and equals comparison methods are dedicated protected methods. It then becomes easy for a subclass to be written that compares keys using case insensitivity (amongst other things). HashMapA would also have a mapIterator() method to access the new map iterator concept. Finally, there would probably need to be a MapA interface to allow access to the map iterator. Stephen - Original Message - Umm, I didn't notice #get did not apply the transformation. Perhaps not such a good idea to use TransformedMap after all. This behaviour is certainly different to my expectations (although the documentation is clear enough on this point). I wonder what the original use-case for TransformedMap was. If the database client code restricts itself to using lowercase names (an aspect you are in control of) TransformedMap could still be useful but hardly as convenient as the original case insensitive map. It's a requirement that DbUtils clients use whatever case they want to refer to column names in a Map so TransformedMap as it is now won't work. Regardless, DbUtils doesn't have a dependency on collections and shouldn't add one just for this feature. The implementation of CaseInsensitiveHashMap is trivial enough to maintain in DbUtils. I opened the enhancement against collections in case anyone else had a need for this kind of Map. If TransformedMap doesn't change then I think adding CaseInsensitiveMap is the best solution. -Janek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/scaffold/xdocs downloads.xml index.xml navigation.xml
dirkv 2003/11/24 14:59:43 Modified:scaffold .cvsignore Added: scaffold LICENSE.txt checkstyle.xml project.properties project.xml scaffold/xdocs downloads.xml index.xml navigation.xml Log: mavenize scaffold Revision ChangesPath 1.2 +7 -0 jakarta-commons-sandbox/scaffold/.cvsignore Index: .cvsignore === RCS file: /home/cvs/jakarta-commons-sandbox/scaffold/.cvsignore,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- .cvsignore23 Nov 2002 02:12:02 - 1.1 +++ .cvsignore24 Nov 2003 22:59:43 - 1.2 @@ -1,2 +1,9 @@ +build.properties dist +.classpath +.project +.checkstyle target +maven.log +velocity.log +eclipse_classes 1.1 jakarta-commons-sandbox/scaffold/LICENSE.txt Index: LICENSE.txt === /* * $Source: /home/cvs/jakarta-commons-sandbox/scaffold/LICENSE.txt,v $ * $Revision: 1.1 $ * $Date: 2003/11/24 22:59:43 $ * * * * 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/ * */ 1.1 jakarta-commons-sandbox/scaffold/checkstyle.xml Index: checkstyle.xml === ?xml version=1.0? !DOCTYPE module PUBLIC -//Puppy Crawl//DTD Check Configuration 1.1//EN http://www.puppycrawl.com/dtds/configuration_1_1.dtd; !-- Checkstyle checks configured for Maven. -- module name=Checker !-- Checks that a package.html file exists for each package. -- !-- See http://checkstyle.sf.net/config_javadoc.html#PackageHtml -- module name=PackageHtml/ !-- Checks whether files end with a new line.-- !-- See http://checkstyle.sf.net/config_misc.html#NewlineAtEndOfFile -- module name=NewlineAtEndOfFile/ !-- Checks that property files contain the same keys. -- !-- See http://checkstyle.sf.net/config_misc.html#Translation -- module name=Translation/ module name=TreeWalker property name=cacheFile
RE: [collections] TimerMap
That would work! It's probably not a big issue if the iterator actually returns an object that has expired from the cache. Typical usages of these implementations aren't necessarily concerned with the EXACT timing of removal from the map. Even if they are, they're not GUARANTEED that the objects will be removed at EXACTLY the TTL value anyway. -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 5:59 PM To: Jakarta Commons Developers List Subject: Re: [collections] TimerMap This sounds good from the discssions. I would definitely want to to extend AbstractMapDecorator if it is a decorator. One solution to troublesome iteration issues can be to clone the data into an ArrayList in the constructor of the iterator. The iterator can then access the data safely. This solution has to be javadocced of course. Stephen - Original Message - From: Arun Thomas [EMAIL PROTECTED] Actually, I'm only concerned about keySet().iterator() and values().iterator(). Not about keySet() and values() :) Perhaps something that can be worked in as we move forward? I think this (the ill-formedness of the iterators) could be something captured in docs today and implemented explicitly moving forward. Perhaps I'll take a shot once we've got it checked in Now if only I can find my password for CVS :) I should be able to check it in -AMT -Original Message- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 12:42 PM To: 'Jakarta Commons Developers List' Subject: RE: TimerMap Maybe you could just go ahead and throw UnsupportedOperationException on keySet(), but implement a generic debugCachingIssues() method! ;-) -Original Message- From: Joseph Rosenblum [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 3:40 PM To: Jakarta Commons Developers List Subject: Re: TimerMap Hey there, Thanks for all the feedback! Ideally, I think this makes the most sense as a Map --since it's most common use cases are as a Map-- and the javadoc would spell out usage scenarios and challenges (something I will work on). I've changed two points: TimedMapKey is now private and the backing store is no longer synchronized (as per Arun's suggestions). Synchronization can be left to the client developer. Even though I wouldn't want to have client code accessing entries via iterator in normal usage, I don't think calling keySet() should throw an UnsupportedOperationException since examining the keySet of such a map could be very useful in debugging caching issues. Thanks, -Joe Joseph Rosenblum | 25th Street Networks Easy, Reliable Web Hosting @ http://www.25thstreet.net/ - 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]
[collections][PROPOSAL] Remove Observable subpackage
I would like to propose that the observable subpackage of [collections] be removed to another location. It remains a relatively self contained part of [collections] following the recent restructuring, and has the potential to grow with other event strategies and integration with GUIs such as Swing. This makes it a relatively poor fit with the rest of [collections]. Either the sandbox, or sourceforge seem appropriate for the code. I know there is demand for the code and a release, but I don't want to let it lie unreleased in [collections] as primitives did for far too long. So, whos in favour of removing it from [collections]? And where to, sandbox (observable), sourceforge (joda-observable), or elsewhere? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] possible DateUtils method
I think this would make a good addition to DateUtils. Would you like to
provide a patch and tests?
Stephen
- Original Message -
From: Inger, Matthew [EMAIL PROTECTED]
public static final long MILLIS_IN_DAY = 1000*60*60*24;
public long getDaysBetween(Calendar c1, Calendar c2)
{
long c1Normalized = c1.getTime().getTime() +
c1.get(Calendar.ZONE_OFFSET) +
c1.get(Calendar.DST_OFFSET);
long c2Normalized = c2.getTime().getTime() +
c2.get(Calendar.ZONE_OFFSET) +
c2.get(Calendar.DST_OFFSET);
long diff = c1Normalized - c2Normalized;
long numDays = diff / MILLIS_IN_DAY;
return numDays;
}
A common mistake most people make is to ignore daylight savings
time when trying to compute the number of days between two Calendar
dates. If you cross the DST boundary when the clock jumps forward,
just subtracting the date objects and dividing will end up giving you
an answer that is off by 1 day. This happens because the clock jumps
ahead, and 00:00 EDT is actually 11:00 EST on the previous day, so the
number of hours is off by 1, and thus the calculation doesn't end up
working
properly. The other thing i'm doing here is to convert to GMT time,
allowing
for the two Calendar objects to have different timezones.
We could have similar methods for getHoursBetween and so forth. Months
would be a bit more complicated of an algorithm.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/collection CollectionAlgorithms.java
rwaldhoff2003/11/24 15:09:13
Modified:functor/src/test/org/apache/commons/functor/core/collection
TestCollectionAlgorithms.java
functor/src/test/org/apache/commons/functor/example
QuicksortExample.java
functor/src/java/org/apache/commons/functor/core/collection
CollectionAlgorithms.java
Log:
undeprecate CollectionAlgorithms for now, Algorithms and CollectionAlgorithms are
less compatiable than I thought
Revision ChangesPath
1.8 +2 -3
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/collection/TestCollectionAlgorithms.java
Index: TestCollectionAlgorithms.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/collection/TestCollectionAlgorithms.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- TestCollectionAlgorithms.java 24 Nov 2003 21:59:30 - 1.7
+++ TestCollectionAlgorithms.java 24 Nov 2003 23:09:13 - 1.8
@@ -78,7 +78,6 @@
/**
* @version $Revision$ $Date$
- * @deprecated The CollectionAlgorithms class has been deprecated
* @author Rodney Waldhoff
*/
public class TestCollectionAlgorithms extends TestCase {
1.6 +5 -5
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/example/QuicksortExample.java
Index: QuicksortExample.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/example/QuicksortExample.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- QuicksortExample.java 24 Nov 2003 21:59:30 - 1.5
+++ QuicksortExample.java 24 Nov 2003 23:09:13 - 1.6
@@ -69,7 +69,7 @@
import org.apache.commons.functor.UnaryFunction;
import org.apache.commons.functor.adapter.RightBoundPredicate;
import org.apache.commons.functor.core.ConstantFunction;
-import org.apache.commons.functor.Algorithms;
+import org.apache.commons.functor.core.collection.CollectionAlgorithms;
import org.apache.commons.functor.core.collection.IsEmpty;
import org.apache.commons.functor.core.comparator.IsGreaterThanOrEqual;
import org.apache.commons.functor.core.comparator.IsLessThan;
@@ -501,7 +501,7 @@
*/
private BinaryFunction lesserTail = new ObjectListFunction() {
public Object evaluate(Object head, List tail) {
-return Algorithms.select(
+return CollectionAlgorithms.select(
tail.iterator(),
RightBoundPredicate.bind(
IsLessThan.getIsLessThan(),
@@ -516,7 +516,7 @@
*/
private BinaryFunction greaterTail = new BinaryFunction() {
public Object evaluate(Object head, Object tail) {
-return Algorithms.select(
+return CollectionAlgorithms.select(
((List)tail).iterator(),
RightBoundPredicate.bind(
IsGreaterThanOrEqual.instance(),
1.5 +2 -3
jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/collection/CollectionAlgorithms.java
Index: CollectionAlgorithms.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/collection/CollectionAlgorithms.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- CollectionAlgorithms.java 24 Nov 2003 21:59:30 - 1.4
+++ CollectionAlgorithms.java 24 Nov 2003 23:09:13 - 1.5
@@ -71,7 +71,6 @@
* Utility methods and algorithms for applying functors
* to [EMAIL PROTECTED] Collection Collections}.
*
- * @deprecated Replaced by, or to be replaced by
org.apache.commons.functor.Algorithms
* @version $Revision$ $Date$
* @author Rodney Waldhoff
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/collection IsEmpty.java
rwaldhoff2003/11/24 15:11:48
Modified:functor/src/test/org/apache/commons/functor/core/collection
TestIsEmpty.java
functor/src/java/org/apache/commons/functor/core/collection
IsEmpty.java
Log:
support Maps in IsEmpty, add tests
Revision ChangesPath
1.5 +13 -4
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/collection/TestIsEmpty.java
Index: TestIsEmpty.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core/collection/TestIsEmpty.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- TestIsEmpty.java 24 Nov 2003 21:38:39 - 1.4
+++ TestIsEmpty.java 24 Nov 2003 23:11:48 - 1.5
@@ -58,8 +58,10 @@
import java.util.ArrayList;
import java.util.Collections;
+import java.util.HashMap;
import java.util.HashSet;
import java.util.List;
+import java.util.Map;
import java.util.Set;
import junit.framework.Test;
@@ -137,8 +139,8 @@
public void testTestNonCollection() throws Exception {
try {
IsEmpty.instance().test(new Integer(3));
-fail(Expected ClassCastException);
-} catch(ClassCastException e) {
+fail(Expected IllegalArgumentException);
+} catch(IllegalArgumentException e) {
// expected
}
}
@@ -153,6 +155,13 @@
public void testTestString() throws Exception {
assertTrue(! IsEmpty.instance().test(xyzzy));
assertTrue(IsEmpty.instance().test());
+}
+
+public void testTestMap() throws Exception {
+Map map = new HashMap();
+assertTrue(IsEmpty.instance().test(map));
+map.put(x,y);
+assertTrue(! IsEmpty.instance().test(map));
}
public void testEquals() throws Exception {
1.4 +14 -7
jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/collection/IsEmpty.java
Index: IsEmpty.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/collection/IsEmpty.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- IsEmpty.java 24 Nov 2003 21:38:39 - 1.3
+++ IsEmpty.java 24 Nov 2003 23:11:48 - 1.4
@@ -59,6 +59,7 @@
import java.io.Serializable;
import java.lang.reflect.Array;
import java.util.Collection;
+import java.util.Map;
import org.apache.commons.functor.UnaryPredicate;
@@ -78,15 +79,17 @@
public boolean test(Object obj) {
if(obj instanceof Collection) {
-return test((Collection)obj);
+return testCollection((Collection)obj);
+} else if(obj instanceof Map) {
+return testMap((Map)obj);
} else if(obj instanceof String) {
-return test((String)obj);
+return testString((String)obj);
} else if(null != obj obj.getClass().isArray()) {
return testArray(obj);
} else if(null == obj){
throw new NullPointerException(Argument must not be null);
} else {
-throw new ClassCastException(Expected Collection, String or Array,
found + obj);
+throw new IllegalArgumentException(Expected Collection, Map, String or
Array, found + obj.getClass());
}
}
@@ -111,11 +114,15 @@
return IsEmpty();
}
-private boolean test(Collection col) {
+private boolean testCollection(Collection col) {
return col.isEmpty();
}
-private boolean test(String str) {
+private boolean testMap(Map map) {
+return map.isEmpty();
+}
+
+private boolean testString(String str) {
return 0 == str.length();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server HttpRequestHandlerChain.java
oglueck 2003/11/24 15:13:22
Modified:httpclient/src/test/org/apache/commons/httpclient/server
Tag: HTTPCLIENT_2_0_BRANCH
HttpRequestHandlerChain.java
Log:
Making this class thread-safe as it is accessed from different threads.
Revision ChangesPath
No revision
No revision
1.1.2.3 +8 -8
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/HttpRequestHandlerChain.java
Index: HttpRequestHandlerChain.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/HttpRequestHandlerChain.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- HttpRequestHandlerChain.java 24 Nov 2003 20:41:11 - 1.1.2.2
+++ HttpRequestHandlerChain.java 24 Nov 2003 23:13:22 - 1.1.2.3
@@ -84,22 +84,22 @@
public HttpRequestHandlerChain() {
}
-public void clear() {
+public synchronized void clear() {
subhandlers.clear();
}
-public void prependHandler(HttpRequestHandler handler) {
+public synchronized void prependHandler(HttpRequestHandler handler) {
subhandlers.add(0,handler);
}
-public void appendHandler(HttpRequestHandler handler) {
+public synchronized void appendHandler(HttpRequestHandler handler) {
subhandlers.add(handler);
}
-public boolean processRequest(SimpleHttpServerConnection conn) throws
IOException {
+public synchronized boolean processRequest(SimpleHttpServerConnection conn)
throws IOException {
for(Iterator it=subhandlers.iterator();it.hasNext();) {
HttpRequestHandler h = (HttpRequestHandler)it.next();
boolean stop = h.processRequest(conn);
-if(stop) {
+if (stop) {
return true;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server SimpleHttpServer.java
oglueck 2003/11/24 15:14:33
Modified:httpclient/src/test/org/apache/commons/httpclient/server
Tag: HTTPCLIENT_2_0_BRANCH SimpleHttpServer.java
Log:
Added support for systems with more than one network interface.
Revision ChangesPath
No revision
No revision
1.1.2.4 +12 -6
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/SimpleHttpServer.java
Index: SimpleHttpServer.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/SimpleHttpServer.java,v
retrieving revision 1.1.2.3
retrieving revision 1.1.2.4
diff -u -r1.1.2.3 -r1.1.2.4
--- SimpleHttpServer.java 24 Nov 2003 20:41:11 - 1.1.2.3
+++ SimpleHttpServer.java 24 Nov 2003 23:14:33 - 1.1.2.4
@@ -119,13 +119,21 @@
}
/**
- * Returns the TCP port on which this HTTP server instance is bound to.
+ * Returns the TCP port that this HTTP server instance is bound to.
*
* @return TCP port, or -1 if not running
*/
public int getLocalPort() {
return server.getLocalPort();
}
+
+/**
+ * Returns the IP address that this HTTP server instance is bound to.
+ * @return String representation of the IP address or codenull/code if not
running
+ */
+public String getLocalAddress() {
+ return server.getInetAddress().getHostAddress();
+}
/**
* Checks if this HTTP server instance is running.
@@ -202,8 +210,6 @@
conn.connectionClose();
ErrorResponse.getInstance().getResponse(HttpStatus.SC_SERVICE_UNAVAILABLE).processRequest(conn);
}
-
-conn.getWriter().flush();
}
public void run() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server SimpleHttpServerConnection.java
oglueck 2003/11/24 15:16:42
Modified:httpclient/src/test/org/apache/commons/httpclient/server
Tag: HTTPCLIENT_2_0_BRANCH
SimpleHttpServerConnection.java
Log:
We do housekeeping on our internal objects ourselves.
Revision ChangesPath
No revision
No revision
1.1.2.4 +4 -3
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/SimpleHttpServerConnection.java
Index: SimpleHttpServerConnection.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/SimpleHttpServerConnection.java,v
retrieving revision 1.1.2.3
retrieving revision 1.1.2.4
diff -u -r1.1.2.3 -r1.1.2.4
--- SimpleHttpServerConnection.java 24 Nov 2003 20:41:11 - 1.1.2.3
+++ SimpleHttpServerConnection.java 24 Nov 2003 23:16:42 - 1.1.2.4
@@ -196,6 +196,7 @@
return;
}
server.processRequest(this);
+out.flush();
}
public Header[] getHeaders() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections][PROPOSAL] Remove Observable subpackage
I think it's a good idea to remove it. At this point, [collections] is so big that I'm +1 for removing all that we can. I frequently get OutOfMemoryExceptions when doing the maven build due to the size (from the statcvs and linkcheck plugins). Now as to where it should go, I always like the idea of doing it at Apache if possible. Here's an idea: [collections] has already spawned off another subproject in [primitives]. There is the alternative primitive collections (let's call it [primitives2], I forget what the actual name is) that you have at SourceForge, and now the possibility of [observable]. However, all of these projects, in a way, still fall under the domain of [collections]. Perhaps it's time for collections to become a larger project which can contain subprojects. I'm not sure if this is doable in Jakarta Commons, but maybe in top-level Jakarta or the newer Apache Commons? All administrative burdens aside, this makes more sense to me. The current [collections] could become [collections-core], along with the newer [collections-primitives] and [collections-observable]. This would allow proper room to grow for each subproject -- while still keeping related projects together. I realize that this is a semi-radical idea, but maybe it's worth considering? At a minimum, I think it would provide the newer subprojects with more visibility and possible promote a more active community. Stephen Colebourne wrote: I would like to propose that the observable subpackage of [collections] be removed to another location. It remains a relatively self contained part of [collections] following the recent restructuring, and has the potential to grow with other event strategies and integration with GUIs such as Swing. This makes it a relatively poor fit with the rest of [collections]. Either the sandbox, or sourceforge seem appropriate for the code. I know there is demand for the code and a release, but I don't want to let it lie unreleased in [collections] as primitives did for far too long. So, whos in favour of removing it from [collections]? And where to, sandbox (observable), sourceforge (joda-observable), or elsewhere? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP - ReapingObjectPool
I saw AbandonedObjectPool but it is deprecated and is in the DBCP.
I was looking for an ObjectPool.
I've extended GenericObjectPool with similar features.
Here it is.
I'm using this as the ObjectPool of a PoolingDataSource and is working
perfectly well.
note:
TimestampedStackTrace is not generic, it responds to my particular
needs and can be taken away or replaced pretty simple.
N.
Dirk Verbeeck wrote:
Actually we already have something similar: AbandonedObjectPool.
http://jakarta.apache.org/commons/dbcp/xref/org/apache/commons/dbcp/AbandonedObjectPool.html
Many enhancements are possible, I have been playing around the
java.lang.ref package to see if it can provide a safe way to recover
abandoned objects.
Contributing is as simple as posting your improvements to the list.
A whole new file or a patch for existing files.
If there isn't a committer around then you can also make a bugzilla
item for it. Writing comments to make the review easier helps and if
you have junit tests then you can be sure your contribution won't go
unnoticed.
If you're thinking about doing a lot of work then first discuss it on
the list just to make sure we are on the same line.
Contributions are always welcome, bugfixes, enhancements, website
updates, documentation, you name it...
Cheers
Dirk
Juan Ignacio Cidre wrote:
I was needing an ObjectPool that 'remembers' the borrowed objects so
it can recollect them if not returned after a while.
Is there something like that arround?
I've extended GenericObjectPool to have that functionallity. I can
give it to the project if there is not a better option than mine.
Since this would be my first contribution to the project, and I don't
know the customs, I would need some help (I've read all the on-line
guides, already, )
N.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
/*
* Created on 07-nov-2003
* @author [EMAIL PROTECTED]
*/
package org.apache.commons.pool;
import java.io.PrintWriter;
import java.io.StringWriter;
/**
* @author [EMAIL PROTECTED]
* @date 07-nov-2003
* @this is a StackTrace and the exact time of its creation
*/
public class TimestampedStackTrace {
/**
* The StackTrace is remembered as an exception to, next, ask its stackTrace()
*/
private Exception stackTrace;
/*
* Millis of creation Time
*/
private long lastUsed;
/**
* @param obj
*/
public TimestampedStackTrace() {
stackTrace = new Exception(Open StackTrace);
lastUsed = System.currentTimeMillis();
}
/**
* @return
*/
public Exception getStackTrace() {
return stackTrace;
}
/**
* @return
*/
public long getLastUsed() {
return lastUsed;
}
public String getStackTraceAsString() {
StringWriter sw = new StringWriter();
stackTrace.printStackTrace(new PrintWriter(sw));
return sw.toString();
}
}
/*
* Created on 07-nov-2003
* @author [EMAIL PROTECTED]
*/
package org.apache.commons.pool;
import java.util.ArrayList;
import java.util.Hashtable;
import java.util.Iterator;
import java.util.Map;
import org.apache.commons.pool.impl.GenericObjectPool;
import ar.com.eds.x71.framework.Ownable;
import ar.com.eds.x71.framework.log.SysLog;
/**
* @author [EMAIL PROTECTED]
* @date 07-nov-2003
* @ObjectPool that remember borrowed objects and have politics to rescue them.
*/
public class ReapingObjectPool extends GenericObjectPool {
/**
* timpo que puede estar activa la conexion
*/
private long maxActiveTime;
/**
* Conjunto de conexiones activas.
*/
private Map active = new Hashtable();
/**
* Get a db connection from the pool.
*
* If removeAbandoned=true, recovers db connections which
* have been idle removeAbandonedTimeout.
*
* @return Object jdbc Connection
*/
public Object borrowObject() throws Exception {
Object obj;
try {
obj = super.borrowObject();
}
catch (Exception e) {
String[] activeTraces = getActiveTrace();
SysLog.getLogger(ReapingObjectPool).warn(**);
SysLog.getLogger(ReapingObjectPool).warn(PROBLEMAS TRAYENDO
UN OBJETO DEL POOL);
SysLog.getLogger(ReapingObjectPool).warn(OBJETOS ACTIVOS
DEL POOL);
SysLog.getLogger(ReapingObjectPool).warn();
for (int i = 0; i activeTraces.length; i++) {
RE: [lang] possible DateUtils method
If i can figure out how to do the patch. is it
diff -n
?
Then do i just post the diff along with the test diff
to the newsgroup?
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 6:12 PM
To: Jakarta Commons Developers List
Subject: Re: [lang] possible DateUtils method
I think this would make a good addition to DateUtils. Would you like to
provide a patch and tests?
Stephen
- Original Message -
From: Inger, Matthew [EMAIL PROTECTED]
public static final long MILLIS_IN_DAY = 1000*60*60*24;
public long getDaysBetween(Calendar c1, Calendar c2)
{
long c1Normalized = c1.getTime().getTime() +
c1.get(Calendar.ZONE_OFFSET) +
c1.get(Calendar.DST_OFFSET);
long c2Normalized = c2.getTime().getTime() +
c2.get(Calendar.ZONE_OFFSET) +
c2.get(Calendar.DST_OFFSET);
long diff = c1Normalized - c2Normalized;
long numDays = diff / MILLIS_IN_DAY;
return numDays;
}
A common mistake most people make is to ignore daylight savings
time when trying to compute the number of days between two Calendar
dates. If you cross the DST boundary when the clock jumps forward,
just subtracting the date objects and dividing will end up giving you
an answer that is off by 1 day. This happens because the clock jumps
ahead, and 00:00 EDT is actually 11:00 EST on the previous day, so the
number of hours is off by 1, and thus the calculation doesn't end up
working
properly. The other thing i'm doing here is to convert to GMT time,
allowing
for the two Calendar objects to have different timezones.
We could have similar methods for getHoursBetween and so forth. Months
would be a bit more complicated of an algorithm.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] possible DateUtils method
Is this necessary?
The result of Calendar.getTime().getTime() is a long representing the number of
milliseconds since the epoch where the epochal point is defined as Jan 1, 1970
00:00:00.000 GMT. This already normalizes for GMT and for daylight savings. The
calendar class essentially provides various filters about this value to transform the
time into something human understandable (this includes accomodating daylight savings
and timezone offsets).
I'm not sure why we'd want to further offset the milliseconds value with timezone and
daylight savings offset - the original numbers are already normalized to the same
point in time.
I agree that there's utility to be found in things like getDaysBetween (just believe
this implementation behaves incorrectly), but if I recall, there was, at some point
(if not today) a Duration class being developed to represent durations. I'm not sure
if anyone is still working on it, but it seems that this might be the way to go -
define Durations and how to convert between durations and java.util.Date differences.
-AMT
-Original Message-
From: Inger, Matthew [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 20, 2003 7:34 AM
To: 'Jakarta Commons Developers List'
Subject: [lang] possible DateUtils method
public static final long MILLIS_IN_DAY = 1000*60*60*24;
public long getDaysBetween(Calendar c1, Calendar c2)
{
long c1Normalized = c1.getTime().getTime() +
c1.get(Calendar.ZONE_OFFSET) +
c1.get(Calendar.DST_OFFSET);
long c2Normalized = c2.getTime().getTime() +
c2.get(Calendar.ZONE_OFFSET) +
c2.get(Calendar.DST_OFFSET);
long diff = c1Normalized - c2Normalized;
long numDays = diff / MILLIS_IN_DAY;
return numDays;
}
A common mistake most people make is to ignore daylight savings time when trying to
compute the number of days between two Calendar dates. If you cross the DST boundary
when the clock jumps forward, just subtracting the date objects and dividing will end
up giving you an answer that is off by 1 day. This happens because the clock jumps
ahead, and 00:00 EDT is actually 11:00 EST on the previous day, so the number of hours
is off by 1, and thus the calculation doesn't end up working properly. The other
thing i'm doing here is to convert to GMT time, allowing for the two Calendar objects
to have different timezones.
We could have similar methods for getHoursBetween and so forth. Months would be a bit
more complicated of an algorithm.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] unexpected StringUtils.split behavior (was RE: suggest ion for new StringUtils.method)
There's a new tokenizer attached to defect 22692 which does
CSV style tokenizing. Test class is attached as well. Just
waiting on someone to commit it.
-Original Message-
From: Al Chou [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 2:02 PM
To: Jakarta Commons Developers List
Subject: RE: [lang] unexpected StringUtils.split behavior (was RE:
suggestion for new StringUtils.method)
I am only skimming [lang] posts for stuff pretty closely related to my
issue,
so I hadn't given much thought to the new StringTokenizer replacement --
perhaps I felt it was a little too new for me to be adding even more new
stuff.
Whoever wants to is welcome to incorporate this new method there, if it
gets
committed to StringUtils at all in the first place.
Al
--- Arun Thomas [EMAIL PROTECTED] wrote:
I also know that this is more than you intended, but any thought of
incorporating the split on string into the new StringTokenizer replacement
as
well? I think that would be pretty useful. (It's behaviour in two
places,
but implementation could certainly delegate)
-AMT
-Original Message-
From: Al Chou [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2003 10:22 PM
To: Jakarta Commons Developers List
Subject: [lang] unexpected StringUtils.split behavior (was RE: suggestion
for
new StringUtils.method)
I guess my previous post got lost in the noise, so I'm reposting. I have
two
new StringUtils.split methods that can split a string at occurrences of a
substring rather than splitting at the individual characters in the
specified
delimiter string.
While testing, I discovered that my expectations for the behavior of the
split( *, ..., int max ) methods didn't match their actual behavior. I
expected to get a maximum of max substrings, all of which were delimited
in
the parent string by the specified delimiters. Instead, what you get is
max
- 1 such substrings, plus the rest of the parent string as the final
result
substring.
This behavior seems counter to what StringTokenizer would do, which is
surprising, given the Javadoc comments about using the split methods as
alternatives to StringTokenizer.
Currently, my tests reflect my expectations for the behavior, and I
modified
the existing split( String, String, int ) method to match my expectations.
I
didn't want to submit such a change as a proposed patch without first
getting
feedback from the community about whether my expectations are wrong. I am
happy to submit only code that does not change the behavior of the
existing
methods, if need be.
Al
--- Al Chou [EMAIL PROTECTED] wrote:
This thread is a good entree for my question. I was adding a new
StringUtils.split method that can split a string using a whole string
as the delimiter, rather than the characters within that string. In
running my JUnit tests, I discovered unexpected behavior in the
existing method:
String stringToSplitOnNulls = ab de fg ;
String[] splitOnNullExpectedResults = { ab, de } ;
String[] splitOnNullResults = StringUtils.split( stringToSplitOnNulls,
null, 2
) ;
assertEquals( splitOnNullExpectedResults.length,
splitOnNullResults.length ) ; for ( int i = 0 ; i
splitOnNullExpectedResults.length ; i+= 1 ) {
assertEquals( splitOnNullExpectedResults[i], splitOnNullResults[i] )
;
}
The result of the split call is
ab, de fg
and it doesn't look to me like StringTokenizer's documentation implies
this behavior
Al
=
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] [PATCH] Adding Ant-like properties support
On 24 Nov 2003, at 22:54, Simon Kitching wrote:
On Tue, 2003-11-25 at 11:32, robert burrell donkin wrote:
i've finally found time to consider both proposals (apologies for the
delay).
1. i think that i like some parts of remy's solution but would prefer
the actual implementation to be pluggable through a strategy interface
(probably implemented as an abstract class). i know that this is a
little slower but i think that in the long term, it's better for
digester not to be tied to a particular implementation (no matter how
good ;)
Could you expand on this strategy interface a little, Robert? I'm not
quite sure what you mean here.
Are you suggesting something like this?
interface VarExpander {
/** expand any variable references in the string */
String expand(String raw);
}
and
Digester.setVarExpander(VarExpander varExpander)
a little. i was using interface in the modelling sense (which you'll
probably have guessed will mean that i'm going to make it an abstract
class since it'll probably need to be expanded in the future).
abstract class ReplacementStrategy {
public abstract Attributes replaceAttributes(Attributes
baseAttributes);
}
with a getter and setter. the actual interface is still a little fluid
in my mind at the moment. the name might also change.
so that the user can control exactly how variables are detected in
strings, and how the replacement data is located?
that's pretty much right.
That sounds good to me. The default could be Remy's implementation
which
requires the syntax ${xxx} and which always draws from one source. My
suggestion of an enhanced version that allows more flexible variable
detection and multiple sources could be provided as an alternative
[provided anyone thinks it is useful enough to add to the Digester
base]. This seems symmetrical with the BaseRules/ExtendedBaseRules
approach.
i was planning on making the default no substitution :)
this will preserve backward's compatibility.
remy's will be the headline (or basic) substitution implementation.
2. i think that simon's correct that the right place to do this is in
digester rather than in particular rules. coding this into rules is
just going to cause confusion for users and difficulties when some
rules support it and some don't.
I was actually working on this last night. I've come up with the idea
of
a lazy evaluation wrapper for the org.xml.sax.Attributes class, which
only checks attribute values for variables when the attribute value is
asked for.
I hope to be able to post this to the list in about 24 hours time.
This hopefully solves Remy's (quite correct) objection about
performance
with the code I originally posted.
i was planning to use something along those lines. lazy is probably
good but maybe need to think about caching results. i think that we
should be able to re-use the same instance without worrying about
re-entancy (but i'll need to double check that tommorrow).
3. i'd prefer not to subclass and instead use a seamless substitution.
i'd probably start with just the attribute values and provide just the
behaviour in remy's post.
Is this in reference to the implementation I posted which subclassed
Digester in order to provide this functionality? That was never
intended
to be a final solution; it's just what I currently have in production.
For production code, I don't like modifying libraries :-). I agree that
var expansion should really be integrated into the existing digester
stuff without subclassing Digester.
The stuff I posted wasn't a prepared patch; I just grabbed some stuff I
already had floating around and sent it out as an alternative
suggestion. Sorry if that wasn't clear.
If you meant something else by prefer not to subclass please let me
know.
it was just a comment :)
i'd like to see support for this in the core digester implementation
(rather than in a subclass).
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] unexpected StringUtils.split behavior (was RE: suggestion for new StringUtils.method)
It's been checked in
The most recent changes you made haven't been checked in because I believe Stephen
adapted your original a little as he was checking it in Further changes should be
made to the checked in version, rather than the original.
-AMT
-Original Message-
From: Inger, Matthew [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 3:31 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [lang] unexpected StringUtils.split behavior (was RE: suggestion for new
StringUtils.method)
There's a new tokenizer attached to defect 22692 which does
CSV style tokenizing. Test class is attached as well. Just waiting on someone to
commit it.
-Original Message-
From: Al Chou [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 2:02 PM
To: Jakarta Commons Developers List
Subject: RE: [lang] unexpected StringUtils.split behavior (was RE: suggestion for new
StringUtils.method)
I am only skimming [lang] posts for stuff pretty closely related to my issue, so I
hadn't given much thought to the new StringTokenizer replacement -- perhaps I felt it
was a little too new for me to be adding even more new stuff. Whoever wants to is
welcome to incorporate this new method there, if it gets committed to StringUtils at
all in the first place.
Al
--- Arun Thomas [EMAIL PROTECTED] wrote:
I also know that this is more than you intended, but any thought of
incorporating the split on string into the new StringTokenizer
replacement
as
well? I think that would be pretty useful. (It's behaviour in two
places,
but implementation could certainly delegate)
-AMT
-Original Message-
From: Al Chou [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2003 10:22 PM
To: Jakarta Commons Developers List
Subject: [lang] unexpected StringUtils.split behavior (was RE: suggestion
for
new StringUtils.method)
I guess my previous post got lost in the noise, so I'm reposting. I
have
two
new StringUtils.split methods that can split a string at occurrences
of a substring rather than splitting at the individual characters in
the
specified
delimiter string.
While testing, I discovered that my expectations for the behavior of
the split( *, ..., int max ) methods didn't match their actual
behavior. I expected to get a maximum of max substrings, all of
which were delimited
in
the parent string by the specified delimiters. Instead, what you get
is
max
- 1 such substrings, plus the rest of the parent string as the final
result
substring.
This behavior seems counter to what StringTokenizer would do, which is
surprising, given the Javadoc comments about using the split methods as
alternatives to StringTokenizer.
Currently, my tests reflect my expectations for the behavior, and I
modified
the existing split( String, String, int ) method to match my
expectations.
I
didn't want to submit such a change as a proposed patch without first
getting
feedback from the community about whether my expectations are wrong.
I am happy to submit only code that does not change the behavior of
the
existing
methods, if need be.
Al
--- Al Chou [EMAIL PROTECTED] wrote:
This thread is a good entree for my question. I was adding a new
StringUtils.split method that can split a string using a whole string
as the delimiter, rather than the characters within that string. In
running my JUnit tests, I discovered unexpected behavior in the
existing method:
String stringToSplitOnNulls = ab de fg ;
String[] splitOnNullExpectedResults = { ab, de } ;
String[] splitOnNullResults = StringUtils.split(
stringToSplitOnNulls,
null, 2
) ;
assertEquals( splitOnNullExpectedResults.length,
splitOnNullResults.length ) ; for ( int i = 0 ; i
splitOnNullExpectedResults.length ; i+= 1 ) {
assertEquals( splitOnNullExpectedResults[i], splitOnNullResults[i] )
;
}
The result of the split call is
ab, de fg
and it doesn't look to me like StringTokenizer's documentation
implies
this behavior
Al
=
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] possible DateUtils method
I believe it's
cvs diff -u
And the most efficient way is to open up an enhancement entry in
Bugzilla and attach the patch there. That way it won't get lost in the mix.
Inger, Matthew wrote:
If i can figure out how to do the patch. is it
diff -n
?
Then do i just post the diff along with the test diff
to the newsgroup?
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 6:12 PM
To: Jakarta Commons Developers List
Subject: Re: [lang] possible DateUtils method
I think this would make a good addition to DateUtils. Would you like to
provide a patch and tests?
Stephen
- Original Message -
From: Inger, Matthew [EMAIL PROTECTED]
public static final long MILLIS_IN_DAY = 1000*60*60*24;
public long getDaysBetween(Calendar c1, Calendar c2)
{
long c1Normalized = c1.getTime().getTime() +
c1.get(Calendar.ZONE_OFFSET) +
c1.get(Calendar.DST_OFFSET);
long c2Normalized = c2.getTime().getTime() +
c2.get(Calendar.ZONE_OFFSET) +
c2.get(Calendar.DST_OFFSET);
long diff = c1Normalized - c2Normalized;
long numDays = diff / MILLIS_IN_DAY;
return numDays;
}
A common mistake most people make is to ignore daylight savings
time when trying to compute the number of days between two Calendar
dates. If you cross the DST boundary when the clock jumps forward,
just subtracting the date objects and dividing will end up giving you
an answer that is off by 1 day. This happens because the clock jumps
ahead, and 00:00 EDT is actually 11:00 EST on the previous day, so the
number of hours is off by 1, and thus the calculation doesn't end up
working
properly. The other thing i'm doing here is to convert to GMT time,
allowing
for the two Calendar objects to have different timezones.
We could have similar methods for getHoursBetween and so forth. Months
would be a bit more complicated of an algorithm.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] unexpected StringUtils.split behavior (was RE: suggest ion for new StringUtils.method)
ok. will he be making those changes? Or do i need to do it.
-Original Message-
From: Arun Thomas [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 6:30 PM
To: Jakarta Commons Developers List
Subject: RE: [lang] unexpected StringUtils.split behavior (was RE:
suggestion for new StringUtils.method)
It's been checked in
The most recent changes you made haven't been checked in because I believe
Stephen adapted your original a little as he was checking it in Further
changes should be made to the checked in version, rather than the original.
-AMT
-Original Message-
From: Inger, Matthew [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 3:31 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [lang] unexpected StringUtils.split behavior (was RE:
suggestion for new StringUtils.method)
There's a new tokenizer attached to defect 22692 which does
CSV style tokenizing. Test class is attached as well. Just waiting on
someone to commit it.
-Original Message-
From: Al Chou [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 2:02 PM
To: Jakarta Commons Developers List
Subject: RE: [lang] unexpected StringUtils.split behavior (was RE:
suggestion for new StringUtils.method)
I am only skimming [lang] posts for stuff pretty closely related to my
issue, so I hadn't given much thought to the new StringTokenizer replacement
-- perhaps I felt it was a little too new for me to be adding even more new
stuff. Whoever wants to is welcome to incorporate this new method there, if
it gets committed to StringUtils at all in the first place.
Al
--- Arun Thomas [EMAIL PROTECTED] wrote:
I also know that this is more than you intended, but any thought of
incorporating the split on string into the new StringTokenizer
replacement
as
well? I think that would be pretty useful. (It's behaviour in two
places,
but implementation could certainly delegate)
-AMT
-Original Message-
From: Al Chou [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2003 10:22 PM
To: Jakarta Commons Developers List
Subject: [lang] unexpected StringUtils.split behavior (was RE: suggestion
for
new StringUtils.method)
I guess my previous post got lost in the noise, so I'm reposting. I
have
two
new StringUtils.split methods that can split a string at occurrences
of a substring rather than splitting at the individual characters in
the
specified
delimiter string.
While testing, I discovered that my expectations for the behavior of
the split( *, ..., int max ) methods didn't match their actual
behavior. I expected to get a maximum of max substrings, all of
which were delimited
in
the parent string by the specified delimiters. Instead, what you get
is
max
- 1 such substrings, plus the rest of the parent string as the final
result
substring.
This behavior seems counter to what StringTokenizer would do, which is
surprising, given the Javadoc comments about using the split methods as
alternatives to StringTokenizer.
Currently, my tests reflect my expectations for the behavior, and I
modified
the existing split( String, String, int ) method to match my
expectations.
I
didn't want to submit such a change as a proposed patch without first
getting
feedback from the community about whether my expectations are wrong.
I am happy to submit only code that does not change the behavior of
the
existing
methods, if need be.
Al
--- Al Chou [EMAIL PROTECTED] wrote:
This thread is a good entree for my question. I was adding a new
StringUtils.split method that can split a string using a whole string
as the delimiter, rather than the characters within that string. In
running my JUnit tests, I discovered unexpected behavior in the
existing method:
String stringToSplitOnNulls = ab de fg ;
String[] splitOnNullExpectedResults = { ab, de } ;
String[] splitOnNullResults = StringUtils.split(
stringToSplitOnNulls,
null, 2
) ;
assertEquals( splitOnNullExpectedResults.length,
splitOnNullResults.length ) ; for ( int i = 0 ; i
splitOnNullExpectedResults.length ; i+= 1 ) {
assertEquals( splitOnNullExpectedResults[i], splitOnNullResults[i] )
;
}
The result of the split call is
ab, de fg
and it doesn't look to me like StringTokenizer's documentation
implies
this behavior
Al
=
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/generator/util IntegerRange.java
rwaldhoff2003/11/24 15:39:17
Modified:functor/src/test/org/apache/commons/functor/generator/util
TestAll.java
Added: functor/src/test/org/apache/commons/functor/generator/util
TestIntegerRange.java
functor/src/java/org/apache/commons/functor/generator/util
IntegerRange.java
Log:
add IntegerRange and tests
Revision ChangesPath
1.2 +3 -2
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/generator/util/TestAll.java
Index: TestAll.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/generator/util/TestAll.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TestAll.java 30 Jun 2003 11:00:13 - 1.1
+++ TestAll.java 24 Nov 2003 23:39:17 - 1.2
@@ -73,6 +73,7 @@
TestSuite suite = new TestSuite();
suite.addTest(TestEachElement.suite());
suite.addTest(TestNumberRange.suite());
+suite.addTest(TestIntegerRange.suite());
return suite;
}
}
1.1
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/generator/util/TestIntegerRange.java
Index: TestIntegerRange.java
===
/*
* $Header:
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/generator/util/TestIntegerRange.java,v
1.1 2003/11/24 23:39:17 rwaldhoff Exp $
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution,
*if any, must include the following acknowledgment:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgment may appear in the software itself,
*if and wherever such third-party acknowledgments normally appear.
*
* 4. The names 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 name, without prior written
*permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*/
package org.apache.commons.functor.generator.util;
import junit.framework.Test;
import junit.framework.TestSuite;
import org.apache.commons.functor.BaseFunctorTest;
/**
* @version $Revision: 1.1 $ $Date: 2003/11/24 23:39:17 $
* @author Jason Horman ([EMAIL PROTECTED])
* @author Rodney Waldhoff
*/
public class TestIntegerRange extends BaseFunctorTest {
// Conventional
//
public TestIntegerRange(String name) {
super(name);
}
Re: [OT] RE: DBCP - ReapingObjectPool
Long story.
I got involved in a big-almost-finished project (arround 6.000 classes,
up to 15 levels of inheritance) 3 months ago to rework the core. It was
having problems. i.e. lost connections and never closed transactions,
concurrency problems, etc.
Replacing the home made ConnectionPool for a good one ;) was easy.
Now I'm dealing with the lost transactions.
In this (again) home-made framework, transaction commiting and closing
is a programmer responsability.
:(
I'm trying to do the same thing here since is exactly the same problem.
finallizers and try{}finally{} has some particular problems in this
framework.
.
N.
Mainguy, Mike wrote:
Just out of curiosity,
What sort of situation do you have that objects get borrowed, but then
forgotten? This is an interesting side-effect of pooling.
worse is better
-Original Message-
From: Dirk Verbeeck [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 5:20 PM
To: Jakarta Commons Developers List
Subject: Re: DBCP - ReapingObjectPool
Actually we already have something similar: AbandonedObjectPool.
http://jakarta.apache.org/commons/dbcp/xref/org/apache/commons/dbcp/Abandone
dObjectPool.html
Many enhancements are possible, I have been playing around the java.lang.ref
package to see if it can provide a safe way to recover abandoned objects.
Contributing is as simple as posting your improvements to the list. A whole
new file or a patch for existing files. If there isn't a committer around
then you can also make a bugzilla item for
it. Writing comments to make the review easier helps and if you have junit
tests then you can be sure your contribution won't go unnoticed. If you're
thinking about doing a lot of work then first discuss it on the list
just to make sure we are on the same line.
Contributions are always welcome, bugfixes, enhancements, website updates,
documentation, you name it...
Cheers
Dirk
Juan Ignacio Cidre wrote:
I was needing an ObjectPool that 'remembers' the borrowed objects so
it
can recollect them if not returned after a while.
Is there something like that arround?
I've extended GenericObjectPool to have that functionallity. I can
give
it to the project if there is not a better option than mine.
Since this would be my first contribution to the project, and I don't
know the customs, I would need some help (I've read all the on-line
guides, already, )
N.
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] unexpected StringUtils.split behavior (was RE: suggest ion for new StringUtils.method)
I can't find it in cvs.
-Original Message-
From: Arun Thomas [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 6:30 PM
To: Jakarta Commons Developers List
Subject: RE: [lang] unexpected StringUtils.split behavior (was RE:
suggestion for new StringUtils.method)
It's been checked in
The most recent changes you made haven't been checked in because I believe
Stephen adapted your original a little as he was checking it in Further
changes should be made to the checked in version, rather than the original.
-AMT
-Original Message-
From: Inger, Matthew [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 3:31 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [lang] unexpected StringUtils.split behavior (was RE:
suggestion for new StringUtils.method)
There's a new tokenizer attached to defect 22692 which does
CSV style tokenizing. Test class is attached as well. Just waiting on
someone to commit it.
-Original Message-
From: Al Chou [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 2:02 PM
To: Jakarta Commons Developers List
Subject: RE: [lang] unexpected StringUtils.split behavior (was RE:
suggestion for new StringUtils.method)
I am only skimming [lang] posts for stuff pretty closely related to my
issue, so I hadn't given much thought to the new StringTokenizer replacement
-- perhaps I felt it was a little too new for me to be adding even more new
stuff. Whoever wants to is welcome to incorporate this new method there, if
it gets committed to StringUtils at all in the first place.
Al
--- Arun Thomas [EMAIL PROTECTED] wrote:
I also know that this is more than you intended, but any thought of
incorporating the split on string into the new StringTokenizer
replacement
as
well? I think that would be pretty useful. (It's behaviour in two
places,
but implementation could certainly delegate)
-AMT
-Original Message-
From: Al Chou [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2003 10:22 PM
To: Jakarta Commons Developers List
Subject: [lang] unexpected StringUtils.split behavior (was RE: suggestion
for
new StringUtils.method)
I guess my previous post got lost in the noise, so I'm reposting. I
have
two
new StringUtils.split methods that can split a string at occurrences
of a substring rather than splitting at the individual characters in
the
specified
delimiter string.
While testing, I discovered that my expectations for the behavior of
the split( *, ..., int max ) methods didn't match their actual
behavior. I expected to get a maximum of max substrings, all of
which were delimited
in
the parent string by the specified delimiters. Instead, what you get
is
max
- 1 such substrings, plus the rest of the parent string as the final
result
substring.
This behavior seems counter to what StringTokenizer would do, which is
surprising, given the Javadoc comments about using the split methods as
alternatives to StringTokenizer.
Currently, my tests reflect my expectations for the behavior, and I
modified
the existing split( String, String, int ) method to match my
expectations.
I
didn't want to submit such a change as a proposed patch without first
getting
feedback from the community about whether my expectations are wrong.
I am happy to submit only code that does not change the behavior of
the
existing
methods, if need be.
Al
--- Al Chou [EMAIL PROTECTED] wrote:
This thread is a good entree for my question. I was adding a new
StringUtils.split method that can split a string using a whole string
as the delimiter, rather than the characters within that string. In
running my JUnit tests, I discovered unexpected behavior in the
existing method:
String stringToSplitOnNulls = ab de fg ;
String[] splitOnNullExpectedResults = { ab, de } ;
String[] splitOnNullResults = StringUtils.split(
stringToSplitOnNulls,
null, 2
) ;
assertEquals( splitOnNullExpectedResults.length,
splitOnNullResults.length ) ; for ( int i = 0 ; i
splitOnNullExpectedResults.length ; i+= 1 ) {
assertEquals( splitOnNullExpectedResults[i], splitOnNullResults[i] )
;
}
The result of the split call is
ab, de fg
and it doesn't look to me like StringTokenizer's documentation
implies
this behavior
Al
=
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22692] - StringUtils.split ignores empty items
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=22692. 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=22692 StringUtils.split ignores empty items --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 23:44 --- I can't find the cvs version. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] [PATCH] Adding Ant-like properties support
On Tue, 2003-11-25 at 12:31, robert burrell donkin wrote:
On 24 Nov 2003, at 22:54, Simon Kitching wrote:
On Tue, 2003-11-25 at 11:32, robert burrell donkin wrote:
i've finally found time to consider both proposals (apologies for the
delay).
1. i think that i like some parts of remy's solution but would prefer
the actual implementation to be pluggable through a strategy interface
(probably implemented as an abstract class). i know that this is a
little slower but i think that in the long term, it's better for
digester not to be tied to a particular implementation (no matter how
good ;)
Could you expand on this strategy interface a little, Robert? I'm not
quite sure what you mean here.
Are you suggesting something like this?
interface VarExpander {
/** expand any variable references in the string */
String expand(String raw);
}
and
Digester.setVarExpander(VarExpander varExpander)
a little. i was using interface in the modelling sense (which you'll
probably have guessed will mean that i'm going to make it an abstract
class since it'll probably need to be expanded in the future).
abstract class ReplacementStrategy {
public abstract Attributes replaceAttributes(Attributes
baseAttributes);
}
with a getter and setter. the actual interface is still a little fluid
in my mind at the moment. the name might also change.
I'm *really* in favour of providing expansion in body text as well as
attributes.
I think that these two representations are equivalent:
person name=${name} email=${email}/
or
person
name${name}/name
email${email}/email
/person
If we only support attribute expansion, then the latter can never be
used. The VarExpander suggestion wraps the concept of expanding a
string without tying it to attribute strings. It can be called for
body text too. Can't think of any other text that might need expanding,
but if there is, then it can be called in that context too.
I also personally favour an interface rather than an abstract class. Who
knows what implementations people might come up with in the future :
retrieve values from LDAP? support emacs macros in variables?.
If the replacement strategy is an abstract class that brings
implementation baggage with it, then it might be more difficult to
implement those...
On the other hand, an abstract class *does* allow us to expand the
interface later by adding operations with default implementations,
without breaking code. I personally still feel more comfortable with a
pure interface in this case, though.
Cheers, Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] new functionality in StringUtils and ArrayUtils - proposal 01
All the concepts (flank, enclose, single quote, double quote) are rather trivial, or, let's say, they're simple append functions. However, they still do represent special cases of appending, and albeit simple, may merit inclusion to the StringUtils class considering that the class is largely a compendium of similar simple functions: If you can chomp a String, you can even flank it? flank/singleQuote/doubleQuote/enclose This has some potential as a StringUtils addition. Perhaps just focussing on the enclose method name, with enclose(str, encloseWith) enclose(str, before, after) Similar to string appending though so is it justified? lead/trail Very little gain over string appending - just null checking. But then thats what StringUtils often is. These two could become one though: concat(str1, str2) But lead and trail represent specific semantics, concat would do, but it's different semantically, isn't it? ArrayUtils.toString with alternate delimiter I can't see the use case for this, and if it exists then ToStringBuilder already handles it. This is from an array user's perspective. A coder who simply wanted to print an array and go on with his code would say why should I do a StringBuilder, I just want a direct toString(arr, ,\n\t), that's it! Of course, this could be a simple delegation to a StringBuilder implementation, but if an array-oriented view can be justified, it can perhaps be said that there is a use for this. ArrayUtils.toString(Object arr, int startIndex, int endIndex) Possible, but how often is this needed? One could use the subarray along with the existing toString. Feedback from others might throw more light on its need. ArrayUtils.subarray(arr, startIndex, endIndex) Looks good +1. Just need to determine whether the end points are inclusive or exclusive (suggest copying List API) The String.substring(startIndex, endIndex) can be suggested to be a good model to emulate, for the inclusiveness aspect. To proceded with ArrayUtils.subarray (gets you started), submit a CVS patch against the latest CVS with the new addition and suitable tests. I'll send this across presently. Ash - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang][PATCH] ArrayUtil.subarray(Object, startIndex, endIndex) implementation v 1.0
PFE a first implementation of the proposed ArrayUtil.subarray()implemented to take an Object array. Also encl some basic testcases. This is my first contribution, so I might take a while to get used to the some of the procedures of the group. Waiting for feedback and criticism. Thanks, Ashwin ArrayUtil.subarrayObject.zip Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] remove old ant build system
Yep,
that bug was fixed in RC1.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
__matthewHawthorne [EMAIL PROTECTED] wrote on 25/11/2003 01:22:38 AM:
I've had this happen when I had references to ${basedir} in the
project.xml. I think this is supposed to be fixed in maven 1.0-rc1?
Stefan Bodewig wrote:
On Sun, 23 Nov 2003, Henri Yandell [EMAIL PROTECTED] wrote:
I've gone ahead and done this.
One thing that you have to be aware of is that under some - unknown to
me - circumstances maven ant puts strange, absolute (specifc to your
machine) paths into the generated build file.
See http://gump.covalent.net/log/commons-io.html
;-)
Maybe dIon can help you out as he's been able to fix it whenever that
has happened in the past. He may even be able to tell us how to avoid
it, hi dIon 8-)
Stefan
-
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: [collections] CaseInsensitiveHashMap
Stephen Colebourne wrote:
I would like to propose an alternative solution to the problem that IMO fits
well with current [collections] direction.
Consider a new Map implementation that acts as a direct replacement for
HashMap, call it HashMapA (A for apache ;-). This class contains basically
the same code as HashMap, although it must be written without using cut and
paste (ie from scratch - Sun licence issues).
HashMapA differs from HashMap in that the hashing algorithm and equals
comparison methods are dedicated protected methods. It then becomes easy for
a subclass to be written that compares keys using case insensitivity
(amongst other things).
You could also consider having a subclass which delegates these methods
to another object (a Hasher?) to make it possible to override the logic
without subclassing.
public interface Hasher {
/**
* Get the hash code for a key.
*/
public int keyHashCode(Object key);
/**
* Tests if a pair of keys are equal.
*/
public boolean keysEqual(Object key1, Object key2);
}
public class DefaultHasher {
public int keyHashCode(Object key) {
return key.hashCode();
}
public boolean keysEqual(Object key1, Object key2) {
return key1.equals(key2);
}
}
public class ComposableHashMapA extends HashMapA {
private Hasher hasher = new DefaultHasher();
...
protected int keyHashCode(Object key) {
return hasher.keyHashCode(key);
}
protected boolean keysEqual(Object key1, Object key2) {
return hasher.keysEqual(key1, key2);
}
...
}
Rich
--
Rich Dougherty
http://www.rd.gen.nz/
pgp0.pgp
Description: PGP signature
cvs commit: jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/generator/util LongRange.java IntegerRange.java
rwaldhoff2003/11/24 15:59:21
Modified:functor/src/test/org/apache/commons/functor/generator/util
TestIntegerRange.java TestAll.java
functor/src/java/org/apache/commons/functor/generator/util
IntegerRange.java
Added: functor/src/test/org/apache/commons/functor/generator/util
TestLongRange.java
functor/src/java/org/apache/commons/functor/generator/util
LongRange.java
Log:
* add LongRange and tests
* make range functions exclusive of the to endpoint, so that things like
IntegerRange(Integer.MIN_VALUE,Integer.MAX_VALUE) can actually complete
Revision ChangesPath
1.2 +12 -12
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/generator/util/TestIntegerRange.java
Index: TestIntegerRange.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/generator/util/TestIntegerRange.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TestIntegerRange.java 24 Nov 2003 23:39:17 - 1.1
+++ TestIntegerRange.java 24 Nov 2003 23:59:21 - 1.2
@@ -124,34 +124,34 @@
public void testObjectConstructor() {
IntegerRange range = new IntegerRange(new Integer(0), new Integer(5));
-assertEquals([0, 1, 2, 3, 4, 5], range.toCollection().toString());
+assertEquals([0, 1, 2, 3, 4], range.toCollection().toString());
range = new IntegerRange(new Integer(0), new Integer(5), new Integer(1));
-assertEquals([0, 1, 2, 3, 4, 5], range.toCollection().toString());
+assertEquals([0, 1, 2, 3, 4], range.toCollection().toString());
}
public void testReverseStep() {
IntegerRange range = new IntegerRange(10, 0, -2);
-assertEquals([10, 8, 6, 4, 2, 0], range.toCollection().toString());
-assertEquals([10, 8, 6, 4, 2, 0], range.toCollection().toString());
+assertEquals([10, 8, 6, 4, 2], range.toCollection().toString());
+assertEquals([10, 8, 6, 4, 2], range.toCollection().toString());
}
public void testStep() {
IntegerRange range = new IntegerRange(0, 10, 2);
-assertEquals([0, 2, 4, 6, 8, 10], range.toCollection().toString());
-assertEquals([0, 2, 4, 6, 8, 10], range.toCollection().toString());
+assertEquals([0, 2, 4, 6, 8], range.toCollection().toString());
+assertEquals([0, 2, 4, 6, 8], range.toCollection().toString());
}
public void testForwardRange() {
IntegerRange range = new IntegerRange(0, 5);
-assertEquals([0, 1, 2, 3, 4, 5], range.toCollection().toString());
-assertEquals([0, 1, 2, 3, 4, 5], range.toCollection().toString());
+assertEquals([0, 1, 2, 3, 4], range.toCollection().toString());
+assertEquals([0, 1, 2, 3, 4], range.toCollection().toString());
}
public void testReverseRange() {
IntegerRange range = new IntegerRange(5, 0);
-assertEquals([5, 4, 3, 2, 1, 0], range.toCollection().toString());
-assertEquals([5, 4, 3, 2, 1, 0], range.toCollection().toString());
+assertEquals([5, 4, 3, 2, 1], range.toCollection().toString());
+assertEquals([5, 4, 3, 2, 1], range.toCollection().toString());
}
public void testEquals() {
1.3 +3 -2
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/generator/util/TestAll.java
Index: TestAll.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/generator/util/TestAll.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TestAll.java 24 Nov 2003 23:39:17 - 1.2
+++ TestAll.java 24 Nov 2003 23:59:21 - 1.3
@@ -74,6 +74,7 @@
suite.addTest(TestEachElement.suite());
suite.addTest(TestNumberRange.suite());
suite.addTest(TestIntegerRange.suite());
+suite.addTest(TestLongRange.suite());
return suite;
}
}
1.1
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/generator/util/TestLongRange.java
Index: TestLongRange.java
===
/*
* $Header:
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/generator/util/TestLongRange.java,v
1.1 2003/11/24 23:59:21 rwaldhoff Exp $
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
*
cvs commit: jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/generator/util TestIntegerRange.java TestLongRange.java
rwaldhoff2003/11/24 16:01:15
Modified:functor/src/test/org/apache/commons/functor/generator/util
TestIntegerRange.java TestLongRange.java
Log:
add test of edge case
Revision ChangesPath
1.3 +8 -2
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/generator/util/TestIntegerRange.java
Index: TestIntegerRange.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/generator/util/TestIntegerRange.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TestIntegerRange.java 24 Nov 2003 23:59:21 - 1.2
+++ TestIntegerRange.java 25 Nov 2003 00:01:15 - 1.3
@@ -154,6 +154,12 @@
assertEquals([5, 4, 3, 2, 1], range.toCollection().toString());
}
+public void testEdgeCase() {
+IntegerRange range = new IntegerRange(Integer.MAX_VALUE - 3,
Integer.MAX_VALUE);
+assertEquals([2147483644, 2147483645, 2147483646],
range.toCollection().toString());
+assertEquals([2147483644, 2147483645, 2147483646],
range.toCollection().toString());
+}
+
public void testEquals() {
IntegerRange range = new IntegerRange(1, 5);
assertObjectsAreEqual(range, range);
1.2 +3 -3
jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/generator/util/TestLongRange.java
Index: TestLongRange.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/generator/util/TestLongRange.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TestLongRange.java24 Nov 2003 23:59:21 - 1.1
+++ TestLongRange.java25 Nov 2003 00:01:15 - 1.2
@@ -154,7 +154,7 @@
assertEquals([5, 4, 3, 2, 1], range.toCollection().toString());
}
-public void testLongRange() {
+public void testEdgeCase() {
LongRange range = new LongRange(Long.MAX_VALUE - 3L, Long.MAX_VALUE);
assertEquals([9223372036854775804, 9223372036854775805,
9223372036854775806], range.toCollection().toString());
assertEquals([9223372036854775804, 9223372036854775805,
9223372036854775806], range.toCollection().toString());
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22692] - StringUtils.split ignores empty items
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=22692. 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=22692 StringUtils.split ignores empty items --- Additional Comments From [EMAIL PROTECTED] 2003-11-25 00:13 --- Created an attachment (id=9273) PatchFile for Tokenizer.java to add reset methods - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections][PROPOSAL] Remove Observable subpackage
--- __matthewHawthorne [EMAIL PROTECTED] wrote: I think it's a good idea to remove it. At this point, [collections] is so big that I'm +1 for removing all that we can. I frequently get OutOfMemoryExceptions when doing the maven build due to the size (from the statcvs and linkcheck plugins). Now as to where it should go, I always like the idea of doing it at Apache if possible. Amen on that. Here's an idea: Perhaps it's time for collections to become a larger project which can contain subprojects. I'm not sure if this is doable in Jakarta Commons, but maybe in top-level Jakarta or the newer Apache Commons? I realize that this is a semi-radical idea, but maybe it's worth considering? At a minimum, I think it would provide the newer subprojects with more visibility and possible promote a more active community. I think that's well worthy of consideration. Three [collections] projects perhaps should entitle [collections] to it's own project hierarchy, and I think it's vitally important to keep these projects under the same roof rather than have them skulk off to the dark corners of sourceforge where who knows what will become of them? ;) neil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] unexpected StringUtils.split behavior (was RE: suggest ion for new StringUtils.method)
I've submitted patches for what i was working on.
I had provided methods to completely reset the tokenizer,
including the input string, so that the same tokenizer can
be re-used when parsing a large file, and doesn't have to
be constantly recreated. See the bug for the patch files.
Also the test cases have been updated.
-Original Message-
From: Arun Thomas [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 6:30 PM
To: Jakarta Commons Developers List
Subject: RE: [lang] unexpected StringUtils.split behavior (was RE:
suggestion for new StringUtils.method)
It's been checked in
The most recent changes you made haven't been checked in because I believe
Stephen adapted your original a little as he was checking it in Further
changes should be made to the checked in version, rather than the original.
-AMT
-Original Message-
From: Inger, Matthew [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 3:31 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [lang] unexpected StringUtils.split behavior (was RE:
suggestion for new StringUtils.method)
There's a new tokenizer attached to defect 22692 which does
CSV style tokenizing. Test class is attached as well. Just waiting on
someone to commit it.
-Original Message-
From: Al Chou [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 2:02 PM
To: Jakarta Commons Developers List
Subject: RE: [lang] unexpected StringUtils.split behavior (was RE:
suggestion for new StringUtils.method)
I am only skimming [lang] posts for stuff pretty closely related to my
issue, so I hadn't given much thought to the new StringTokenizer replacement
-- perhaps I felt it was a little too new for me to be adding even more new
stuff. Whoever wants to is welcome to incorporate this new method there, if
it gets committed to StringUtils at all in the first place.
Al
--- Arun Thomas [EMAIL PROTECTED] wrote:
I also know that this is more than you intended, but any thought of
incorporating the split on string into the new StringTokenizer
replacement
as
well? I think that would be pretty useful. (It's behaviour in two
places,
but implementation could certainly delegate)
-AMT
-Original Message-
From: Al Chou [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2003 10:22 PM
To: Jakarta Commons Developers List
Subject: [lang] unexpected StringUtils.split behavior (was RE: suggestion
for
new StringUtils.method)
I guess my previous post got lost in the noise, so I'm reposting. I
have
two
new StringUtils.split methods that can split a string at occurrences
of a substring rather than splitting at the individual characters in
the
specified
delimiter string.
While testing, I discovered that my expectations for the behavior of
the split( *, ..., int max ) methods didn't match their actual
behavior. I expected to get a maximum of max substrings, all of
which were delimited
in
the parent string by the specified delimiters. Instead, what you get
is
max
- 1 such substrings, plus the rest of the parent string as the final
result
substring.
This behavior seems counter to what StringTokenizer would do, which is
surprising, given the Javadoc comments about using the split methods as
alternatives to StringTokenizer.
Currently, my tests reflect my expectations for the behavior, and I
modified
the existing split( String, String, int ) method to match my
expectations.
I
didn't want to submit such a change as a proposed patch without first
getting
feedback from the community about whether my expectations are wrong.
I am happy to submit only code that does not change the behavior of
the
existing
methods, if need be.
Al
--- Al Chou [EMAIL PROTECTED] wrote:
This thread is a good entree for my question. I was adding a new
StringUtils.split method that can split a string using a whole string
as the delimiter, rather than the characters within that string. In
running my JUnit tests, I discovered unexpected behavior in the
existing method:
String stringToSplitOnNulls = ab de fg ;
String[] splitOnNullExpectedResults = { ab, de } ;
String[] splitOnNullResults = StringUtils.split(
stringToSplitOnNulls,
null, 2
) ;
assertEquals( splitOnNullExpectedResults.length,
splitOnNullResults.length ) ; for ( int i = 0 ; i
splitOnNullExpectedResults.length ; i+= 1 ) {
assertEquals( splitOnNullExpectedResults[i], splitOnNullResults[i] )
;
}
The result of the split call is
ab, de fg
and it doesn't look to me like StringTokenizer's documentation
implies
this behavior
Al
=
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
cvs commit: jakarta-commons-sandbox/functor/src/test/org/apache/commons/functor/core TestOffset.java TestAll.java
rwaldhoff2003/11/24 16:22:26
Modified:functor/src/test/org/apache/commons/functor/core
TestAll.java
Added: functor/src/java/org/apache/commons/functor/core Offset.java
functor/src/test/org/apache/commons/functor/core
TestOffset.java
Log:
add Offset and tests
Revision ChangesPath
1.1
jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/Offset.java
Index: Offset.java
===
/*
* $Header:
/home/cvs/jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/Offset.java,v
1.1 2003/11/25 00:22:26 rwaldhoff Exp $
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution,
*if any, must include the following acknowledgment:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgment may appear in the software itself,
*if and wherever such third-party acknowledgments normally appear.
*
* 4. The names 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 name, without prior written
*permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*/
package org.apache.commons.functor.core;
import org.apache.commons.functor.BinaryPredicate;
import org.apache.commons.functor.Predicate;
import org.apache.commons.functor.UnaryPredicate;
/**
* A predicate that returns codefalse/code
* the first in/i times it is invoked, and
* codetrue/code thereafter.
*
* @since 1.0
* @version $Revision: 1.1 $ $Date: 2003/11/25 00:22:26 $
* @author Jason Horman ([EMAIL PROTECTED])
* @author Rodney Waldhoff
*/
public final class Offset implements Predicate, UnaryPredicate, BinaryPredicate {
public Offset(int count) {
if(count 0) {
throw new IllegalArgumentException(Argument must be a non-negative
integer.);
}
this.min = count;
}
public boolean test() {
// stop incremeting when we've hit max, so we don't loop around
if(current min) {
current++;
return false;
} else {
return true;
}
}
public boolean test(Object obj) {
return test();
}
public boolean test(Object a, Object b) {
return test();
}
public String toString() {
return Offset + min + ;
}
// instance variables
//---
private int min;
private int current = 0;
}
1.8 +3 -2
RE: [lang] unexpected StringUtils.split behavior (was RE: suggest ion for new StringUtils.method)
To clarify. By completely, i mean wiping out the token cache,
and reseting the iterator functionality, as well as resetting
the input. The configured parameters are not changed on a reset.
This has HUGE performance implications when working with a large
file that you're trying to tokenize.
-Original Message-
From: Inger, Matthew [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 7:19 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [lang] unexpected StringUtils.split behavior (was RE:
suggest ion for new StringUtils.method)
I've submitted patches for what i was working on.
I had provided methods to completely reset the tokenizer,
including the input string, so that the same tokenizer can
be re-used when parsing a large file, and doesn't have to
be constantly recreated. See the bug for the patch files.
Also the test cases have been updated.
-Original Message-
From: Arun Thomas [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 6:30 PM
To: Jakarta Commons Developers List
Subject: RE: [lang] unexpected StringUtils.split behavior (was RE:
suggestion for new StringUtils.method)
It's been checked in
The most recent changes you made haven't been checked in because I believe
Stephen adapted your original a little as he was checking it in Further
changes should be made to the checked in version, rather than the original.
-AMT
-Original Message-
From: Inger, Matthew [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 3:31 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [lang] unexpected StringUtils.split behavior (was RE:
suggestion for new StringUtils.method)
There's a new tokenizer attached to defect 22692 which does
CSV style tokenizing. Test class is attached as well. Just waiting on
someone to commit it.
-Original Message-
From: Al Chou [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 2:02 PM
To: Jakarta Commons Developers List
Subject: RE: [lang] unexpected StringUtils.split behavior (was RE:
suggestion for new StringUtils.method)
I am only skimming [lang] posts for stuff pretty closely related to my
issue, so I hadn't given much thought to the new StringTokenizer replacement
-- perhaps I felt it was a little too new for me to be adding even more new
stuff. Whoever wants to is welcome to incorporate this new method there, if
it gets committed to StringUtils at all in the first place.
Al
--- Arun Thomas [EMAIL PROTECTED] wrote:
I also know that this is more than you intended, but any thought of
incorporating the split on string into the new StringTokenizer
replacement
as
well? I think that would be pretty useful. (It's behaviour in two
places,
but implementation could certainly delegate)
-AMT
-Original Message-
From: Al Chou [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2003 10:22 PM
To: Jakarta Commons Developers List
Subject: [lang] unexpected StringUtils.split behavior (was RE: suggestion
for
new StringUtils.method)
I guess my previous post got lost in the noise, so I'm reposting. I
have
two
new StringUtils.split methods that can split a string at occurrences
of a substring rather than splitting at the individual characters in
the
specified
delimiter string.
While testing, I discovered that my expectations for the behavior of
the split( *, ..., int max ) methods didn't match their actual
behavior. I expected to get a maximum of max substrings, all of
which were delimited
in
the parent string by the specified delimiters. Instead, what you get
is
max
- 1 such substrings, plus the rest of the parent string as the final
result
substring.
This behavior seems counter to what StringTokenizer would do, which is
surprising, given the Javadoc comments about using the split methods as
alternatives to StringTokenizer.
Currently, my tests reflect my expectations for the behavior, and I
modified
the existing split( String, String, int ) method to match my
expectations.
I
didn't want to submit such a change as a proposed patch without first
getting
feedback from the community about whether my expectations are wrong.
I am happy to submit only code that does not change the behavior of
the
existing
methods, if need be.
Al
--- Al Chou [EMAIL PROTECTED] wrote:
This thread is a good entree for my question. I was adding a new
StringUtils.split method that can split a string using a whole string
as the delimiter, rather than the characters within that string. In
running my JUnit tests, I discovered unexpected behavior in the
existing method:
String stringToSplitOnNulls = ab de fg ;
String[] splitOnNullExpectedResults = { ab, de } ;
String[] splitOnNullResults = StringUtils.split(
stringToSplitOnNulls,
null, 2
) ;
assertEquals( splitOnNullExpectedResults.length,
splitOnNullResults.length ) ; for ( int i = 0 ; i
splitOnNullExpectedResults.length ; i+= 1 ) {
assertEquals(
cvs commit: jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/generator/util MaxIterations.java
rwaldhoff2003/11/24 16:23:14 Modified:functor/src/java/org/apache/commons/functor/generator/util MaxIterations.java Log: deprecate MaxIterations Revision ChangesPath 1.2 +3 -2 jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/generator/util/MaxIterations.java Index: MaxIterations.java === RCS file: /home/cvs/jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/generator/util/MaxIterations.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- MaxIterations.java30 Jun 2003 11:00:13 - 1.1 +++ MaxIterations.java25 Nov 2003 00:23:14 - 1.2 @@ -69,6 +69,7 @@ * Would only generate 1 line from the file. * * @since 1.0 + * @deprecated See Limit and Offset * @version $Revision$ $Date$ * @author Jason Horman ([EMAIL PROTECTED]) */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
