[PATCH][betwixt] CustomerBean, PersonBean, AddressBean

Hi, Here are three simple patches that change the contract of the CustomerBean, PersonBean and AddressBean test classes in betwixt, so that these beans can be compared in a sensible manner. The patches change the toString() method and add equals() and hashCode() methods so that any two Custome

Re: [cli] API change

In my own CLI-like library, I've occasionally found it useful to be able to hack the command line slightly, before passing it to the interrogation phase. For example, where a parameter two's default value depends on parameter one's value, but I don't want to over-write the user's input if they

Re: [jelly] [jsl] XPath context for templates and looping

Cool. I have another hassle with JSL that I'll document in a test case today hopefully. Thanks for the quick turnaround. I had no idea on how to fix this and it'll save me lots of grey hair knowing it's fixed :) -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Develo

Re: [core] presentation url

Cool stuff. Can we collect these links somewhere in the commons site? -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers Henri Yandell <[EMAIL PROTECTED]> wrote on 20/11/2002 12:39:09 AM: > I did a presentation

[cli] API change

Hi guys, The method signature for addValue is currently public, this method should only ever be called by the parser when it is creating the command line. This method currently returns a boolean when the add fails, this should be changed to throw exceptions when a problem occurs. What is the

RE: runtime attributes

Hi everyone, I'm still comming up to speed on the other projects but I thought I'd through my 2cents in anyway coming from the perspective of what is done in attrib4j. I see different approaches of what the @tag should contain and how it should be interpreted by doclet processing. One appro

[core] presentation url

I did a presentation on Commons 'Core', that is Collections, Lang, BeanUtils and a few others over at the JUG in Cincinatti, OH, USA. Thought the url might be of interest: http://www.flamefew.net/~hen/talks/commonsCore/ Hen -- To unsubscribe, e-mail: For additional

RE: [attributes] Jakarta Commons Attributes, Nanning & XRAI

--- Ara Abrahamian <[EMAIL PROTECTED]> skrev: > > Ok, so maybe we just have to change our mind. What > you are proposing > is > > that commons-attributes is the de facto > runtime-implementation of > > attributes. It could still be pluggable but we > have a very rich > default > > implementation d

cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli OptionBuilder.java

jkeyes 2002/11/19 14:54:48 Modified:cli/src/java/org/apache/commons/cli OptionBuilder.java Log: set the default argument name Revision ChangesPath 1.14 +4 -4 jakarta-commons/cli/src/java/org/apache/commons/cli/OptionBuilder.java Index: OptionBuilder.java

cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli Option.java

jkeyes 2002/11/19 14:53:08 Modified:cli/src/java/org/apache/commons/cli Option.java Log: set the default argument name Revision ChangesPath 1.17 +1 -1 jakarta-commons/cli/src/java/org/apache/commons/cli/Option.java Index: Option.java

cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli HelpFormatter.java

jkeyes 2002/11/19 14:50:19 Modified:cli/src/java/org/apache/commons/cli HelpFormatter.java Log: applied some fixes to HelpFormatter, thanks to Rob and Boon Revision ChangesPath 1.11 +81 -44 jakarta-commons/cli/src/java/org/apache/commons/cli/HelpFormatter.java

cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli CommandLine.java

jkeyes 2002/11/19 14:47:11 Modified:cli/src/java/org/apache/commons/cli CommandLine.java Log: applied a fix to prevent a NPE, reported by Boon Hian Tek Revision ChangesPath 1.16 +3 -0 jakarta-commons/cli/src/java/org/apache/commons/cli/CommandLine.java In

Javdoc formatting (Was: [lang] [patch] Javadoc improvements)

Henri Yandell wrote: I'm all for having consistent javadoc. Feel like writing up the 'rules' for the javadoc style you've ended up on? Hi! Here is the promised rules that I try to follow when writing javadoc. Ofcourse the Sun javadoc guidelines is used, this is only to be seen as an extension

DO NOT REPLY [Bug 14394] - Excessive exceptions log under security manager

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/beanutils/src/java/org/apache/commons/beanutils MethodUtils.java

