[collections] [patch] NodeCachingLinkedList

(I'm reposting this, since I sent the original over eight hours ago and it hasn't shown up here. Apologies if you get it twice.) Hi Here is a patch to resolve the license issues with NodeCachingLinkedList. Included in this patch is: - CommonsLinkedList, a version of java.util.LinkedList that we

Re: [functor] draft proposal

On Fri, 13 Dec 2002, Rodney Waldhoff wrote: > In part of the discussion of his recent proposal, Stephen Coleburn wrote: > > > I am trying to move forward _now_. Creating > > [functor] would involve a sandbox project, > > moving the code again (effectively > > recreating [pattern]), a strong poss

cvs commit: jakarta-commons-sandbox/clazz build.xml

dmitri 2002/12/13 18:37:43 Modified:clazzbuild.xml Log: Fixed up the build script Revision ChangesPath 1.2 +163 -66 jakarta-commons-sandbox/clazz/build.xml Index: build.xml === RCS file:

Re: [lang] Has anyone thought about a TimeUtils package?

Please be warned, that Date is a fragile/controversial issue, since 1. The java SimpleDateFormatter is not thread safe 2. Dates have many locale specific representation. Indeed, Sun's dates are pretty rubbish. Joda has a 0.8 release, which has thread safe formatting including time zone hand

Re: [lang] Has anyone thought about a TimeUtils package?

I agree that simple time/date utilities would belong in commons/lang as opposed to a larger project like joda. This is infact what I had in mind. I will also keep in mind the potential controversey as suggested. Here are a few scenarios that I'd like to throw out there as possibly being gener

[functor] draft proposal

In part of the discussion of his recent proposal, Stephen Coleburn wrote: > I am trying to move forward _now_. Creating > [functor] would involve a sandbox project, > moving the code again (effectively > recreating [pattern]), a strong possibility > of a one-man project, thus no possibility > of p

Re: [lang] Validate.java

I have checked this in with some additions, javadoc changes and tests. Thanks Stephen - Original Message - From: "Ola Berg" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Monday, November 25, 2002 1:42 PM Subject: [lang] Validate.java By the way, I p

Re: [lang] Has anyone thought about a TimeUtils package?

I agree that simple time/date utilities would belong in commons/lang as opposed to a larger project like joda. This is infact what I had in mind. I will also keep in mind the potential controversey as suggested. Here are a few scenarios that I'd like to throw out there as possibly being general

RE: [VOTE][collections] Functors, dependency from collections to lang

While not a commiter, I heartily agree! -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED]] Sent: Friday, December 13, 2002 7:04 AM To: Jakarta Commons Developers List Subject: [VOTE][collections] Functors, dependency from collections to lang Proposal: a) Add dependenc

RE: [collections][patch] ClassFilterIterator

I've already submitted an OrPredicate and an InstanceOfPredicate -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED]] Sent: Friday, December 13, 2002 4:29 AM To: Jakarta Commons Developers List Subject: Re: [collections][patch] ClassFilterIterator I intend to get a reso

RE: [VOTE][collections] Functors, dependency from collections to lang

This issue is that [collections] is in wide use. Stephens proposal allows all existing applications to use the future releases (of [commons]) without code change, only requiring that commons-lang.jar be added as a dependency. This is especially important if your application depends on third party s

cvs commit: jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/xml suite.jelly

jstrachan2002/12/13 10:08:31 Modified:jelly/src/java/org/apache/commons/jelly/tags/xml XMLTagLibrary.java jelly/src/test/org/apache/commons/jelly/xml suite.jelly Added: jelly/src/java/org/apache/commons/jelly/tags/xml

Re: [VOTE][collections] Functors, dependency from collections tolang

Rodney Waldhoff wrote: On Fri, 13 Dec 2002, Emmanuel Bourg wrote: Clearly the intention behind deprecating a method or class is to remove it. (i) deprecating (with the intention of removing) released classes The intention is to no longer use it. It *may* be removed at a later date, but that

cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang Validate.java

scolebourne2002/12/13 09:21:57 Modified:lang/src/test/org/apache/commons/lang LangTestSuite.java Added: lang/src/test/org/apache/commons/lang ValidateTest.java lang/src/java/org/apache/commons/lang Validate.java Log: Add Validate class for argument validation

RE: [lang] Has anyone thought about a TimeUtils package?

I would definitly like to help actually.. I am going to be doing more work with date and times in the future, so getting started on something would be great. Eric -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED]] Sent: Friday, December 13, 2002 10:52 AM To: Jakarta Com

cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging LogFactory.java

rsitze 2002/12/13 08:55:39 Modified:logging/src/java/org/apache/commons/logging LogFactory.java Log: Oops.. almost broke type check via typecast! Revision ChangesPath 1.18 +10 -5 jakarta-commons/logging/src/java/org/apache/commons/logging/LogFactory.java I

cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging LogFactory.java

rsitze 2002/12/13 08:48:06 Modified:logging/src/java/org/apache/commons/logging LogFactory.java Log: More doPriv's around ClassLoader.loadClass and Class.forName Revision ChangesPath 1.17 +48 -39 jakarta-commons/logging/src/java/org/apache/commons/logging/LogFac

Re: [lang] Has anyone thought about a TimeUtils package?

> Seems that Stephen has taken another approach to this (see the posts > in this thread). Maybe someone takes a look to see if the two versions > in rupert can be explited and deprecated in favor of CalendarUtils > or joda. Parts of these classes could be deprecated to Joda, but Joda is much bigger

cvs commit: jakarta-commons/discovery/src/java/org/apache/commons/discovery ResourceClass.java

rsitze 2002/12/13 08:43:37 Modified:discovery/src/java/org/apache/commons/discovery ResourceClass.java Log: More doPriv's around ClassLoader.loadClass. Revision ChangesPath 1.5 +12 -5 jakarta-commons/discovery/src/java/org/apache/common

[VALIDATOR] funny build.xml ?

Hello, Maybe this was reported before, but the build.xml in the source distribution for Validator 1.0 funnied on me. From last night's nightly: # ant -projecthelp Buildfile: build.xml Main targets: all Clean and compile all components cleanClean build and distribution

Re: [VOTE][collections] Functors, dependency from collections tolang

