Re: [lang] PATCH add serialize method to lang.Objects

2002-03-10 Thread Daniel Rall
John McNally <[EMAIL PROTECTED]> writes: > Here is another try with a better subject. Also changed the serialize > method to return null instead of throwing an exception, so it behaves > similarly to the deserialize method. Though I think both methods > throwing an exception would be better. H

Re: add serialize method to lang.Objects

2002-03-10 Thread Daniel Rall
Done, thanks John. - Dan John McNally <[EMAIL PROTECTED]> writes: > Here is a patch to add a serialize method to Objects to complement the > deserialize method. Also included are unit tests for Objects. > > john mcnallyIndex: Objects.java > =

cvs commit: jakarta-commons-sandbox/lang/src/test/org/apache/commons/lang ObjectsTest.java

2002-03-10 Thread dlr
dlr 02/03/11 00:05:20 Modified:lang build.xml lang/src/java/org/apache/commons/lang Objects.java Added: lang/src/test/org/apache/commons/lang ObjectsTest.java Log: Patch by John McNally <[EMAIL PROTECTED]>: "Here is a patch to add a serialize meth

Re: [lang] test classes for commons.lang.exception package

2002-03-10 Thread Daniel Rall
"Steven Caswell" <[EMAIL PROTECTED]> writes: > Ah. Yes. Sorry for the oversight. And thanks for the cleanup. Thanks for the test cases Steve! - Dan -- To unsubscribe, e-mail: For additional commands, e-mail:

RE: [COLLECTIONS] Avalon's BucketMap meets commons?

2002-03-10 Thread Tim Vernum
From: Gerhard Froehlich [mailto:[EMAIL PROTECTED]] > Hi, > we introduced a new Collection class "the BucketMap" > into Avalon Excalibur some days ago: > >http://cvs.apache.org/viewcvs/jakarta-avalon-excalibur/src/java/org/apache/avalon/excalibur/collections/BucketMap.java > BTW: It doesn't imp

Re: Handling of Commons Bugzilla Reports

2002-03-10 Thread Martin Cooper
+1 This works well in Struts, and I'd like to see the same thing happen in Commons. -- Martin Cooper - Original Message - From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, March 10, 2002 9:28 PM Subject: Handling of Commons Bugzilla Reports > I'd l

DO NOT REPLY [Bug 6685] - Validator forces Digester debugging to true

2002-03-10 Thread bugzilla
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 6685] - Validator forces Digester debugging to true

2002-03-10 Thread bugzilla
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

Handling of Commons Bugzilla Reports

2002-03-10 Thread Craig R. McClanahan
I'd like to suggest a convention for nwe Bugzilla bug reports related to Commons packages that has worked well for many other Jakarta projects -- make the initial owner of all bugs the commons-dev mailing list. This causes all new bug reports (and updates to them) to get reflected to the COMMONS-

cvs commit: jakarta-commons/validator build.xml

2002-03-10 Thread dwinterfeldt
dwinterfeldt02/03/10 21:12:02 Modified:validator build.xml Added: validator/src/test/org/apache/commons/validator Name.java RequiredNameTest.java TestValidator.java validator-name-required.xml ValidatorTestSuite.java Log: Start

[dbcp] Build fails with JDK 1.4

2002-03-10 Thread otisg
Hello, It appears that DBCP cannot be compiled with JDK 1.4. Are there any plans to make DBCP compatible with 1.4? build-java: [javac] Compiling 9 source files to /home/otis/cvs-repositories/jakarta/jakarta-commons/dbcp/dist/classes [javac] /home/otis/cvs-repositories/jakarta/jakarta-commons/dbc

Re: cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digesterDigester.java

2002-03-10 Thread Craig R. McClanahan
On 11 Mar 2002 [EMAIL PROTECTED] wrote: > Index: build.xml > === > RCS file: /home/cvs/jakarta-commons/digester/build.xml,v > retrieving revision 1.20 > retrieving revision 1.21 > diff -u -r1.20 -r1.21 > --- build.xml

cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester Digester.java

