Re: [Collections] [SUBMIT] Trie

> Would it be useful to have a trie that would index on the tail ends of > strings in reverse, for supporting quick searches for stuff 'ending in'? > > Are there any situations where it would be valuable to index on all > n-to-last-character subsequences of entries, or would the overhead just > be

[Jelly] JellyServlet

A simple implementation modelled after VelocityServlet. Regards, Kelvin JellyServlet.java Description: Binary data -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: [Collections] [SUBMIT] Trie

Yes, I definitely think a trie implementation is a good thing to have. I can see myself maybe using it on a project coming up. I am interested in gauging the relative performance of the first cut that was submitted vs. a purely String-oriented trie. It seems to me from poking around the Web t

Re: [Collections] [SUBMIT] Trie

FWIW, there are at least two Jakarta products that I'm involved in (Tomcat and Struts) that have exactly the path-mapping use case that was described for the Trie class. And, conveniently, they both already dependd on [collections] so it would be very convenient to have Trie added here. It will b

[Collections] [SUBMIT] Unmodifiable iterators

Hi This patch adds two methods to IteratorUtils which return unmodifiable views of iterators. One wraps an Iterator, the other a ListIterator. These methods are analogues to the methods for collections in the java.util.Collections class. Rich unmodifiable-iterators.patch.gz Description: appl

cvs commit: jakarta-commons-sandbox/clazz/src/java/org/apache/commons/clazz/reflect/standard - New directory

dmitri 2002/12/05 17:06:21 jakarta-commons-sandbox/clazz/src/java/org/apache/commons/clazz/reflect/standard - New directory -- To unsubscribe, e-mail: For additional commands, e-mail:

cvs commit: jakarta-commons-sandbox/clazz/src/java/org/apache/commons/clazz/reflect/common - New directory

dmitri 2002/12/05 17:06:16 jakarta-commons-sandbox/clazz/src/java/org/apache/commons/clazz/reflect/common - New directory -- To unsubscribe, e-mail: For additional commands, e-mail:

cvs commit: jakarta-commons-sandbox/clazz/src/java/org/apache/commons/clazz/reflect/extended - New directory

dmitri 2002/12/05 17:06:19 jakarta-commons-sandbox/clazz/src/java/org/apache/commons/clazz/reflect/extended - New directory -- To unsubscribe, e-mail: For additional commands, e-mail:

cvs commit: jakarta-commons-sandbox/clazz/src/java/org/apache/commons/clazz/common - New directory

dmitri 2002/12/05 17:06:11 jakarta-commons-sandbox/clazz/src/java/org/apache/commons/clazz/common - New directory -- To unsubscribe, e-mail: For additional commands, e-mail:

cvs commit: jakarta-commons-sandbox/clazz/src/java/org/apache/commons/clazz/bean - New directory

dmitri 2002/12/05 17:06:07 jakarta-commons-sandbox/clazz/src/java/org/apache/commons/clazz/bean - New directory -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: [Jelly] demo:jellyunit error: Ant Filtersets

James Strachan - thank you! Today I found out from Bob that using ant 1.5.1 in a Maven plugin was not possible unless Maven's dependency went to 1.5.1. So it turns out I was always using Ant 1.5 So I tried 1.5.1 and it works like a charm. My plugin that is with the filtersets. Thanks so much. I'

DO NOT REPLY [Bug 15128] New: - Tests cannot handle immutable lists

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

DO NOT REPLY [Bug 15127] New: - Tests should explicit about checking serialization

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

[Jelly] demo:jellyunit error: Ant Filtersets