On Fri, 13 Dec 2002, Emmanuel Bourg wrote: > Rodney Waldhoff wrote: > > On Fri, 13 Dec 2002, Stephen Colebourne wrote: > > I think this proposal would be more accurately considered a product change > > (it removes public classes from a released component and adds a new > > dependency to a release

Re: [lang] Has anyone thought about a TimeUtils package?

Hi, an first hit at this in the commons land was in: http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/rupert/src/java/org/apache/commons/rupert/christoph/IsoDateTool.java?rev=HEAD http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/rupert/src/java/org/apache/commons/rupert/nathan/DateTool.j

Re: [VOTE][collections] Functors, dependency from collections tolang

Rodney Waldhoff wrote: On Fri, 13 Dec 2002, Stephen Colebourne wrote: I think this proposal would be more accurately considered a product change (it removes public classes from a released component and adds a new dependency to a released component, arguably it changes the scope of two released com

DO NOT REPLY [Bug 15339] - StackObjectPool needs to ensure available objects in pool are unique

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Comment on [VOTE][collections] Functors, dependency fromcollections to lang

On Fri, 13 Dec 2002, Stephen Colebourne wrote: > > I think this proposal would be more accurately considered a product change > > (it removes public classes from a released component and adds a new > > dependency to a released component, arguably it changes the scope of two > > released componen

Re: [lang] Has anyone thought about a TimeUtils package?

Stephen Colebourne wrote: There is a CalendarUtils class already in the [lang-sandbox] that you might want to look at. Will do. I will report back after I take a look at what's there in the sandbox. Thanks for the tip. (Also I will be checking out your site for the joda stuff.) Eric, I

Re: [lang] Has anyone thought about a TimeUtils package?

There is a CalendarUtils class already in the [lang-sandbox] that you might want to look at. http://joda.sourceforge.net is where I have quite an extensive time/date rewrite project underway. But we'll always take a look at ideas. Simple utils for java dates and times probably fit in [lang], more

Re: [lang] Has anyone thought about a TimeUtils package?

Oh, welcome to the party by the way :) On Fri, 13 Dec 2002, Sean Schofield wrote: > Greetings. > > I'm new to the commons-dev list and I've been throwing out ideas of > where I might be able to make my first open source contribution. > > Has anyone thought about a possible TimeUtils package with

Re: [lang] Has anyone thought about a TimeUtils package?

Stephen's our expert here as his joda project has an extensive time system in. There is a TImeUtils/CalendarUtils idea floating around a bit, but it needs to remain simple and not grow into a large system [which by experience, Stephen has shown us can happen]. But feel free to throw in the ideas,

RE: [lang] Has anyone thought about a TimeUtils package?

I was looking at the various DateUtils in ant.. And I think that something that pulled in Time, Date, and Calendar Utils would be great.. Eric Pugh -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED]] Sent: Friday, December 13, 2002 10:28 AM To: [EMAIL PROTECTED] Subject: [

[lang] Has anyone thought about a TimeUtils package?

Greetings. I'm new to the commons-dev list and I've been throwing out ideas of where I might be able to make my first open source contribution. Has anyone thought about a possible TimeUtils package with commons.lang? There a variety of time-related utilities that I've been working on that migh

Re: [VOTE][collections] Functors, dependency from collections to lang

> Proposal: > a) Add dependency from [collections] to [lang] > b) Deprecate the existing functor classes in [collections] > c) Make the existing functor classes in [collections] extend those in [lang] > for easy upgrading > > The functor code (Predicate et al), currently resides in [lang]. It conta

Re: [VOTE][collections] Functors, dependency from collections tolang

On Fri, 13 Dec 2002, Stephen Colebourne wrote: > Proposal: > a) Add dependency from [collections] to [lang] > b) Deprecate the existing functor classes in [collections] > c) Make the existing functor classes in [collections] extend those in [lang] > for easy upgrading > > +1 [ X ] I support thi

[VOTE][collections] Functors, dependency from collections to lang

Proposal: a) Add dependency from [collections] to [lang] b) Deprecate the existing functor classes in [collections] c) Make the existing functor classes in [collections] extend those in [lang] for easy upgrading The functor code (Predicate et al), currently resides in [lang]. It contains about 50

Re: [logging] Adding jndi java:env support

At 22:44 12.12.2002 -0800, you wrote: Craig R. McClanahan wrote: > I'm neutral on prefix versus suffix (although prefix feels a little more > in keeping with the hierarchical naming I tend to use for logging). But > that raises an important consideration -- do the underlying logging > implementa

Re: [collections][lang] Functors, pre-vote

> Your argument makes perfect sense, except that [lang] also wants to be the > lowest level, no dependency library. This is why functors are could reside > in [lang], so this kind of cross dependency isn't an issue. I am in favor of functors belonging in lang, _but_ if that makes [collection] and

[GUMP] Build Failure - commons-email

This email is autogenerated from the output from: Buildfile: build-gump.xml jar: [mkdir] Created dir: /home/rubys/jakart

Re: [collections][patch] ClassFilterIterator

I intend to get a resolution on the functors question, as it is clearly holding things up ;-) The approach taken to functors in general is to have lots of small functors. With your example, rather than having one predicate that receives an array of classes to check, I would probably favour one pre

Re: [collections] [patch] changes for ArrayListIterator was: Re: [collections] private member access in o.a.c.collections.iterators

Patch used to extend array iterators in general, thanks. Take a look - we now have: ArrayIterator ArrayListIterator ObjectArrayIterator ObjectArrayListIterator The first two support primitives, but with a performance penalty. The latter two don't, so run faster. Comments welcome. Stephen -

cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/iterators TestArrayListIterator2.java TestArrayListIterator.java TestObjectArrayListIterator.java TestObjectArrayIterator.java TestArrayIterator2.java TestAll.java TestArrayIterator.java

scolebourne2002/12/13 04:10:48 Modified:collections/src/test/org/apache/commons/collections/iterators TestArrayIterator2.java TestAll.java TestArrayIterator.java Added: collections/src/test/org/apache/commons/collections/iterators

cvs commit: jakarta-commons/collections STATUS.html

scolebourne2002/12/13 04:04:17 Modified:collections STATUS.html Log: Rework array iterators to include Iterator and ListIterator implementations. Also add Object array versions for better performance. Revision ChangesPath 1.22 +5 -2 jakarta-commons/collection

cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/iterators TestIterator.java

scolebourne2002/12/13 04:03:46 Modified:collections/src/test/org/apache/commons/collections/iterators TestIterator.java Log: Add test for remove on an iterator Revision ChangesPath 1.2 +52 -16 jakarta-commons/collections/src/test/org/apac

cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/iterators TestSingletonListIterator.java TestSingletonIterator.java TestFilterIterator.java

scolebourne2002/12/13 04:03:06 Modified:collections/src/test/org/apache/commons/collections/iterators TestSingletonListIterator.java TestSingletonIterator.java TestFilterIterator.java Log: Add method to indicate that iterator doesn't su

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections IteratorUtils.java

scolebourne2002/12/13 04:01:58 Modified:collections/src/java/org/apache/commons/collections IteratorUtils.java Log: Rework array iterators to include Iterator and ListIterator implementations. Also add Object array versions for better performance. Revi

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/iterators ArrayListIterator.java ObjectArrayListIterator.java ObjectArrayIterator.java ArrayIterator.java

scolebourne2002/12/13 04:01:36 Modified:collections/src/java/org/apache/commons/collections/iterators ArrayIterator.java Added: collections/src/java/org/apache/commons/collections/iterators ArrayListIterator.java ObjectArrayListIter

Re: [collections][patch] ClassFilterIterator

This is a modified version of my previous ClassFilterIterator with a little more meat : - it accepts an array of classes to match several classes - the class matching can optionnaly be "strict", that is subclasses of the required class aren't returned. In strict mode a ClassFilterIterator will o

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/iterators CollatingIterator.java

scolebourne2002/12/13 03:03:42 Modified:collections/src/java/org/apache/commons/collections/iterators CollatingIterator.java Log: Fix remove method to throw correct exception Revision ChangesPath 1.4 +5 -5 jakarta-commons/collections/sr

Re: [collections][lang] Functors, pre-vote

Your argument makes perfect sense, except that [lang] also wants to be the lowest level, no dependency library. This is why functors are could reside in [lang], so this kind of cross dependency isn't an issue. I agree that bean based functors would sit in [beanutils], and io based functors in [io]

[jelly] Regexp ?

Hi, I'm trying to set variables with a Perl5 regexp pattern, such as : This doesn't want to work and always returns 0 (zero). This probably comes from the {} and $ that are inside the regexp. Is there a way to disable Jelly evaluation before setting the variable, so that it would be sent 'as

[jelly] Regexp ?

Hi, I'm trying to set variables with a Perl5 regexp pattern, such as : This doesn't want to work and always returns 0 (zero). This probably comes from the {} and $ that are inside the regexp. Is there a way to disable Jelly evaluation before setting the variable, so that it would be sent 'as

cvs commit: jakarta-commons/validator RELEASE-NOTES.txt

turner 2002/12/13 00:12:51 Modified:validator RELEASE-NOTES.txt Log: Release notes for 1.01 release Revision ChangesPath 1.2 +12 -12jakarta-commons/validator/RELEASE-NOTES.txt Index: RELEASE-NOTES.txt =