2002-03-10 Thread craigmcc
craigmcc02/03/10 21:01:54 Modified:digester build.xml digester/src/java/org/apache/commons/digester Digester.java Log: Instead of swallowing Throwables inside a rethrown SAXException, simply log and rethrow any Error that occurs so that things like OutOfMemoryError

cvs commit: jakarta-commons/beanutils/src/test/org/apache/commons/beanutils BeanUtilsTestCase.java DynaBeanUtilsTestCase.java

2002-03-10 Thread craigmcc
craigmcc02/03/10 20:49:53 Modified:beanutils/src/java/org/apache/commons/beanutils BeanUtils.java beanutils/src/test/org/apache/commons/beanutils BeanUtilsTestCase.java DynaBeanUtilsTestCase.java Log: Repair and enhance

Re: [betwixt] Strategy for dealing with addXXX() methods

2002-03-10 Thread Jason van Zyl
On Sun, 2002-03-10 at 20:26, James Strachan wrote: > Hi Jason > > I think that approach sounds great. I'm sure we could plug in a few > different Strategy patterns so that folks can customize the XMLIntrospector > to suit their needs. e.g. some folks like to use mixedCaseNames for bean > properti

[lang] PATCH add serialize method to lang.Objects

2002-03-10 Thread John McNally
Here is another try with a better subject. Also changed the serialize method to return null instead of throwing an exception, so it behaves similarly to the deserialize method. Though I think both methods throwing an exception would be better. previous message: Here is a patch to add a seriali

Re: [betwixt] Default Behaviour

2002-03-10 Thread James Strachan
James - Original Message - From: "Jason van Zyl" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Sunday, March 10, 2002 3:13 AM Subject: [betwixt] Default Behaviour > Hi James, > > I'm just looking over the maven project descriptor in the tests and I

Re: [betwixt] Strategy for dealing with addXXX() methods

2002-03-10 Thread James Strachan
Hi Jason I think that approach sounds great. I'm sure we could plug in a few different Strategy patterns so that folks can customize the XMLIntrospector to suit their needs. e.g. some folks like to use mixedCaseNames for bean properties and style XML elements. So go for it. BTW yes you're right

Re: org.apache.commons.digester.Rule constructor...

2002-03-10 Thread Craig R. McClanahan
On Sun, 10 Mar 2002, robert burrell donkin wrote: > Date: Sun, 10 Mar 2002 16:26:10 + > From: robert burrell donkin <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > Subject: Re: org.apache.commons

cvs commit: jakarta-commons-sandbox/simplestore/src/test/org/apache/commons/simplestore TestPersistentClassType.java TestSample.java storage.xml

2002-03-10 Thread baliuka
baliuka 02/03/10 10:58:35 Modified:simplestore/src/test/org/apache/commons/simplestore TestPersistentClassType.java TestSample.java storage.xml Log: Added validation Revision ChangesPath 1.3 +8 -1 jakarta-common

cvs commit: jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/persistence/impl NotNull.java MetaClassImpl.java PersistentProxy.java

2002-03-10 Thread baliuka
baliuka 02/03/10 10:37:17 Modified:simplestore/src/java/org/apache/commons/simplestore/persistence MetaClass.java simplestore/src/java/org/apache/commons/simplestore/persistence/impl MetaClassImpl.java PersistentProxy.java

cvs commit: jakarta-commons-sandbox/simplestore/src/test/org/apache/commons/simplestore TestPersistent.java TestPersistentClassType.java TestSample.java

2002-03-10 Thread baliuka
baliuka 02/03/10 04:32:31 Modified:simplestore build.xml simplestore/src/java/org/apache/commons/simplestore/cache/impl SoftRefMemoryCache.java simplestore/src/java/org/apache/commons/simplestore/persistence M

RE: [lang] test classes for commons.lang.exception package

2002-03-10 Thread Steven Caswell
Ah. Yes. Sorry for the oversight. And thanks for the cleanup. Steven Caswell [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving "One ring to rule them all, one ring to find them..." > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Daniel

Re: [ALTRMI]-PATCH JNDI interface for Altrmi clients

2002-03-10 Thread vinaysahil chandran
> 3) your name has replaced mine as auther of the > smaller class, as i did > nothing really. > :-)) haha > > 1) I hate the env.put() business of JNDI. Should we > also provide a > helper factory (optional use) that will make an > InitialContext for comon > types of transport? It would