Hi, I tried the recent test cases added re: Ant filtersets. I still have the same problems.:( Here is a piece of the demo:jellyunit goal: [java] [INFO] InfoTag - -The exception was: This should always fail. Assertion failed while evaluating xpath: $:docchild::foo/child::xyz File: file:/D:/cygwin

DO NOT REPLY [Bug 15123] New: - Incorrect stack trace shown when abandoned connections are closed

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: [beanutils] ConstructorUtils in beanutils: a bad idea

On Thursday, December 5, 2002, at 10:49 PM, Costin Manolache wrote: I'm not sure I understand what is proposed :-) it's the same old proposal. discussed at length a long time ago. have only one canonical set of basic reflection code that's easy to maintain and bug fix. However I'm strongly -

[digester] default for useThreadClassLoader

Is there any reason for having 'false' for useThreadClassLoader ? I have a number of failures with tomcat if digester is in the parent loader, since a lot of code doesn't set this. And IMO the correct behavior for any utility designed to work in a server side environment is to check the thread

Re: [beanutils] moving reflection classes out of beanutils

On Thursday, December 5, 2002, at 08:39 PM, Morgan Delagrange wrote: --- robert burrell donkin <[EMAIL PROTECTED]> wrote: rodney hasn't been a regular contributor to beanutils either in terms of code or on the mailing lists. if he couldn't even be bothered to ask before making himself a commi

Re: [beanutils] ConstructorUtils in beanutils: a bad idea

I'm not sure I understand what is proposed :-) However I'm strongly -1 on removing ( or deprecating ) public code in beanutils, or on adding more dependencies. It works fine and if another package wants to do reflection - that's perfectly fine, but that doesn't mean everyone else is required to s

Re: [Collections] [SUBMIT] Trie

I am reluctantly minded to not include Trie in [collections] Unfortunately, at present I am the only active committer for [collections]. This means that I am unable to get feedback from other committers (who know collections in more detail than I). My decision is based on a feeling that different

Re: cvs commit: jakarta-commons-sandbox/attributes build.xml

[EMAIL PROTECTED] wrote on 06/12/2002 06:58:34 AM: > jstrachan2002/12/05 11:58:34 > > Modified:attributes build.xml > Log: > added an autogenerated build.xml [snip] > - > + James, we really need to do a relative file tag for jelly and start using it in maven :

Re: [general] lang scope?

The [lang] implementations do not depend on [collections], but they do depend on java.util.collections. This seems perfectly OK to me. Cyclic dependencies should be avoided. Stephen - Original Message - From: "Tom Drake" <[EMAIL PROTECTED]> > Yes, it would be the implementations (in [lang

Re: [lang] MethodUtils method naming

I thought this was just going to be getMethod()? With your changes how many names do we need? I thought there were just two: - normal (getMethod ?) - ignoring scope (getMethodIgnoringScope ???) Stephen - Original Message - From: "robert burrell donkin" <[EMAIL PROTECTED]> To: "Jakart

RE: [general] lang scope?

Yes, it would be the implementations (in [lang][functor] that would want to use [collections]. And the implementation classes and interfaces in [collections] would, by definition depend on [lang][functor]. -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED]] Sent: T

[core] Scope, you choose!

Here are the tasks currently/planned for 'core' commons components, by which I mean [lang], [util], [beanutils], [io], [util], ('pattern' no longer exists). The project is the current location. String/number/object manipulation [lang] Exception manipulation [lang] Collections [collections] Iterato

Re: [collections][lang] Predicate etc impls, was Re: commons-collections: New code contribution.

From: "Tom Drake" <[EMAIL PROTECTED]> > Thanks for the note. Functors seems to contain many of the things that I've > also created. > I'll look more closely at this, factor out the overlap. May I send you a zip > file with the > remaining classes? Of course, please submit ideas/patches to the list.

Re: [collections] private member access in o.a.c.collections.iterators

Perhaps you would like to send a patch for ArrayIterator. http://jakarta.apache.org/site/source.html#Patches Also, an ArrayListIterator would be very welcome for the iterators package. If you are writing it, perhaps you would consider submitting it together with the associated patch to IteratorUti

Re: moving reflection classes out of beanutils (was: Re: [beanutils]ConstructorUtils in beanutils: a bad idea)

On Thu, 5 Dec 2002, robert burrell donkin wrote: > i only threatened to -1 after trying quite a few times to get rodney to > discuss his commit. I'm not interested in starting some sort of flame war on this minor point, but for the record, I saw exactly two emails on this--one directly to my apac

Re: [beanutils] moving reflection classes out of beanutils (was: Re: [beanutils] ConstructorUtils in beanutils: a bad idea)

--- robert burrell donkin <[EMAIL PROTECTED]> wrote: > On Thursday, December 5, 2002, at 07:20 PM, Morgan > Delagrange wrote: > > > So it seems like the point is not > "ConstructorUtils in > > beanutils: a bad idea", but rather "Reflection > classes > > in beanutils: a bad idea". It's inappropr

[lang] MethodUtils method naming

in beanutils, methods called 'getAccessibleMethod' (or variations) are used to get methods which can safely be called through reflection. this seems a little at odds with the use of the term 'accessible' in the java.lang.reflect which means that the object suppresses the standard java access ru

Re: moving reflection classes out of beanutils (was: Re: [beanutils] ConstructorUtils in beanutils: a bad idea)

On Thursday, December 5, 2002, at 07:20 PM, Morgan Delagrange wrote: So it seems like the point is not "ConstructorUtils in beanutils: a bad idea", but rather "Reflection classes in beanutils: a bad idea". It's inappropriate to -1 adding ConstructorUtils to beanutils on the basis of scope, sinc

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

jstrachan2002/12/05 11:58:34 Modified:attributes build.xml Log: added an autogenerated build.xml Revision ChangesPath 1.2 +5 -3 jakarta-commons-sandbox/attributes/build.xml Index: build.xml

Re: [general] lang scope?

On Thursday, December 5, 2002, at 06:35 PM, Tom Drake wrote: It sounds like I've jumped into a bit of a hornets nest. this is actually pretty tame :) but it's too late to jump of the frying pan... I was thinking this morning that such a move will run a high risk of creating a circular depend

[collections] private member access in o.a.c.collections.iterators

Hi, I've been using the o.a.c.collections packages for a few months, and I want to applaud you guys for some fantastic work. I do have a question: forgive me if this has been discussed before (though I couldn't find it in the mail archive), but is there a particular reason why the member variabl

moving reflection classes out of beanutils (was: Re: [beanutils] ConstructorUtils in beanutils: a bad idea)

So it seems like the point is not "ConstructorUtils in beanutils: a bad idea", but rather "Reflection classes in beanutils: a bad idea". It's inappropriate to -1 adding ConstructorUtils to beanutils on the basis of scope, since that is where such classes currently belong. If you want to move ref

Re: [beanutils] ConstructorUtils in beanutils: a bad idea

On Thursday, December 5, 2002, at 03:25 PM, Rodney Waldhoff wrote: Looking through the archives, I now see the thread named "[beanutils][lang][PROPOSAL] deprecated beanutils version of MethodUtils" [1] which apparently should have been flagged "[VOTE]", if that was intended to be a binding vote

RE: [general] lang scope? (was Re: [collections][lang] Predicate etc impls, was Re: commons-collections: New code contribution.)

It sounds like I've jumped into a bit of a hornets nest. I was thinking this morning that such a move will run a high risk of creating a circular dependancy between [collections] and [lang][functor]. It seems likely that functors would want to use collection objects and vice-versa. If I'm right ab

[general] lang scope? (was Re: [collections][lang] Predicate etcimpls, was Re: commons-collections: New code contribution.)

On Thu, 5 Dec 2002 [EMAIL PROTECTED] wrote: > The plan is to make [collections] depend on [lang] and deprecate the > Predicate etc. interfaces in [collections]. At the risk of becoming increasingly unpopular with the lang folks, for reasons similiar to those I enumerated in [1] (and others), I'm

Re: [Collections] [SUBMIT] Trie

- Original Message - From: "Stephen Colebourne" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Thursday, December 05, 2002 12:13 AM Subject: Re: [Collections] [SUBMIT] Trie > Hi, > I've taken a quick look at the code here, and that all looks fine. > >

Re: [collections][lang] Predicate etc impls, was Re: commons-collections: New code contribution.

Stephen: Thanks for the note. Functors seems to contain many of the things that I've also created. I'll look more closely at this, factor out the overlap. May I send you a zip file with the remaining classes? BTW, what timeframe is this package refactoring of the collections patterns slated for?

Re: [beanutils] ConstructorUtils in beanutils: a bad idea

I did recall seeing some threads around lang/beanutils/reflection/clazz, indeed before I wrote ConstructorUtils I checked those places for the functionality I was looking for. Lang's ConstructorUtil class wasn't quite it, and the last commit message reads "[...] (not all working)", which wasn't exa

RE: [jelly] Subclassing JellyContext

James, thanks for the pointer re createChildContext(). I am not clear what the scoping refactoring you refer to means exactly, even after reading the link you sent ;-) But never mind. My scoping requirements are to be able to have a variable value visible only to its children. Maybe this is s