rdonkin 2002/11/19 13:51:06 Modified:beanutils/src/java/org/apache/commons/beanutils MethodUtils.java Log: Added code to prevent excessive logging at warn level when running in restrictive security environment (bug #14394). Revision ChangesPath 1.

RE: runtime attributes

> > /** > > * @simple we like to program > > * @complex we="like" to="program" > > */ > > > > These are the two "legal" @tag formats in XDoclet/XJavadoc. It's > analog to > > XML: > > > > we like to program > > > > > > The complex format is used more by XDoclet plugins than the simple > format.

DO NOT REPLY [Bug 14394] - Excessive exceptions log under security manager

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 14620] - debug logging turns on exception

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/beanutils/src/java/org/apache/commons/beanutils BeanUtils.java

rdonkin 2002/11/19 12:20:08 Modified:beanutils/src/java/org/apache/commons/beanutils BeanUtils.java Log: Fixed bug #14620. Fix proposed by larry hamel. Revision ChangesPath 1.27 +9 -7 jakarta-commons/beanutils/src/java/org/apache/commons

Re: [betwixt][patch] CustomerBean, PersonBean, AddressBean

committed. thanks. - robert On Monday, November 18, 2002, at 11:03 PM, Michael Davey wrote: Hi, Here are three simple patches that change the contract of the CustomerBean, PersonBean and AddressBean test classes in betwixt, so that these beans can be compared in a more logical manner. The p

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt AddressBean.java CustomerBean.java PersonBean.java

rdonkin 2002/11/19 12:13:18 Modified:betwixt/src/test/org/apache/commons/betwixt AddressBean.java CustomerBean.java PersonBean.java Log: Test case comparison improvements. Submitted by Michael Davey. Revision ChangesPath 1.2 +12 -1 jakar

RE: runtime attributes

> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: den 19 november 2002 14:56 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: runtime attributes > > > > Hi! > > (Sorry for sending HTML mail, I have a

Re: [lang] MethodUtils - assignableFrom

makes sense to me :) i'll hunt the right method in ReflectionUtils and fix any bugs it contains. - robert On Monday, November 18, 2002, at 11:05 PM, Stephen Colebourne wrote: Ahh, now I remember my thinking... ClassUtils version is non-reflection specific, thus it knows nothing about Boolean

cvs commit: jakarta-commons/docs commons.html beanutils.html logging.html volunteering.html charter.html dbcp.html pool.html lang.html sandbox.html license.html directory.html releases.html contributors.html modeler.html discovery.html versioning.html components.html index.html collections.html patches.html digester.html

jstrachan2002/11/19 08:55:12 Modified:docs commons.html beanutils.html logging.html volunteering.html charter.html dbcp.html pool.html lang.html sandbox.html license.html directory.html releases.html contributors

cvs commit: jakarta-commons/xdocs/stylesheets project.xml

jstrachan2002/11/19 08:54:46 Modified:xdocssandbox.xml components.xml xdocs/stylesheets project.xml Log: Added links to commons-attributes Revision ChangesPath 1.23 +8 -0 jakarta-commons/xdocs/sandbox.xml Index: sandbox.xml

cvs commit: jakarta-commons-sandbox/attributes/xdocs navigation.xml index.xml usecases.xml

jstrachan2002/11/19 08:40:08 Modified:attributes/xdocs navigation.xml index.xml usecases.xml Log: Added more links to the JSR175 and XRAI and tidied the documentation some Revision ChangesPath 1.3 +3 -2 jakarta-commons-sandbox/attributes/xdocs/navigation.xml

DO NOT REPLY [Bug 14549] - Default charset

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: [attributes][PATCH]

Patch applied, many thanks Jon. James --- http://radio.weblogs.com/0112098/ - Original Message - From: "Jon Tirsén" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Friday, November 15, 2002 2:11 PM Subject: [attributes][PATCH] > - Added Attribute-i

cvs commit: jakarta-commons-sandbox/attributes/src/java/org/apache/commons/attributes/impl DefaultAttribute.java DefaultAttributeFinder.java

jstrachan2002/11/19 08:04:30 Modified:attributes/src/java/org/apache/commons/attributes AttributeFinder.java Attributes.java attributes/src/test/org/apache/commons/attributes AttributesTest.java AttributesTestClass.java

cvs commit: jakarta-commons-sandbox/attributes/xdocs/style - New directory

jstrachan2002/11/19 08:04:24 jakarta-commons-sandbox/attributes/xdocs/style - New directory -- To unsubscribe, e-mail: For additional commands, e-mail:

cvs commit: jakarta-commons-sandbox/attributes/xdocs/images - New directory

jstrachan2002/11/19 08:04:24 jakarta-commons-sandbox/attributes/xdocs/images - New directory -- To unsubscribe, e-mail: For additional commands, e-mail:

DO NOT REPLY [Bug 11223] - need to add a default constructor for Cookie

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: [codec] Handling text encodings (one more thing, sorry)

> Maybe we need two concepts: > > A ChunkCodec - like Soundex, Metaphone, Refined Soundex, Message > digests > And a StreamCodec - like Base64, Rot13, compression algorithms, sound > encoding... Sun dealt with the IO in a block/stream neutral way, where InputStream provides a stream oriente

RE: [codec] Handling text encodings (one more thing, sorry)

A lot of good points. Soundex, Metaphone, and Refined Soundex all deal with language, it would make more sense if these classes were moved into a language subpackage. With regards to streams, I think it makes sense for something like Base64 - most definitely this should be a stream oriented codec

Re: [jelly] [jsl] XPath context for templates and looping

OK this bug is now fixed - thanks once again for both finding it and replicating it in a JellyUnit test case. This made fixing it considerably easier. It was a strange, hard to explain bug caused by the current TagScript implementation (in the impl package). The bug is due to the body of a actual

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

jstrachan2002/11/19 05:28:43 Modified:jelly/src/java/org/apache/commons/jelly/impl TagScript.java jelly/src/java/org/apache/commons/jelly/tags/jsl TemplateTag.java jelly/src/test/org/apache/commons/jelly/jsl suite.jelly Log: Patch

Re: [jelly] [jsl] XPath context for templates and looping

BTW dIon, thanks for the great JellyUnit test case to demonstrate this bug! FWIW I've just committed a workaround example in the JellyUnit test case that shows that if the stylesheet is defined outside of the loop and reused inside it, things work fine. I'm close to tracking down this bug now...

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

jstrachan2002/11/19 05:14:00 Modified:jelly/src/test/org/apache/commons/jelly/jsl suite.jelly Log: Added an example of working JSL stylesheets. In particular the reuse of a single JSL stylesheet within a loop works fine. Still haven't fixed dIon's bug yet but it appears to be

AW: AW: [Betwixt] XMLBeanInfo customization

> -Ursprüngliche Nachricht- > Von: robert burrell donkin > [mailto:[EMAIL PROTECTED]] > Gesendet: Montag, 18. November 2002 22:53 > An: Jakarta Commons Developers List > Betreff: Re: AW: [Betwixt] XMLBeanInfo customization > > > On Monday, November 18, 2002, at 08:41 PM, > [EMAIL PROT

[lang] Hasher

It is difficult with good hashing. But I am into giving a static utility hashing class a try, since I think it is justified in lang. I experiment with two approaches: bit mangling functions (a la Thomas Wang http://www.concentric.net/~Ttwang/tech/inthash.htm ) and lookup-tables ("buztables") li

Re: [codec] Handling text encodings

> It should work with streams, no doubt about it. > I think that there should be two separate > interfaces-- at least that's what I've usually done in such situations. An argument against that would be that both en- and decoding are simply stream transformations. It is the context (or your m

[codec] Handling text encodings (one more thing, sorry)

I also think that if there are going to be lots of codecs in the project over time, all the classes for a particular area should be in subpackages, like the Base64 codec currently is. That means that the Metaphone codec etc. should be moved down into a subpackage, and the codec package should j

Re: [codec] Handling text encodings

I just wanted to point out that in similar situations, more than one XML API developer has chosen to force String input to be wrapped in StringReader instances. This is in a whole programming area devoted to nothing but processing text! I don't think it's inappropriate at all, even though I've

Re: [codec] Handling text encodings

It should work with streams, no doubt about it. I think that there should be two separate interfaces-- at least that's what I've usually done in such situations. You can make a separate Encoder and Decoder interface, and a Codec interface that extends them both. That gives lots of flexibility

Re: [codec] Handling text encodings

> > The codec package is very simple. Right now it contains 3 encoders > > specifically geared towards language ( Soundex, RefinedSoundex, and > > Metaphone ). It also contains a Base64 encoder and decoder. > > > > There is only one interface "Encoder" with one method "public > > String encode(S