cvs commit: jakarta-commons-sandbox/betwixt/src/test/org/apache/commons/betwixt/project BaseObject.java TestProjectRoundTrip.java

2002-03-10 Thread jvanzyl
jvanzyl 02/03/10 12:16:03 Modified:betwixt/src/test/org/apache/commons/betwixt/project BaseObject.java TestProjectRoundTrip.java Log: This is as close as I can get without changing any code: You seem to need: ... In order to s

cvs commit: jakarta-commons-sandbox/betwixt/src/test/org/apache/commons/betwixt/project Project.java TestProjectRoundTrip.java

2002-03-10 Thread jvanzyl
jvanzyl 02/03/10 11:38:49 Modified:betwixt/src/test/org/apache/commons/betwixt/project Project.java TestProjectRoundTrip.java Log: Didn't mean to check in a failing test, working on finding the problem. Revision ChangesPath 1.2 +4 -3 j

cvs commit: jakarta-commons-sandbox/betwixt/src/test/org/apache/commons/betwixt/project BaseObject.java Developer.java Project.java TestProjectRoundTrip.java project.xml

2002-03-10 Thread jvanzyl
jvanzyl 02/03/10 11:35:28 Added: betwixt/src/test/org/apache/commons/betwixt/project BaseObject.java Developer.java Project.java TestProjectRoundTrip.java project.xml Log: Placing the project tests in a package of their own. Rev

cvs commit: jakarta-commons-sandbox/betwixt/src/test/org/apache/commons/betwixt/project - New directory

2002-03-10 Thread jvanzyl
jvanzyl 02/03/10 11:34:10 jakarta-commons-sandbox/betwixt/src/test/org/apache/commons/betwixt/project - New directory -- To unsubscribe, e-mail: For additional commands, e-mail:

Bug report for Commons [2002/03/10]

2002-03-10 Thread bugzilla
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned

[betwixt] Strategy for dealing with addXXX() methods

2002-03-10 Thread Jason van Zyl
Hi James, I was just looking at a way for trying to deal with addXXX() methods in a configurable way. I think I might have come up with a way to handle it. While passing through the bean information in XMLIntrospector.introspect() when discovering a loop type could we take the name, say Hobbies,

Re: org.apache.commons.digester.Rule constructor...

2002-03-10 Thread robert burrell donkin
On Saturday, March 9, 2002, at 12:51 AM, James Carman wrote: > Why does the Rule class only provide a constructor that takes a Digester > parameter? It is very annoying to have to provide a constructor for > rules! Why can't you just add a setDigester() method to the Rule class > and let a t

Re: [ALTRMI]-PATCH JNDI interface for Altrmi clients

2002-03-10 Thread Paul Hammant
Vinay, >Did some prelim' JNDI bridge work for client-side >lookup's and listing. > Yes it is good stuff. I have committed it. Some small changes : 1) names of clases have be prefixed with Default. Why? EOB is likely to re-implement to allow internal VM lookup when the client thinks it is do

cvs commit: jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/impl/naming DefaultAltrmiContext.java DefaultAltrmiInitialContextFactory.java AltrmiContext.java

2002-03-10 Thread hammant
hammant 02/03/10 01:40:18 Modified:altrmi/src/java/org/apache/commons/altrmi/client/impl DefaultInterfaceLookupFactory.java Added: altrmi/src/java/org/apache/commons/altrmi/client/impl/naming DefaultAltrmiContext.java

Re: [ALTRMI]-PATCH JNDI interface for Altrmi clients

2002-03-10 Thread Paul Hammant
Vinay, >Paul, >Did some prelim' JNDI bridge work for client-side >lookup's and listing. > > > > >Comments ?? > I am over the moon I will put it in now! - Paul -- To unsubscribe, e-mail: For additional commands, e-mail: