cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator ValidatorResult.java

martinc 2002/12/12 23:54:10 Modified:validator/src/share/org/apache/commons/validator ValidatorResult.java Log: Make ValidatorResult$ResultStatus serializable. The onus is therefore on the Validator client to ensure that result classes are serializable.

Re: [logging] Adding jndi java:env support

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 > implementations we support deal gracefully with a

Re: [jelly] [latka] Plugin for Maven

Morgan Delagrange <[EMAIL PROTECTED]> wrote on 13/12/2002 03:44:26 AM: > This is pretty cool. I assume it uses the latest, > Jelly-driven version of Latka? The new code seems > pretty stable, but it could use more testing. :) Yep, using a snapshot of Latka I built when I made the plugin. There

DO NOT REPLY [Bug 14384] - ValidatorResources.get-method not working properly

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 15345] - Validator incorrectly searching formsets by locale

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 15257] - Hierarchy support in ToStringBuilder.reflectionToString()

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 15257] - Hierarchy support in ToStringBuilder.reflectionToString()

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 15345] - Validator incorrectly searching formsets by locale

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 15345] New: - Validator not formsets by locale

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: [logging] Adding jndi java:env support

On Thu, 12 Dec 2002, Costin Manolache wrote: > Date: Thu, 12 Dec 2002 13:29:51 -0800 > From: Costin Manolache <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [logging] Adding jndi java:env support > > The big issue is the

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

I think we agree on just about everything, excepting dependancies between [functor] and [lang]. I'm not very familiar with the scope of [lang] so take my comments with a grain of salt. My point is that [functor] (defined as having no dependancies on any other apache project) represents a set o

Re: [digester] i'd like to contribute - here's my new feature idea

I don't want to squash Sean's enthusiasm, but I don't yet understand the need for this modification. Don't worry about my enthusiasm. I'm just throwing this out as an idea. I can take thoughtful criticism. If we nix this idea, I have some other ideas that I could contribute (eventually folks

DO NOT REPLY [Bug 14981] - getNumActive() count is wrong when returnObject() is used to pre-populate StackObjectPool

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 14983] - GenericObjectPool should allow for manual population of the pool

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 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

DO NOT REPLY [Bug 14982] - GenericObjectPool does not work with null factory.

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: [digester] i'd like to contribute - here's my new feature idea

by all means, submit a patch. but i'd prefer an attribute name to be passed in rather than using the first attribute. (i have a feeling that the order of attributes can be parser dependent.) when the attribute name isn't present, then just don't create anything. since ObjectCreateRule already h

DO NOT REPLY [Bug 15339] New: - 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: [digester] i'd like to contribute - here's my new feature idea

hi sean by all means, submit a patch. but i'd prefer an attribute name to be passed in rather than using the first attribute. (i have a feeling that the order of attributes can be parser dependent.) when the attribute name isn't present, then just don't create anything. since ObjectCreateRule

cvs commit: jakarta-commons/discovery/src/testAlt1 - New directory

rsitze 2002/12/12 14:35:36 jakarta-commons/discovery/src/testAlt1 - New directory -- To unsubscribe, e-mail: For additional commands, e-mail:

cvs commit: jakarta-commons/discovery/src/test testResource

rsitze 2002/12/12 14:35:40 Modified:discovery/src/test/org/apache/commons/discovery/test TestAll.java discovery build.xml discovery/sandbox/java/org/apache/commons/discovery/jdk JDK11Hooks.java JDK12Hooks.java

cvs commit: jakarta-commons/discovery/src/testAlt2 - New directory

rsitze 2002/12/12 14:35:36 jakarta-commons/discovery/src/testAlt2 - New directory -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: [logging] Adding jndi java:env support

The big issue is the behavior. My proposal was: if java:env/comp/LoggingDomain is set ( as a String ), it'll be used as a prefix in all loggers ( that don't have a prefix ). The syntax for the logger names will become: DOMAIN:LOGGER And all loggers will have to be configured with this name (

Re: [logging] Adding jndi java:env support

Craig R. McClanahan wrote: > > > On Wed, 11 Dec 2002, Costin Manolache wrote: > >> >> The big downsize is that we'll add a compile dependency on >> JNDI ( the code can catch ClassNotFound - and run even if >> JNDI is not present ). >> > > Why couldn't we use reflection to avoid the compile-tim

Re: [digester] i'd like to contribute - here's my new feature idea

So what if I wrote a patch to deal with this limitation (I described such a patch in an earlier reply but it didn't seem to make it to the list). The patch would be as follows: - Add a no-argument constructor to ObjectCreateRule - Modify the begin() method of ObjectCreateRule so that if there i

Re: [digester] i'd like to contribute - here's my new feature idea

On Thursday, December 12, 2002, at 07:59 PM, Sean Schofield wrote: All, Is this the correct newsgroup (just in case this wasn't a typo and that you weren't aware of the point - this is really a mailing list. some helpful people elsewhere mirror it into news.) for me to be raising these ki

Re: [logging] Adding jndi java:env support

I'll wait for the formal call to vote before I start voting, BUT I support the following: + release a 1.0.3 before any major code changes + JNDI - NO API changes - NO new runtime dependencies, and I'd like to be able to build, even if I cannot test it. ***

DO NOT REPLY [Bug 15331] - getResourceAsStream access permissions in J2EE environs

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

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

rsitze 2002/12/12 12:29:16 Modified:logging/src/java/org/apache/commons/logging LogFactory.java logging/src/java/org/apache/commons/logging/impl SimpleLog.java Log: Fix getResourceAsStream security violations with doPriv. Revision Changes

DO NOT REPLY [Bug 15331] New: - getResourceAsStream access permissions in J2EE environs

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

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

rsitze 2002/12/12 11:23:34 Modified:logging/src/java/org/apache/commons/logging/impl SimpleLog.java Log: 1. Wrapped System.getProperties with doPrivileged. 2. Moved catch. If System properties cannot be loaded, then don't abandon effort, but go on

Re: [logging] Adding jndi java:env support

sounds like a good plan. this sounds (to me) like a change big enough to call for a new (major?) version. (i'm not a cvs expert) but from what i can see there have been some small changes since the last release. maybe a quick bugfix 1.0.3 release would be a good idea before adding making this

Re: JNDI based selection

Ceki Gülcü wrote: > OK, the solution I presented solves the "VOLUNTATRY separation of > logging" problem. It can be further refined to address the > "MANDATORY separation of logging" problem Costin mentions. > Costin suggested the use of string prefixes to enforce mandatory > separation which is

Re: [codec] Re: DoubleMetaphone

formatting looks close enough to me :) (whoever commits should probably go through the code and correct any small problems anyway.) since this is a (reasonably) significant donation of code for which versions with other copyright already exist, we should probably check with the foundation to m

Re: JNDI based selection

Costin Manolache wrote: > One comment: application isolation is not a voluntary thing. If we > want to isolate the loggers you can't allow the application to specify > what logger it wants in web.xml and hope they'll not use the same > name. OK, the solution I presented solves the "VOLUNTATRY se

RE: [DBCP] Building the DBCP jarfile

On Thu, 12 Dec 2002, Martin van Dijken wrote: > Everything works peachy now, except for 13 deprecated warnings:) The DelegatingXXX classes in DBCP override also delegate the deprecated methods of XXX, for example: class DelegatingPreparedStatement extends PreparedStatement { /** @deprecated */

[digester] i'd like to contribute - here's my new feature idea

Greetings, I have been using the great software developed by the jakarta team for some time now. I have found it very useful and I would like to contribute something. I'd like to start with the commons digester and I have a specific idea. Let me know if people would like to see this implemen

RE: [DBCP] Building the DBCP jarfile

> > I checked the collections jarfile and the FastHashMap.class file is > > present there. Anybody got a clue what's going wrong? > > No. That's odd. Sure was. Sorry, fucked something up. Everything works peachy now, except for 13 deprecated warnings:) > It looks like DBCP has a maven buildfi

Re: [latka] Plugin for Maven

This is pretty cool. I assume it uses the latest, Jelly-driven version of Latka? The new code seems pretty stable, but it could use more testing. On a side note, the old Latka implementation automatically checked to make sure all variables were defined. We can't do that in quite the same way

Re: cvs commit:jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/taskJellyTask.java

Your welcome ;) My first commit for jelly afaik (although I already seem to be a contributor) I'm probably also going to jelliefy nyx :) Mvgr, Martin On Thu, 2002-12-12 at 17:25, James Strachan wrote: > From: <[EMAIL PROTECTED]> > > mvdb2002/12/12 07:40:37 > > > > Modified:jelly/sr

Re: [jelly] switch/case

FWIW I also think the current behaviour is nice and concise. I wrote a fairly large Jelly switch statement, and it was nice to not have to write all those break tags. --- Rodney Waldhoff <[EMAIL PROTECTED]> wrote: > Given this and the other replies on this thread, I > guess I'll just leave > well

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

On Thu, 12 Dec 2002, Ola Berg wrote: > The thing is: should [functor] contain the util classes with default > implementations etc. If so, I am compelled to say that it should go into > [lang]. In my opinion, yes [functor] should contain the most basic and common Functor implementations. You're o

Re: cvs commit: jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/task JellyTask.java

From: <[EMAIL PROTECTED]> > mvdb2002/12/12 07:40:37 > > Modified:jelly/src/java/org/apache/commons/jelly/task JellyTask.java > Log: > Now using getLocation and getProject instead of directly referencing the protected instance. This instance will be deprecated in the next ant relea

Re: [DBCP] Building the DBCP jarfile

On Thu, 12 Dec 2002, Martin van Dijken wrote: > I checked the collections jarfile and the FastHashMap.class file is > present there. Anybody got a clue what's going wrong? No. That's odd. I'll guess that commons-collections isn't really in your compile-time classpath. That particular class is

cvs commit: jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/task JellyTask.java

mvdb2002/12/12 07:40:37 Modified:jelly/src/java/org/apache/commons/jelly/task JellyTask.java Log: Now using getLocation and getProject instead of directly referencing the protected instance. This instance will be deprecated in the next ant release, that's why it caught my eye.

[DBCP] Building the DBCP jarfile

Hey guys, I wanted to try and change some stuff in dbcp. (for now just for test purposes) In order to do that I checked out the entire commons module and built the collections, pool and lang packages. I then saved dbcp\build.properties.sample to dbcp\build.properties and changed the locations o

Re: [jelly] switch/case

Given this and the other replies on this thread, I guess I'll just leave well enough alone for now. On Tue, 10 Dec 2002, bob mcwhirter wrote: > > I think most folks tend to use 'break' with their switch/case statements, > and probably have been bitten in the ass a lot due to a missing break. > >

Re: [collections][patch] ClassFilterIterator

Wouldn't it be more generic to expose your (private inner) ClassPredicate as a public Predicate, say InstanceOfPredicate? That way one could easily create ClassFilterIterator, as you have, but could also use the Predicate in the various CollectionUtils methods, etc. Also, I wonder if the ClassPred

[GUMP] Build Failure - commons-email

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

[GUMP] Build Failure - commons-jelly

This email is autogenerated from the output from: Buildfile: build.xml init: [mkdir] Created dir: /home/rubys/jakarta/jak

RE: DBCP tracking stale connections?

On Tue, 10 Dec 2002, Martin van Dijken wrote: > > > > BasicDataSource currently doesn't expose testWhileIdle, > > > > although if you look at how the other props are dealt with, > > > > it wouldn't be difficult to expose it (a small change to > > > > BasicDataSourceFactory and BasicDataSource is

DO NOT REPLY [Bug 14591] - Serialization problem with org.apache.commons.validator.ValidatorResult$ResultStatus

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: [collections][lang] Functors, pre-vote

>> Does it matter if [functor] and [lang] have circular dependencies? Not >> that they will. Ola: > Yes, that does matter. > The thing is: should [functor] contain the util classes with default implementations etc. If so, I am compelled to say that it should go into [lang]. There is no real req

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

> it appears that [functor] will need to depend on [lang] for exception > nesting. > > hopefully, lang will not need to depend on functor. if it does, then maybe > it shows that the factoring has gone a bit wrong and we need to think > about it again. No, I don't agree. Functors would be very

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

> Does it matter if [functor] and [lang] have circular dependencies? Not > that they will. Yes, that does matter. The thing is: should [functor] contain the util classes with default implementations etc. If so, I am compelled to say that it should go into [lang]. /O -- To unsubscribe, e-mai