Re: [jelly] Subclassing JellyContext

There's a factory method, createChildContext() which you can override to create your own context... public class MyContext extends JellyContext { public MyContext(JellyContext parent) { super(parent); } protected JellyContext createChildContext() { return new MyContex

[jelly] Subclassing JellyContext

Hi, Is there any way I can override the creation of JellyContext instances so I can put in my own subclass? Thanks, Mike. -- To unsubscribe, e-mail: For additional commands, e-mail:

[collections][lang] Predicate etc impls, was Re: commons-collections: New code contribution.

[please note the square brackets in the title ;-)] This has been a hot topic before in commons. The current position is that there is a large body of code such as what you suggest already coded. It resides in [lang]s functor package (not released yet). However, the classes use a different Predic

commons-collections: New code contribution.

I'm new to this list, but have worked with the commons-collections package for quite a while. I recently came off a project that implemented a simple but powerful rules engine based on three interfaces that were essentially identical to the Predicate, Closure, and Transformer interfaces. I've buil

Re: [configuration] XmlConfiguration

Please see attached. Kelvin On Thu, 05 Dec 2002 08:42:16 +0100, Martin Poeschl said: >Kelvin Tan wrote: > >>I've noticed XmlConfiguration to be unimplemented for awhile now. >>Is there any intention to do something about it? >> >>I have a basic implementation using dom4j and am willing to >>contr

Re: [configuration] XmlConfiguration

Kelvin Tan wrote: On Wed, 04 Dec 2002 14:25:10 +0100, Nicola Ken Barozzi said: In the Ant codebase, in the proposals/embed dir, ther is a task that uses jxpath for configuration. JXPath can make use of more things than just XML, and is thus much more flexible, and has xpath support. I'd take a