DO NOT REPLY [Bug 16525] - BeanUtils.setProperty is over-zealous at converting types
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16525 BeanUtils.setProperty is over-zealous at converting types --- Additional Comments From [EMAIL PROTECTED] 2003-02-03 08:19 --- Created an attachment (id=4680) Alternate patch - make copyProperty() support the extended syntax (nested/indexed/mapped). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16525] - BeanUtils.setProperty is over-zealous at converting types
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16525 BeanUtils.setProperty is over-zealous at converting types --- Additional Comments From [EMAIL PROTECTED] 2003-02-03 08:21 --- The above patch is quite large - I ended up doing some significant refactoring to reduce the duplication of code between setProperty() and copyProperty() All tests pass and I've added some additional tests for the new functionality of copyProperty. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release digester 1.4
From: robert burrell donkin [EMAIL PROTECTED] the release candidate can be found at http://cvs.apache.org/~rdonkin/commons-digester/RC1/ your votes, please: Digester 1.4 Release - [X] +1 I support this release and will help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons: -- James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16600] - JUnitTestAdapter throws SAXException because no DTD found
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16600. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16600 JUnitTestAdapter throws SAXException because no DTD found --- Additional Comments From [EMAIL PROTECTED] 2003-02-03 12:53 --- suite.dtd: that's great. To make it more usable, can we get this: 1. assigned a PUBLIC ID so it can be loaded by classpath resolvers. 2. assigned a URL so it can be loaded without a resolver. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language - New directory
tobrien 2003/02/03 06:12:17 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit:jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language - New directory
Title: RE: cvs commit: jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language - New directory Please remove me from the mailing list -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 8:12 AM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language - New directory tobrien 2003/02/03 06:12:17 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] "WorldSecure Server" made the following annotations on 02/03/2003 09:14:03 AM -- This message and any attachments (hereunder the « message ») are confidential and intended solely for the addressees. If you receive this message in error, please delete it and immediately notify the sender. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, copying or dissemination is prohibited. E-mails are susceptible to alteration. Neither LOREAL nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/digester XMLIntrospectorHelper.java
mvdb2003/02/03 06:23:31 Modified:betwixt/src/java/org/apache/commons/betwixt/digester XMLIntrospectorHelper.java Log: Fixing nullpointer exception scenario when debugging. Revision ChangesPath 1.17 +3 -2 jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/digester/XMLIntrospectorHelper.java Index: XMLIntrospectorHelper.java === RCS file: /home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/digester/XMLIntrospectorHelper.java,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- XMLIntrospectorHelper.java8 Jan 2003 22:07:21 - 1.16 +++ XMLIntrospectorHelper.java3 Feb 2003 14:23:31 - 1.17 @@ -392,7 +392,8 @@ if ( log.isDebugEnabled() ) { log.debug( !! + propertyName + - + descriptor ); -log.debug( !! + name + - + descriptor.getPropertyName() ); +log.debug( !! + name + - + +(descriptor!=null?descriptor.getPropertyName():) ); } if ( descriptor != null ) { - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Proposal new xml tag xml:entity
On Mon, Feb 03, 2003 at 09:49:04AM +0100, Martin van den Bemt wrote: So maybe there should be an xml:text tag to get this handled (don't use xslt myself though) ? I think it's better to have a jsl:text tag that accepts the disable-output-escaping=yes attribute. You don't need any special xml tag just output an entity name=copy/ tag to the processing chain (the xml taglib will output it transparentely), catch it in a rule and use the jsl:text tag for it. One of my major headache right now is that (Don't want to give you bad tips, that in a document: ?xml version=1.0? !DOCTYPE a [ !ENTITY x y ] ax;/a the dom4j linrary will output (just something like what you want) ?xml version=1.0 encoding=UTF-8? !DOCTYPE aax;/a in a simple read-in/write-out processing (e.g.: SAXReader xmlReader = new SAXReader(); Document doc = xmlReader.read(argv[0]); XMLWriter writer = new XMLWriter(System.out); writer.write(doc); writer.flush();) which is not well-formed, so my processing pipe breaks at this point. At any creative solution you 'll find yourself similar problems. incze - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/codec/src/test/org/apache/commons/codec/language - New directory
tobrien 2003/02/03 06:58:55 jakarta-commons-sandbox/codec/src/test/org/apache/commons/codec/language - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/codec/src/test/org/apache/commons/codec/language TestDoubleMetaphone.java
tobrien 2003/02/03 07:00:12 Modified:codec/src/test/org/apache/commons/codec TestAll.java Added: codecTODO codec/src/java/org/apache/commons/codec/language DoubleMetaphone.java codec/src/test/org/apache/commons/codec/language TestDoubleMetaphone.java Log: Added DoubleMetaphone and associated JUnit test Revision ChangesPath 1.1 jakarta-commons-sandbox/codec/TODO Index: TODO === This is a list of action items to be finished in the [codec] project. This TODO list reflects the current direction of development, and should be updated by all committers when a known issues or task is identified. This TODO list be periodically sync'd with the content on http://nagoya.apache.org/wiki/apachewiki.cgi?CodecProjectPages - this WIKI page is provides as a tool for volunteers to comment on the current TODO list and to suggest tasks. When a task in the TODO list is done, move the entry to the DONE list below, and note who made the change and when. ** TODO List * Add a Hex implementation * Add a Rot13 implementation * Move phonetic encoders into dedicated package. * Add a Decoder interface * Refactor Base64 to implement both Encoder and Decoder * Documentation! Create Forrest documentation for Codec AFTER documentation has evolved in Wiki * Integrate Patches: ** Patch submitted by Iulian Musat for Base64 ** Add DoubleMetaphone and Nysiis implementation from KyleBurton * DoubleMetaphone ** Modify DoubleMetaphone implementation - make it thread safe(r). ** Figure out why algorithm fails to properly code bryce and maurice. ** DONE 2/3/03 - TOB - Integrated DoubleMetaphone and Test from Kyle Burton 2/2/03 - TOB - language package created to hold language and phonetic encodings 2/2/03 - TOB - All CRLF issues resolved in codec 1/31/03 - TOB - Patch submitted fixing CRLF problems in Soundex.java 1/31/03 - TOB - Patch submitted fixing CRLF problems in RefinedSoundex.java 1.1 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java Index: DoubleMetaphone.java === /* * The Apache Software License, Version 1.1 * * Copyright (c) 2001-2002 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, *if any, must include the following acknowledgment: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgment may appear in the software itself, *if and wherever such third-party acknowledgments normally appear. * * 4. The names Apache and Apache Software Foundation and *Apache Commons must not be used to endorse or promote products *derived from this software without prior written permission. For *written permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache, *Apache Turbine, nor may Apache appear in their name, without *prior written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. *
DO NOT REPLY [Bug 13676] - [PATCH] FilePart fails to send data on second call to send
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13676. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13676 [PATCH] FilePart fails to send data on second call to send [EMAIL PROTECTED] changed: What|Removed |Added CC|commons-| |[EMAIL PROTECTED] | Status|NEW |RESOLVED Resolution||REMIND --- Additional Comments From [EMAIL PROTECTED] 2003-02-03 15:08 --- Adrian, it appears that this bug is fixed. Can it be closed? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16440] - [codec] Base64 does not handle whitespace correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16440. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16440 [codec] Base64 does not handle whitespace correctly [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED Summary|Codec: Base64 does not |[codec] Base64 does not |handle whitespace correctly |handle whitespace correctly --- Additional Comments From [EMAIL PROTECTED] 2003-02-03 15:28 --- There is talk of starting to use the Base64 code from HttpClient. I will investigate this matter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/codec/src/test/org/apache/commons/codec/language TestNysiis.java
tobrien 2003/02/03 07:48:14 Modified:codecTODO codec/src/test/org/apache/commons/codec TestAll.java Added: codec/src/java/org/apache/commons/codec/language Nysiis.java codec/src/test/org/apache/commons/codec/language TestNysiis.java Log: Added Nysiis implementation Revision ChangesPath 1.3 +4 -1 jakarta-commons-sandbox/codec/TODO Index: TODO === RCS file: /home/cvs/jakarta-commons-sandbox/codec/TODO,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- TODO 3 Feb 2003 15:08:10 - 1.2 +++ TODO 3 Feb 2003 15:48:14 - 1.3 @@ -27,14 +27,17 @@ * Integrate Patches: ** Patch submitted by Iulian Musat for Base64 -** Add Nysiis implementation from KyleBurton * DoubleMetaphone ** Modify DoubleMetaphone implementation - make it thread safe(r). ** Figure out why algorithm fails to properly code bryce and maurice. +* Nysiis +** Modify Nysiis implementation - make it thread safe(r). + ** DONE +2/3/03 - TOB - Added Nysiis code and tests from Kyle Burton 2/3/03 - TOB - Added DoubleMetaphone code and tests from Kyle Burton 2/2/03 - TOB - language package created to hold language and phonetic encodings 2/2/03 - TOB - All CRLF issues resolved in codec 1.1 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language/Nysiis.java Index: Nysiis.java === /* * The Apache Software License, Version 1.1 * * Copyright (c) 2001-2002 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, *if any, must include the following acknowledgment: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgment may appear in the software itself, *if and wherever such third-party acknowledgments normally appear. * * 4. The names Apache and Apache Software Foundation and *Apache Commons must not be used to endorse or promote products *derived from this software without prior written permission. For *written permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache, *Apache Turbine, nor may Apache appear in their name, without *prior written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. */ package org.apache.commons.codec.language; import org.apache.commons.codec.Encoder; /** * A class to generate phonetic codings based on the New York State * Identification and Intelligence System algorithm. This module is based on * the code from the Perl module available from CPAN, which derives from an * implementation by Ben Kennedy. * * @see http://www.nist.gov/dads/HTML/nysiis.html * @see http://search.cpan.org/search?query=nysiismode=all *
RE: [codec] Re: DoubleMetaphone
DoubleMetaphone and Nysiis have been committed. Kyle, thanks for the code. Here's a numbered list... 1. Thread Safety - All of the other encoders are thread safe in that multiple threads can call encode on a single instance of the class. Since we intend codec to be in wide use, it might make sense to move all implementations towards extreme thread safety. I don't think that Soundex is going to be used in the Arianne Sky Rocket or life support, but something like Hex or Base64 could be. 2. DoubleMetaphone doesn't play nice with maurice and bryce - I've put a bug into Bugzilla for this. Tim O'Brien -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 1:51 AM To: Jakarta Commons Developers List; Kyle R . Burton Subject: [codec] Re: DoubleMetaphone Just bouncing this email back to the list so it can go into the submission queue for codec. Hen On Wed, 11 Dec 2002, Kyle R . Burton wrote: I just came across the Codec commons project (we're already using HttpClient where I work) while looking for a Base64 encoder/decoder. While looking through the CVSweb, I noticed the Metaphone and SOUNDEX implementations...I've done implementations of DoubleMetaphone (based on public-domain code - I had permission from Ed Parrish to re-implement his code in Java), and Nysiis and would like to offer them to this project. You can find them here: http://www.bgw.org/projects/java/phonetic/ http://www.bgw.org/projects/java/phonetic/DoubleMetaphone.java http://www.bgw.org/projects/java/phonetic/Nysiis.java I'm not currently on commons-dev, so please CC me directly with any discussion. Thank you for your time, Kyle R. Burton -- -- Wisdom and Compassion are inseparable. -- Christmas Humphreys [EMAIL PROTECTED] http://www.voicenet.com/~mortis -- -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language Nysiis.java
bayard 2003/02/03 08:02:17 Modified:codec/src/java/org/apache/commons/codec/language Nysiis.java Log: Fixed licence from Turbine to Commons. Revision ChangesPath 1.2 +2 -2 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language/Nysiis.java Index: Nysiis.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language/Nysiis.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Nysiis.java 3 Feb 2003 15:48:14 - 1.1 +++ Nysiis.java 3 Feb 2003 16:02:16 - 1.2 @@ -29,7 +29,7 @@ *written permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache, - *Apache Turbine, nor may Apache appear in their name, without + *Apache Commons, nor may Apache appear in their name, without *prior written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language DoubleMetaphone.java
bayard 2003/02/03 08:03:54 Modified:codec/src/java/org/apache/commons/codec Encoder.java EncoderComparator.java Metaphone.java RefinedSoundex.java Soundex.java codec/src/java/org/apache/commons/codec/language DoubleMetaphone.java Log: Fixed licence from Turbine to Commons. Revision ChangesPath 1.4 +2 -2 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/Encoder.java Index: Encoder.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/Encoder.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- Encoder.java 3 Feb 2003 02:19:41 - 1.3 +++ Encoder.java 3 Feb 2003 16:03:54 - 1.4 @@ -29,7 +29,7 @@ *written permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache, - *Apache Turbine, nor may Apache appear in their name, without + *Apache Commons, nor may Apache appear in their name, without *prior written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED 1.4 +2 -2 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/EncoderComparator.java Index: EncoderComparator.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/EncoderComparator.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- EncoderComparator.java3 Feb 2003 02:19:41 - 1.3 +++ EncoderComparator.java3 Feb 2003 16:03:54 - 1.4 @@ -29,7 +29,7 @@ *written permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache, - *Apache Turbine, nor may Apache appear in their name, without + *Apache Commons, nor may Apache appear in their name, without *prior written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED 1.6 +2 -2 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/Metaphone.java Index: Metaphone.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/Metaphone.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- Metaphone.java3 Feb 2003 02:19:41 - 1.5 +++ Metaphone.java3 Feb 2003 16:03:54 - 1.6 @@ -29,7 +29,7 @@ *written permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache, - *Apache Turbine, nor may Apache appear in their name, without + *Apache Commons, nor may Apache appear in their name, without *prior written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED 1.5 +2 -2 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/RefinedSoundex.java Index: RefinedSoundex.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/RefinedSoundex.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- RefinedSoundex.java 3 Feb 2003 02:19:41 - 1.4 +++ RefinedSoundex.java 3 Feb 2003 16:03:54 - 1.5 @@ -29,7 +29,7 @@ *written permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache, - *Apache Turbine, nor may Apache appear in their name, without + *Apache Commons, nor may Apache appear in their name, without *prior written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED 1.6 +2 -2 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/Soundex.java Index: Soundex.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/Soundex.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- Soundex.java 3 Feb 2003 02:19:41 - 1.5 +++ Soundex.java 3 Feb 2003 16:03:54 - 1.6 @@ -29,7 +29,7 @@ *written permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache, - *Apache Turbine, nor may Apache appear in their name,
RE: [codec] Re: DoubleMetaphone
Big worry for code like this is to make sure the licencing etc is okay. As even the cvs-sandbox is published code, making sure that the ASF are not taking over ownership of code without permission is important. These seem okay. Nysiis and DoubleMetaphone are names of algorithms and not trademarked terms. The Nysiis code was originally a perl module [ie) artistic licence I assume, which I'm pretty sure allows copying to an ASF licence]. DoubleMetaphone is a port from C++ code which was originally published in C/C++ Users Journal. If anyone thinks the licencing of these should be a worry, feel free to pipe up. Hen On Mon, 3 Feb 2003, O'brien, Tim wrote: DoubleMetaphone and Nysiis have been committed. Kyle, thanks for the code. Here's a numbered list... 1. Thread Safety - All of the other encoders are thread safe in that multiple threads can call encode on a single instance of the class. Since we intend codec to be in wide use, it might make sense to move all implementations towards extreme thread safety. I don't think that Soundex is going to be used in the Arianne Sky Rocket or life support, but something like Hex or Base64 could be. 2. DoubleMetaphone doesn't play nice with maurice and bryce - I've put a bug into Bugzilla for this. Tim O'Brien -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 1:51 AM To: Jakarta Commons Developers List; Kyle R . Burton Subject: [codec] Re: DoubleMetaphone Just bouncing this email back to the list so it can go into the submission queue for codec. Hen On Wed, 11 Dec 2002, Kyle R . Burton wrote: I just came across the Codec commons project (we're already using HttpClient where I work) while looking for a Base64 encoder/decoder. While looking through the CVSweb, I noticed the Metaphone and SOUNDEX implementations...I've done implementations of DoubleMetaphone (based on public-domain code - I had permission from Ed Parrish to re-implement his code in Java), and Nysiis and would like to offer them to this project. You can find them here: http://www.bgw.org/projects/java/phonetic/ http://www.bgw.org/projects/java/phonetic/DoubleMetaphone.java http://www.bgw.org/projects/java/phonetic/Nysiis.java I'm not currently on commons-dev, so please CC me directly with any discussion. Thank you for your time, Kyle R. Burton -- -- Wisdom and Compassion are inseparable. -- Christmas Humphreys [EMAIL PROTECTED] http://www.voicenet.com/~mortis -- -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit:jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language DoubleMetaphone.java
Title: RE: cvs commit: jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language DoubleMetaphone.java Please remove me from the mailing list - [EMAIL PROTECTED] This is my second week with e-mail bombardment. The documentation to remove yourself from the e-mail list is not correct or is not working! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 10:04 AM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language DoubleMetaphone.java bayard 2003/02/03 08:03:54 Modified: codec/src/java/org/apache/commons/codec Encoder.java EncoderComparator.java Metaphone.java RefinedSoundex.java Soundex.java codec/src/java/org/apache/commons/codec/language DoubleMetaphone.java Log: Fixed licence from Turbine to Commons. Revision Changes Path 1.4 +2 -2 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/Encoder.java Index: Encoder.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/Encoder.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- Encoder.java 3 Feb 2003 02:19:41 - 1.3 +++ Encoder.java 3 Feb 2003 16:03:54 - 1.4 @@ -29,7 +29,7 @@ * written permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache, - * Apache Turbine, nor may Apache appear in their name, without + * Apache Commons, nor may Apache appear in their name, without * prior written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED 1.4 +2 -2 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/EncoderComparator.java Index: EncoderComparator.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/EncoderComparator.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- EncoderComparator.java 3 Feb 2003 02:19:41 - 1.3 +++ EncoderComparator.java 3 Feb 2003 16:03:54 - 1.4 @@ -29,7 +29,7 @@ * written permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache, - * Apache Turbine, nor may Apache appear in their name, without + * Apache Commons, nor may Apache appear in their name, without * prior written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED 1.6 +2 -2 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/Metaphone.java Index: Metaphone.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/Metaphone.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- Metaphone.java 3 Feb 2003 02:19:41 - 1.5 +++ Metaphone.java 3 Feb 2003 16:03:54 - 1.6 @@ -29,7 +29,7 @@ * written permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache, - * Apache Turbine, nor may Apache appear in their name, without + * Apache Commons, nor may Apache appear in their name, without * prior written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED 1.5 +2 -2 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/RefinedSoundex.java Index: RefinedSoundex.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/RefinedSoundex.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- RefinedSoundex.java 3 Feb 2003 02:19:41 - 1.4 +++ RefinedSoundex.java 3 Feb 2003 16:03:54 - 1.5 @@ -29,7 +29,7 @@ * written permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache, - * Apache Turbine, nor may Apache appear in their name, without + * Apache Commons, nor may Apache appear in their name, without * prior written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED 1.6 +2 -2 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/Soundex.java Index: Soundex.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/Soundex.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- Soundex.java 3 Feb 2003 02:19:41 - 1.5 +++ Soundex.java 3 Feb 2003 16:03:54 - 1.6 @@ -29,7 +29,7 @@ * written permission, please contact [EMAIL PROTECTED] * * 5. Products derived
RE: [codec] Re: DoubleMetaphone
DoubleMetaphone also seems to be a port of CPAN Test-DoubleMetaphone-0.05. So, I think both of Kyle's contributions are covered under artistic license. I believe that Perl Artistic section 3a covers this: http://www.perl.com/pub/a/language/misc/Artistic.html, but in big bold red letters, I am not a lawyer. We do intend to modify the code. Tim O'Brien -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 10:09 AM To: Jakarta Commons Developers List Cc: 'Kyle R . Burton' Subject: RE: [codec] Re: DoubleMetaphone Big worry for code like this is to make sure the licencing etc is okay. As even the cvs-sandbox is published code, making sure that the ASF are not taking over ownership of code without permission is important. These seem okay. Nysiis and DoubleMetaphone are names of algorithms and not trademarked terms. The Nysiis code was originally a perl module [ie) artistic licence I assume, which I'm pretty sure allows copying to an ASF licence]. DoubleMetaphone is a port from C++ code which was originally published in C/C++ Users Journal. If anyone thinks the licencing of these should be a worry, feel free to pipe up. Hen On Mon, 3 Feb 2003, O'brien, Tim wrote: DoubleMetaphone and Nysiis have been committed. Kyle, thanks for the code. Here's a numbered list... 1. Thread Safety - All of the other encoders are thread safe in that multiple threads can call encode on a single instance of the class. Since we intend codec to be in wide use, it might make sense to move all implementations towards extreme thread safety. I don't think that Soundex is going to be used in the Arianne Sky Rocket or life support, but something like Hex or Base64 could be. 2. DoubleMetaphone doesn't play nice with maurice and bryce - I've put a bug into Bugzilla for this. Tim O'Brien -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 1:51 AM To: Jakarta Commons Developers List; Kyle R . Burton Subject: [codec] Re: DoubleMetaphone Just bouncing this email back to the list so it can go into the submission queue for codec. Hen On Wed, 11 Dec 2002, Kyle R . Burton wrote: I just came across the Codec commons project (we're already using HttpClient where I work) while looking for a Base64 encoder/decoder. While looking through the CVSweb, I noticed the Metaphone and SOUNDEX implementations...I've done implementations of DoubleMetaphone (based on public-domain code - I had permission from Ed Parrish to re-implement his code in Java), and Nysiis and would like to offer them to this project. You can find them here: http://www.bgw.org/projects/java/phonetic/ http://www.bgw.org/projects/java/phonetic/DoubleMetaphone.java http://www.bgw.org/projects/java/phonetic/Nysiis.java I'm not currently on commons-dev, so please CC me directly with any discussion. Thank you for your time, Kyle R. Burton -- -- Wisdom and Compassion are inseparable. -- Christmas Humphreys [EMAIL PROTECTED] http://www.voicenet.com/~mortis -- -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[codec] RE: more common classes need a home
Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was initially from the HttpClient project. The codec Base64 class has an open bug which also should point us in the right direction: http://issues.apache.org/bugzilla/show_bug.cgi?id=16440 So, I'll make a proposal and hope for lazy consensus: Let's replace Base64 in codec with the current HttpClient version. Tim O'Brien -Original Message- From: Jeffrey Dever [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 1:04 AM To: Jakarta Commons Developers List Subject: Re: more common classes need a home *commons.codec* sounds like a good place for this class. Perhaps you could look at the various current implementations, and see if you can provide a common Base64 class attractive to everyone in Jakarta. Currently these projects (at least) have one plus your new codec package: tomcat xml-rpc slide httpclient Three cheers for code reuse! This goes into codec, which is still in Sandbox. Infact there's already a Base64 there, but I'm not sure how well it matches Slide's needs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Moving commons-sql to db.apache.org
Hi, This pertains to primarily to James and Daniel but I would like to move the commons-sql package over to db.apache.org. I'm in the process of moving OJB and Torque over there so this is the next set of code I want to move. Any objections? -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Redirects?
Hello, I dug through the code to see why my redirects were not being followed. I found HttpMethodBase:checkValidRedirect was not honoring cross server redirects. Isn't this a common type of redirect? Is there a reason its not supported? I did a lot of digging in the specs and couldn't find anything wrong with it unless its an architectural issue with the HttpMethod and the way it integrates with the session. Any help would be appreciated. If there is no reason not to support it, can you make that check part of the strict mode settings on the object? Thanks in advance, Alan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] RE: more common classes need a home
+1 Any timeline for raising codec out of the sandbox? O'brien, Tim wrote: Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was initially from the HttpClient project. The codec Base64 class has an open bug which also should point us in the right direction: http://issues.apache.org/bugzilla/show_bug.cgi?id=16440 So, I'll make a proposal and hope for lazy consensus: Let's replace Base64 in codec with the current HttpClient version. Tim O'Brien -Original Message- From: Jeffrey Dever [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 1:04 AM To: Jakarta Commons Developers List Subject: Re: more common classes need a home *commons.codec* sounds like a good place for this class. Perhaps you could look at the various current implementations, and see if you can provide a common Base64 class attractive to everyone in Jakarta. Currently these projects (at least) have one plus your new codec package: tomcat xml-rpc slide httpclient Three cheers for code reuse! This goes into codec, which is still in Sandbox. Infact there's already a Base64 there, but I'm not sure how well it matches Slide's needs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] RE: more common classes need a home
It might need a little time for Tim to get things sorted out. It's all a bit messy in there. I guess the question needs to be whether it should focus on new functionalities or wrapping up enough to goto Commons-proper. Hen On Mon, 3 Feb 2003, Jeffrey Dever wrote: +1 Any timeline for raising codec out of the sandbox? O'brien, Tim wrote: Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was initially from the HttpClient project. The codec Base64 class has an open bug which also should point us in the right direction: http://issues.apache.org/bugzilla/show_bug.cgi?id=16440 So, I'll make a proposal and hope for lazy consensus: Let's replace Base64 in codec with the current HttpClient version. Tim O'Brien -Original Message- From: Jeffrey Dever [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 1:04 AM To: Jakarta Commons Developers List Subject: Re: more common classes need a home *commons.codec* sounds like a good place for this class. Perhaps you could look at the various current implementations, and see if you can provide a common Base64 class attractive to everyone in Jakarta. Currently these projects (at least) have one plus your new codec package: tomcat xml-rpc slide httpclient Three cheers for code reuse! This goes into codec, which is still in Sandbox. Infact there's already a Base64 there, but I'm not sure how well it matches Slide's needs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EL] Promotion to jakarta-commons?
Hi Rod, I'm +1 on moving [EL] to commons proper, but -1 on promoting components this casually. If this is meant to be a binding vote on promoting EL, it ought to be on a [VOTE] thread, and include a proposal that identif[ies] the rationale for the package, its scope, its interaction with other packages and products, the Commons resources, if any, to be created, the initial source from which the package is to be created, the coding conventions used for the package (if different from the Sun coding conventions), and the initial set of committers. (#17 at http://jakarta.apache.org/commons/charter.html). actually, I think all the information you requested is already provided in jakarta-commons-sandbox/el/PROPOSAL.html, which I circulated to this list when originally proposing this project. Please let me know if you need any additional information. Thanks, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] RE: more common classes need a home
+1 Maybe chunked transfer encoding and URL encoding would fit into this package as well somehow? Odi O'brien, Tim wrote: Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was initially from the HttpClient project. The codec Base64 class has an open bug which also should point us in the right direction: http://issues.apache.org/bugzilla/show_bug.cgi?id=16440 So, I'll make a proposal and hope for lazy consensus: Let's replace Base64 in codec with the current HttpClient version. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [net] Refactoring of ftp2
Basically you contribute to an ASF project via patches and general efforts on the mailing lists. Another way is to help with testing pre-releases. See: http://jakarta.apache.org/site/getinvolved.html Hen On Mon, 3 Feb 2003, Winston Ojeda wrote: Don't know, but if you find out let me know. ;) Winston --- Steve Cohen [EMAIL PROTECTED] wrote: Any news on the promotion business? Is there anything I need to do to get voted in as a committer? __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [codec] RE: more common classes need a home
URI, URL, and URNs are very general - and used everywhere in ASF - this sounds like prime content for the Apache Commons. I don't think that [codec] is the appropriate place for UR[LIN] code, but maybe chunked transfer encoding. I think this is even more general than networks, go to the ISOC, IANA, IAB, ITU, INTA, WIPO archives: http://www.faqs.org/rfcs/index.html, and you'll probably find that URLs are used for more things than you could've imagined. Specifically, I've been taking a crack at telephony, and you've got SIP urls and TEL urls, etc... Tim O'Brien -Original Message- From: Jeffrey Dever [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 11:37 AM To: Jakarta Commons Developers List Subject: Re: [codec] RE: more common classes need a home Maybe chunked transfer encoding and URL encoding would fit into this package as well somehow? Both of those are very http specific. I'm trying to find a home for all the URI, URIUtil, HttpURL ... classes too, but don't think that should be codec. There were some suggestions like commons-net, but its taken. Perhaps there is enough code for their own package commons-uri. http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] ache.orgmsgNo=23684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/fileupload STATUS.html
rdonkin 2003/02/03 09:57:23 Modified:fileupload STATUS.html Log: Added myself to the committers list since i'll be doing some work on the docs Revision ChangesPath 1.6 +2 -1 jakarta-commons/fileupload/STATUS.html Index: STATUS.html === RCS file: /home/cvs/jakarta-commons/fileupload/STATUS.html,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- STATUS.html 12 Nov 2002 05:05:37 - 1.5 +++ STATUS.html 3 Feb 2003 17:57:23 - 1.6 @@ -81,6 +81,7 @@ lia href=mailto:dlr at apache.orgDaniel Rall/a/li lia href=mailto:jvanzyl at apache.orgJason van Zyl/a/li lia href=mailto:martinc at apache.orgMartin Cooper/a/li +lia href=mailto:rdonkin at apache.orgRobert Burrell Donkin/a/li /ul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jelly/jelly-tags/jms/src/java/org/apache/commons/jelly/tags/jms OnMessageTag.java
jstrachan2003/02/03 09:58:00 Modified:jelly/jelly-tags/jms/src/java/org/apache/commons/jelly/tags/jms OnMessageTag.java Log: Patched mistake in jms:onMessage tag which was incorrectly settting the context, rather than the message as a variable when a Message is received Revision ChangesPath 1.3 +6 -7 jakarta-commons-sandbox/jelly/jelly-tags/jms/src/java/org/apache/commons/jelly/tags/jms/OnMessageTag.java Index: OnMessageTag.java === RCS file: /home/cvs/jakarta-commons-sandbox/jelly/jelly-tags/jms/src/java/org/apache/commons/jelly/tags/jms/OnMessageTag.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- OnMessageTag.java 26 Jan 2003 06:24:47 - 1.2 +++ OnMessageTag.java 3 Feb 2003 17:58:00 - 1.3 @@ -100,14 +100,13 @@ throw new JellyTagException(This tag must be nested within a ConsumerTag like the subscribe tag); } - final JellyContext childContext = context.newJellyContext(); final Script script = getBody(); final XMLOutput childOutput = output; MessageListener listener = new MessageListener() { public void onMessage(Message message) { - childContext.setVariable(var, childContext); + childContext.setVariable(var, message); try { script.run(childContext, childOutput); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/fileupload/xdocs navigation.xml overview.xml tasks.xml index.xml
rdonkin 2003/02/03 09:58:31 Modified:fileupload project.xml fileupload/xdocs index.xml Added: fileupload/xdocs navigation.xml overview.xml tasks.xml Log: Created a basic maven documentation. Revision ChangesPath 1.13 +6 -0 jakarta-commons/fileupload/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/fileupload/project.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- project.xml 20 Dec 2002 04:09:08 - 1.12 +++ project.xml 3 Feb 2003 17:58:30 - 1.13 @@ -80,6 +80,12 @@ email[EMAIL PROTECTED]/email organizationZenplex/organization /developer +developer + nameRobert Burrell Donkin/name + idrdonkin/id + email[EMAIL PROTECTED]/email + organization/ +/developer /developers dependencies 1.2 +17 -34jakarta-commons/fileupload/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-commons/fileupload/xdocs/index.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- index.xml 15 Aug 2002 07:50:20 - 1.1 +++ index.xml 3 Feb 2003 17:58:30 - 1.2 @@ -25,41 +25,24 @@ /p /section -section name=Using FileUpload - p -Your application should detect whether or not FileUpload should be -invoked, based on the HTTP method and the content type of the request. - /p - p -Assuming that you have decided that FileUpload should be invoked, you -might write the following code to handle a file upload request: -pre -// Create a new file upload handler -FileUpload upload = new FileUpload(); - -// Set upload parameters -upload.setSizeMax(MAX_UPLOAD_SIZE); -upload.setSizeThreshold(MAX_MEMORY_SIZE); -upload.setRepositoryPath(TEMP_DIR); - -// Parse the request -List items = upload.parseRequest(request); - -// Process the uploaded fields -Iterator iter = items.iterator(); -while (iter.hasNext()) { -FileItem item = (FileItem) iter.next(); - -if (item.isFormField()) { -processTextParameter(request, item); -} else { -processFileParameter(request, item); -} -} -/pre - /p +section name=Downloading Fileupload +subsection name='Full Releases' +!-- list full releases here -- +/subsection +subsection name='Beta Releases' +!-- list beta releases here-- +/subsection +subsection name='Nightly Builds' +p +Nightly builds are built every day from the current CVS HEAD. This is +the latest code and so should be treated with caution! +/p +p +Download nightly builds from +a href='http://cvs.apache.org/builds/jakarta-commons/nightly/commons-fileupload/'here/a. +/p +/subsection /section - /body /document 1.1 jakarta-commons/fileupload/xdocs/navigation.xml Index: navigation.xml === ?xml version=1.0 encoding=ISO-8859-1? project name=Betwixt titleFileUpload/title organizationLogo href=/images/jakarta-logo-blue.gifJakarta/organizationLogo body menu name=FileUpload item name=Homehref=/index.html/ item name=Overviewhref=/overview.html/ item name=To Do List href=/tasks.html/ /menu /body /project 1.1 jakarta-commons/fileupload/xdocs/overview.xml Index: overview.xml === ?xml version=1.0? document properties titleFileupload Overview/title author email=[EMAIL PROTECTED]Robert Burrell Donkin/author /properties body section name=Using FileUpload p Your application should detect whether or not FileUpload should be invoked, based on the HTTP method and the content type of the request. /p p Assuming that you have decided that FileUpload should be invoked, you might write the following code to handle a file upload request: pre // Create a new file upload handler FileUpload upload = new FileUpload(); // Set upload parameters upload.setSizeMax(MAX_UPLOAD_SIZE); upload.setSizeThreshold(MAX_MEMORY_SIZE); upload.setRepositoryPath(TEMP_DIR); // Parse the request List items = upload.parseRequest(request);
RE: [codec] RE: more common classes need a home
I'm +1 to commons-uri. As Tim points out, it's not just URLs, so we could even have pieces of code for dealing with ISBNs etc if the need arose. I don't think they really tie well to commons-io, and losing them in commons-net would be a mistake probably. Hen On Mon, 3 Feb 2003, O'brien, Tim wrote: URI, URL, and URNs are very general - and used everywhere in ASF - this sounds like prime content for the Apache Commons. I don't think that [codec] is the appropriate place for UR[LIN] code, but maybe chunked transfer encoding. I think this is even more general than networks, go to the ISOC, IANA, IAB, ITU, INTA, WIPO archives: http://www.faqs.org/rfcs/index.html, and you'll probably find that URLs are used for more things than you could've imagined. Specifically, I've been taking a crack at telephony, and you've got SIP urls and TEL urls, etc... Tim O'Brien -Original Message- From: Jeffrey Dever [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 11:37 AM To: Jakarta Commons Developers List Subject: Re: [codec] RE: more common classes need a home Maybe chunked transfer encoding and URL encoding would fit into this package as well somehow? Both of those are very http specific. I'm trying to find a home for all the URI, URIUtil, HttpURL ... classes too, but don't think that should be codec. There were some suggestions like commons-net, but its taken. Perhaps there is enough code for their own package commons-uri. http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] ache.orgmsgNo=23684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] RE: more common classes need a home
On Mon, Feb 03, 2003 at 10:46:23AM -0600, O'brien, Tim wrote: Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was initially from the HttpClient project. The codec Base64 class has an open bug which also should point us in the right direction: http://issues.apache.org/bugzilla/show_bug.cgi?id=16440 So, I'll make a proposal and hope for lazy consensus: Let's replace Base64 in codec with the current HttpClient version. I believe that was actually Scott Sanders (sanders), not Sander Striker (striker) :) -- Scott Sanders - [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [net] Refactoring of ftp2
Well, I have been contributing patches both to ant for over a year and commons-net since it came under jakarta. -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 11:56 AM To: Jakarta Commons Developers List Subject: RE: [net] Refactoring of ftp2 Basically you contribute to an ASF project via patches and general efforts on the mailing lists. Another way is to help with testing pre-releases. See: http://jakarta.apache.org/site/getinvolved.html Hen On Mon, 3 Feb 2003, Winston Ojeda wrote: Don't know, but if you find out let me know. ;) Winston --- Steve Cohen [EMAIL PROTECTED] wrote: Any news on the promotion business? Is there anything I need to do to get voted in as a committer? __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [codec] RE: more common classes need a home
My apologies, Scott, my apologies. Tim O'Brien -Original Message- From: Scott Sanders [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 11:58 AM To: Jakarta Commons Developers List Subject: Re: [codec] RE: more common classes need a home On Mon, Feb 03, 2003 at 10:46:23AM -0600, O'brien, Tim wrote: Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was initially from the HttpClient project. The codec Base64 class has an open bug which also should point us in the right direction: http://issues.apache.org/bugzilla/show_bug.cgi?id=16440 So, I'll make a proposal and hope for lazy consensus: Let's replace Base64 in codec with the current HttpClient version. I believe that was actually Scott Sanders (sanders), not Sander Striker (striker) :) -- Scott Sanders - [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
A new VOTE list commoons-vote
The most recent dicsussion of having a commons-vote list had pretty good support but the thread died away. Not having a dedicated place to vote is a continuous problem for HttpClient, and would be for any other project that is looking towards its own list. When we vote, we have to decide: 1) to post on the commons-httpclient-dev list where people most interested in httpclient hang out (about 130 subscribers) 2) post to the commons-dev list where most of the commons committers are subscribed 3) cross post and risk getting flamed and fragmenting the results to make the result difficult to veryify A dedicated list would completely solve our voting problem. Recently we have seen a number of poorly formed votes on commons. That is just expected in the current framework. The dev list is so casual, that it is natural to expect casual votes. A dedicated vote list would give us well defined location to look to for examples, not 350 messages ago in the archives or somewhere on the website but right there, on the list. I'm not going to propose a vote on this issue myself: I'm just happy being the release prime for HttpClient. I'm certainly willing to help, but this is somthing that should be driven at a higher level. I would be very impressed if someone on the PMC would take up this cause and at least present a proposal here that we can vote on and bring this issue to a close one way or another. -jsd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving commons-sql to db.apache.org
Sounds good to me. Whenever db.apache.org is ready, I'd be only too happy to move dbutils over. Hen On Mon, 3 Feb 2003 [EMAIL PROTECTED] wrote: Not that I'm a committer to it, but commons-dbutils might also seem an appropriate move if there is to be a db-commons. Stephen from:Martin van den Bemt [EMAIL PROTECTED] date:Mon, 03 Feb 2003 17:42:24 to: [EMAIL PROTECTED] subject: Re: Moving commons-sql to db.apache.org 1.. Any possibility of having commiter status for the moved commons-sql ? I am planning on using it a lot the next few weeks. And is there going to be a db-commons or something like that ? Mvgr, Martin On Mon, 2003-02-03 at 17:51, Jason van Zyl wrote: Hi, This pertains to primarily to James and Daniel but I would like to move the commons-sql package over to db.apache.org. I'm in the process of moving OJB and Torque over there so this is the next set of code I want to move. Any objections? -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Proposal new xml tag xml:entity
From: Incze Lajos [EMAIL PROTECTED] On Mon, Feb 03, 2003 at 09:49:04AM +0100, Martin van den Bemt wrote: So maybe there should be an xml:text tag to get this handled (don't use xslt myself though) ? I think it's better to have a jsl:text tag that accepts the disable-output-escaping=yes attribute. You don't need any special xml tag just output an entity name=copy/ tag to the processing chain (the xml taglib will output it transparentely), catch it in a rule and use the jsl:text tag for it. One of my major headache right now is that (Don't want to give you bad tips, that in a document: ?xml version=1.0? !DOCTYPE a [ !ENTITY x y ] ax;/a the dom4j linrary will output (just something like what you want) ?xml version=1.0 encoding=UTF-8? !DOCTYPE aax;/a in a simple read-in/write-out processing (e.g.: AFAIK enabling the capture of internal DOCTYPEs (which is disabled by default) should fix this. e.g. see the extra line I've added... SAXReader xmlReader = new SAXReader(); xmlReader.setIncludeInternalDTDDeclarations(true); Document doc = xmlReader.read(argv[0]); XMLWriter writer = new XMLWriter(System.out); writer.write(doc); writer.flush();) which is not well-formed, so my processing pipe breaks at this point. At any creative solution you 'll find yourself similar problems. James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote el from commons-sandbox to commons-proper
the following concerns me about the proposal: (4) Initial Committers The initial committers will be identical to those of the Standard Taglib project. i'm unhappy with this since it implies that all current taglib committers will be grandfathered in. a list of the people being proposed would be much better. - robert On Monday, February 3, 2003, at 05:33 PM, Jan Luehe wrote: Please cast your vote on the promotion of the commons-el package from commons sandbox to commons proper. The commons-el package contains the EL evaluator code from JSP 2.0. See jakarta-commons-sandbox/el/PROPOSAL.html for more details. commons-el nightly source and binary builds are available at: http://cvs.apache.org/builds/jakarta-commons/nightly/commons-el/ Regards, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Proposal new xml tag xml:entity
There seems to be a few possibilities here. One is that the XML output uses a DTD (internal or external) and you wish to output an entity reference in the output. i.e. the output contains a DOCTYPE and an entity reference to an entity defined in this DOCTYPE. Another option could be that the Jelly script itself uses a DOCTYPE and an entity reference, which is then expanded so that the output does not require a DOCTYPE. Finally using Jelly variables is kinda an alternative to entities - 'macros' can be defined using Jelly variables expressions. I'm thinking in this case the former is probably whats required. So Martin's suggestion of a new tag to output an entity reference... xml:entity name=copy/ which under the covers would call XMLOutput.startEntity( copy ); XMLOutput.endEntity( copy ); sounds a reasonable approach. As Incze says, this would normally generate badly formed XML, unless the output also contains a DOCTYPE declaration which includes the 'copy' entity. James --- http://radio.weblogs.com/0112098/ - Original Message - From: Martin van den Bemt [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, February 03, 2003 8:49 AM Subject: Re: [Jelly] Proposal new xml tag xml:entity So maybe there should be an xml:text tag to get this handled (don't use xslt myself though) ? Mvgr, Martin On Mon, 2003-02-03 at 02:02, Incze Lajos wrote: On Sun, Feb 02, 2003 at 03:11:53PM +0100, Martin van den Bemt wrote: The problem is that it is not about a compliant way to do this, since I can have any entity I define myself in my target xml (based on the DTD). The problem is that the one that parses to the new xml file supports everything that could end up as valid xml in the target. Thats why I think there should be an addition to the current xml (or other) taglib, so we can support those outputs correctly, so we don't have to assume the xml that is doing the parsing also needs to conform to the target dtd. Hope you get my point ;) Mvgr, Martin If it is inevitable that you need to do that, then xsl:text disable-output-escaping=yescopy;/xsl:text should work, but don't know if it was available from jsl. (And this works only if you write a text node, not in an attribute node.) incze - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A new VOTE list commoons-vote
+1 - robert On Monday, February 3, 2003, at 06:12 PM, Jeffrey Dever wrote: The most recent dicsussion of having a commons-vote list had pretty good support but the thread died away. Not having a dedicated place to vote is a continuous problem for HttpClient, and would be for any other project that is looking towards its own list. When we vote, we have to decide: 1) to post on the commons-httpclient-dev list where people most interested in httpclient hang out (about 130 subscribers) 2) post to the commons-dev list where most of the commons committers are subscribed 3) cross post and risk getting flamed and fragmenting the results to make the result difficult to veryify A dedicated list would completely solve our voting problem. Recently we have seen a number of poorly formed votes on commons. That is just expected in the current framework. The dev list is so casual, that it is natural to expect casual votes. A dedicated vote list would give us well defined location to look to for examples, not 350 messages ago in the archives or somewhere on the website but right there, on the list. I'm not going to propose a vote on this issue myself: I'm just happy being the release prime for HttpClient. I'm certainly willing to help, but this is somthing that should be driven at a higher level. I would be very impressed if someone on the PMC would take up this cause and at least present a proposal here that we can vote on and bring this issue to a close one way or another. -jsd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [beanutils][patch] ConstructorUtils javadoc
Seems like your attachment got stripped from the mail. Amybe wrong extension or too big, don't know.. Mvgr, Martin On Mon, 2003-02-03 at 19:22, LOX wrote: I'm sorry, I'm relly new to the Apache lists.. Could somebody explain me what happened? First I sent a mail containing the patch, a minute later I received the mail from the list. So far it's fine, but now I receive the same mail with some kind of default file attached to it. (also my attachment was missing). My adress was in the from fields of the both mails.. What happened actually? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[codec] maybe someone could write something for the jan newsletter?
now that codec has come alive again, anyone feel like volunteering to write something up about codec and the future plans for the january news letter? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/el PROPOSAL.html
luehe 2003/02/03 10:35:56 Modified:el PROPOSAL.html Log: updated list of initial committers Revision ChangesPath 1.2 +10 -4 jakarta-commons-sandbox/el/PROPOSAL.html Index: PROPOSAL.html === RCS file: /home/cvs/jakarta-commons-sandbox/el/PROPOSAL.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- PROPOSAL.html 8 Jan 2003 23:46:14 - 1.1 +++ PROPOSAL.html 3 Feb 2003 18:35:55 - 1.2 @@ -69,8 +69,7 @@ h3(3.1) Mailing list/h3 -The package shall use the jakarta-commons (or jakarta-commons-el, if -approved) mailing list. +The package shall use the jakarta-commons mailing list. h3(3.2) CVS repositories/h3 @@ -87,8 +86,15 @@ h3(4) Initial Committers/h3 -The initial committers will be identical to those of the Standard -Taglib project. +ul + liShawn Bayern/li + liNathan Abramson + liPierre Delisle/li + liHans Bergsten/li + liJustyna Horwat/li + liCraig R. McClanahan/li + liJan Luehe/li +/ul /body /html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester RELEASE-NOTES.txt build.xml
rdonkin 2003/02/03 10:40:28 Modified:digester RELEASE-NOTES.txt build.xml Log: Preparations for digester 1.4 release Revision ChangesPath 1.8 +23 -9 jakarta-commons/digester/RELEASE-NOTES.txt Index: RELEASE-NOTES.txt === RCS file: /home/cvs/jakarta-commons/digester/RELEASE-NOTES.txt,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- RELEASE-NOTES.txt 2 Feb 2003 16:30:29 - 1.7 +++ RELEASE-NOTES.txt 3 Feb 2003 18:40:28 - 1.8 @@ -20,24 +20,33 @@ Digester Enhancements: - -New begin, body and end methods were added that include namespace information. This is an important change since it allows more sophisticated Rules to be created. The old versions of these methods have been deprecated (see below) but existing Rules that override these methods will continue to function correctly. +New begin, body and end methods were added that include namespace information. +This is an important change since it allows more sophisticated Rules to be +created. The old versions of these methods have been deprecated (see below) +but existing Rules that override these methods will continue to function correctly. + +Improved support for XML schema. The scope of schema related variables has been +changed from private to protected. The entity resolver used can now be configured +through a property. -Improved support for XML schema. The scope of schema related variables has been changed from private to protected. The entity resolver used can now be configured through a property. - -Improved support for Public ID. The property now has a setter (as well as a getter). Digester will no longer set a public ID to null. +Improved support for Public ID. The property now has a setter (as well as a getter). +Digester will no longer set a public ID to null. Rules Enhancements: --- -NodeCreateRule is a new rule that creates a DOM node for the matched node. This allows sophisticated approaches mixing DOM with digester. +NodeCreateRule is a new rule that creates a DOM node for the matched node. This +allows sophisticated approaches mixing DOM with digester. -ObjectParamRule is a new rule that works with the CallMethodRule. This allows arbitrary objects to be passed as parameters into a CallMethodRule method call. +ObjectParamRule is a new rule that works with the CallMethodRule. This allows +arbitrary objects to be passed as parameters into a CallMethodRule method call. XMLRule Enhancements: - -Added a new createDigester method which allows the digester to be used to process the xml rules file to be passed in. This allows this digester to be configured so that the xml rules file can be loaded from a jar. +Improved support for loading xmlrules from jars. A new factory method was added +to DigesterLoader together with changes to supporting code. BUG REPORTS ADDRESSED: @@ -53,5 +62,10 @@ DEPRECATION === -The begin, body and end method signatures of org.apache.commons.digester.Rule have now been deprecated. They have been been replaced by new begin, body and end methods whose signatures contain namespace information. Digester now calls these new methods. Existing rules overriding the old signatures will continue to function correctly since each base implementation of these new methods in Rule calls the old ones. +The begin, body and end method signatures of org.apache.commons.digester.Rule +have now been deprecated. They have been been replaced by new begin, body and +end methods whose signatures contain namespace information. Digester now calls these +new methods. Existing rules overriding the old signatures will continue to function +correctly since each base implementation of these new methods in Rule calls +the old ones. 1.34 +2 -2 jakarta-commons/digester/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-commons/digester/build.xml,v retrieving revision 1.33 retrieving revision 1.34 diff -u -r1.33 -r1.34 --- build.xml 2 Feb 2003 16:30:29 - 1.33 +++ build.xml 3 Feb 2003 18:40:28 - 1.34 @@ -55,7 +55,7 @@ property name=component.title value=Digester - XML to Java Object Configuration/ !-- The current version number of this component -- - property name=component.version value=1.4RC1/ + property name=component.version value=1.4/ !-- The base directory for compilation targets -- property name=build.home value=target/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail:
Re: [VOTE] Promote el from commons-sandbox to commons-proper
Robert, (4) Initial Committers The initial committers will be identical to those of the Standard Taglib project. i'm unhappy with this since it implies that all current taglib committers will be grandfathered in. a list of the people being proposed would be much better. OK, I've set the list of initial committers to include the following names: Shawn Bayern Nathan Abramson Pierre Delisle Hans Bergsten Justyna Horwat Craig R. McClanahan Jan Luehe I've also removed jakarta-commons-el from 3.1. The mailing list to be used shall be jakarta-commons. Attached is the updated proposal. Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] 1.6.1 release? [WAS Re: [beanutils] 1.6 releasebreaks Maven and Jelly - fixed!]
On Mon, 3 Feb 2003, robert burrell donkin wrote: Date: Mon, 3 Feb 2003 17:43:22 + From: robert burrell donkin [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: [beanutils] 1.6.1 release? [WAS Re: [beanutils] 1.6 release breaks Maven and Jelly - fixed!] for this to be of any use to maven, it will need to be done quickly. if people are in agreement that a special 1.6.1 release with the aim of fixing this problem for maven and jelly is worthwhile, i'll volunteer to act as release manager. my plan would be to create a branch ASAP and moved as quickly as possible to a release without fixing any other problems which emerge. I'd like to look at the problem report and proposed patch on #16525 as well. One of the main reasons that people are trying to use BeanUtils.setProperty() instead of BeanUtils.copyProperty() -- despite the warning in the Javadocs not to -- is that the former makes some effort to deal with nested and indexed properties, while the latter doesn't at the moment. And Tim was kind enough to offer not only a patch but some test cases as well. I can commit to looking at this tonight (Pacific time), unless Robert beats me to it. But I'd really like to include this in 1.6.1 if we can. (Struts is under the same sort of time pressure as Maven with respect to wanting a released version of beanutils.) - robert Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A new VOTE list commoons-vote
-1 on a voting list separate from the DEV list for a given project. There are two main reasons for my view on this: * People who search the DEV mailing list archives should be able to see both the discussions around design decisions and the votes with a single search; making them look two places is painful. * People who vote should not have the option to do so without subscribing to the DEV list and at least seeing the discussions about what they are voting on (much better, of course, if they actually *participate* in those discussions as well). Commons is a little funny because we've got multiple (somewhat overlapping but basically independent) development groups sharing a single mailing list. However, there is already a mechanism to deal with that -- separate DEV list for a particular component, if the developers of that component so choose (like [ttpclient] did. IMHO, votes on [httpclient] issues should be done where the developers are, which is commons-httpclient-dev, rather than on commons-dev itself. If you've got a separate developers list, it should be used for everything that would otherwise happen on commons-dev. Craig On Mon, 3 Feb 2003, Jeffrey Dever wrote: Date: Mon, 03 Feb 2003 13:12:32 -0500 From: Jeffrey Dever [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: A new VOTE list commoons-vote The most recent dicsussion of having a commons-vote list had pretty good support but the thread died away. Not having a dedicated place to vote is a continuous problem for HttpClient, and would be for any other project that is looking towards its own list. When we vote, we have to decide: 1) to post on the commons-httpclient-dev list where people most interested in httpclient hang out (about 130 subscribers) 2) post to the commons-dev list where most of the commons committers are subscribed 3) cross post and risk getting flamed and fragmenting the results to make the result difficult to veryify A dedicated list would completely solve our voting problem. Recently we have seen a number of poorly formed votes on commons. That is just expected in the current framework. The dev list is so casual, that it is natural to expect casual votes. A dedicated vote list would give us well defined location to look to for examples, not 350 messages ago in the archives or somewhere on the website but right there, on the list. I'm not going to propose a vote on this issue myself: I'm just happy being the release prime for HttpClient. I'm certainly willing to help, but this is somthing that should be driven at a higher level. I would be very impressed if someone on the PMC would take up this cause and at least present a proposal here that we can vote on and bring this issue to a close one way or another. -jsd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16732] New: - Null Pointer Re depends
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16732. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16732 Null Pointer Re depends Summary: Null Pointer Re depends Product: Commons Version: 1.6 Final Platform: All OS/Version: Other Status: NEW Severity: Minor Priority: Other Component: Validator AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When you are using Validator in Struts and you leave out the depends attribute on a field, you get a null pointer exception on line 502 of Validator. There is no way to tell which field is causing this. It would be nice if we checked for a null there and threw an exception providing some info about the field that was causing the problem. I'm not sure if this should be more of a Struts issue or a Validator issue but I'm sure it's costing people a lot of time. I just assumed that the field was not dependent on any validation routines so I just removed the depends attribute. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [codec] maybe someone could write something for the jan newsletter?
Anyone interested in reading a draft, should switch over to general@jakarta list. I'll write a quick draft. Tim O'Brien -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 12:34 PM To: 'Jakarta Commons Developers List' Subject: [codec] maybe someone could write something for the jan newsletter? now that codec has come alive again, anyone feel like volunteering to write something up about codec and the future plans for the january news letter? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[codec] Csv's
I've a CSVReader, CSVWriter, and POI versions [well poi reader yet to be written]. Would these go better in codec or io or not really fitting for Jakarta?? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [beanutils][patch] ConstructorUtils javadoc
Have a go with the txt extension (the headers still showed the mixed/multipart, so that's why I think it was stripped out of the mail). Don't know if it makes any difference though :) Mvgr, Martin On Mon, 2003-02-03 at 19:48, LOX wrote: Seems like your attachment got stripped from the mail. Amybe wrong extension or too big, don't know.. The extension was .patch, the size was 12k.. Plain text patch file... Dimiter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A new VOTE list commoons-vote
-1 Filtering can be done in most mail clients if the right subject prefixes are used. A separate list is not necessary. i.e. use [VOTE][Codec] and not just [VOTE] for votes interesting for all projects you could use [VOTE][COMMONS] or [VOTE][ALL] or similar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] Csv's
The cvsreader afaik is also used in turbine.. Probably fits into io a bit (assuming it's build on that). When I think of codec cvs stuff doesn't really go through my mind to be honest.. Mvgr, martin On Mon, 2003-02-03 at 20:45, Henri Yandell wrote: I've a CSVReader, CSVWriter, and POI versions [well poi reader yet to be written]. Would these go better in codec or io or not really fitting for Jakarta?? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] Csv's
just to check. csv not cvs :) On 3 Feb 2003, Martin van den Bemt wrote: The cvsreader afaik is also used in turbine.. Probably fits into io a bit (assuming it's build on that). When I think of codec cvs stuff doesn't really go through my mind to be honest.. Mvgr, martin On Mon, 2003-02-03 at 20:45, Henri Yandell wrote: I've a CSVReader, CSVWriter, and POI versions [well poi reader yet to be written]. Would these go better in codec or io or not really fitting for Jakarta?? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lang 2.0 Scope Was: [lang] scope for version 2
Hello Allm About: org.apache.commons.lang.functor.* Functor interfaces, grown from initial versions in Collections and Patterns. Does the introduction of this new package mean that Commons Collection will depend on Commons Lang, if not, why not? It would seem to me that creating such a dependency would truly validate this new package, not to speak of reducing code bloat for those of use using multiple Jakarta libraries. I would find it very useful if the documentation for a Jakarta library specified the direction it was taking WRT integration with other Jakarta libraries. I recognize that different components have grown from different needs at different times but I would like to see more thought given to the Jakarta suite as a whole. Is there someone overseing this or does each component live on its own? Thank you for considering these issues, Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 02, 2003 12:18 AM To: Jakarta Commons Developers List Subject: Lang 2.0 Scope Was: [lang] scope for version 2 Any arguments with this? Release of version 2.0 of Commons Lang -- All bugfixes that have entered CVS. Need to be listed at some point. org.apache.commons.lang.math.* Fraction. Various ranges. Bugfix in NumberRange. org.apache.commons.lang.functor.* Functor interfaces, grown from initial versions in Collections and Patterns. org.apache.commons.lang.util.* BitField: Mature class used in POI. Need to confer with POI on this. Validate: It tests boolean possibilities and throws IllegalArgumentExceptions if they are false. Not in scope: === org.apache.commons.lang.time.* org.apache.commons.lang.reflect.* To be Discussed === The order of stack-traces in ExceptionUtils. New trim method variants in StringUtils. New methods in ExceptionUtils. null handling in StringUtils. All open-bugs in Bugzilla. Performance of StringUtils. Initial collection size in Enum. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] Csv's
I just type cvs too often to get CSV typed correctly :) I meant CSV :) btw I like to see them in commons, but it will end up more for db.apache.org if it is left up to me :) (written a simple db system around csv a long while ago..) Mvgr, Martin On Mon, 2003-02-03 at 21:04, Henri Yandell wrote: just to check. csv not cvs :) On 3 Feb 2003, Martin van den Bemt wrote: The cvsreader afaik is also used in turbine.. Probably fits into io a bit (assuming it's build on that). When I think of codec cvs stuff doesn't really go through my mind to be honest.. Mvgr, martin On Mon, 2003-02-03 at 20:45, Henri Yandell wrote: I've a CSVReader, CSVWriter, and POI versions [well poi reader yet to be written]. Would these go better in codec or io or not really fitting for Jakarta?? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lang 2.0 Scope Was: [lang] scope for version 2
On Mon, 3 Feb 2003, Gary Gregory wrote: Hello Allm About: org.apache.commons.lang.functor.* Functor interfaces, grown from initial versions in Collections and Patterns. Does the introduction of this new package mean that Commons Collection will depend on Commons Lang, if not, why not? It would seem to me that creating such a dependency would truly validate this new package, not to speak of reducing code bloat for those of use using multiple Jakarta libraries. It would be intended that Commons Collections would deprecate in favour of the larger set of functors in Lang as I think the functors in Collections form a subset of the ones in Lang. I would find it very useful if the documentation for a Jakarta library specified the direction it was taking WRT integration with other Jakarta libraries. I recognize that different components have grown from different needs at different times but I would like to see more thought given to the Jakarta suite as a whole. Is there someone overseing this or does each component live on its own? Some are quite tied as they have the same committers on each. For example, Stephen and I are both on Lang and Collections. Stephen is on Clazz as well, while Robert is on Lang and BeanUtils [and Digester and others]. These projects are definitely not classic benevelont dictator projects, like Linux, or even Jelly [James Strachan(?)], Maven [Jason van Zyl] or the early Ant [James Duncan Davidson], so having someone with an overall vision/oversight of the future would probably be resisted. Rodney has posted good reasons as to why having one large project with all the reusable bits in together has large negative aspects, so I think you can expect to see the projects continue to exist with overlapping communities. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [beanutils][patch] ConstructorUtils javadoc
here we go again... Index: ConstructorUtils.java === RCS file: /home/cvspublic/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/ConstructorUtils.java,v retrieving revision 1.2 diff -u -r1.2 ConstructorUtils.java --- ConstructorUtils.java 15 Jan 2003 21:59:38 - 1.2 +++ ConstructorUtils.java 3 Feb 2003 14:38:06 - @@ -63,6 +63,21 @@ /** * @version $Revision: 1.2 $ $Date: 2003/01/15 21:59:38 $ + * + * p Utility reflection methods focussed on constructors, modelled after {@link +MethodUtils}. /p + * + * h3Known Limitations/h3 + * h4Accessing Public Constructors In A Default Access Superclass/h4 + * pThere is an issue when invoking public constructors contained in a default +access superclass. + * Reflection locates these constructors fine and correctly assigns them as public. + * However, an codeIllegalAccessException/code is thrown if the constructors is +invoked./p + * + * pcodeConstructorUtils/code contains a workaround for this situation. + * It will attempt to call codesetAccessible/code on this constructor. + * If this call succeeds, then the method can be invoked as normal. + * This call will only succeed when the application has sufficient security +privilages. + * If this call fails then a warning will be logged and the method may fail./p + * * @author Craig R. McClanahan * @author Ralph Schaer * @author Chris Audley @@ -82,6 +97,19 @@ // - Public Methods +/** + * pConvenience method returning new instance of codeklazz/code using a +single argument constructor. + * The formal parameter type is inferred from the actual values of +codearg/code. + * See {@link #invokeExactConstructor(Class, Object[], Class[])} for more +details./p + * + * pThe signatures should be assignment compatible./p + * + * @param klass the class to be constructed. + * @param arg the actual argument + * @return new instance of codeklazz/code + * + * @see #invokeConstructor(java.lang.Class, java.lang.Object[], java.lang.Class[]) + */ public static Object invokeConstructor(Class klass, Object arg) throws NoSuchMethodException, @@ -94,6 +122,19 @@ } +/** + * pReturns new instance of codeklazz/code created using the actual +arguments codeargs/code. + * The formal parameter types are inferred from the actual values of +codeargs/code. + * See {@link #invokeExactConstructor(Class, Object[], Class[])} for more +details./p + * + * pThe signatures should be assignment compatible./p + * + * @param klass the class to be constructed. + * @param args actual argument array + * @return new instance of codeklazz/code + * + * @see #invokeConstructor(java.lang.Class, java.lang.Object[], java.lang.Class[]) + */ public static Object invokeConstructor(Class klass, Object[] args) throws NoSuchMethodException, @@ -113,6 +154,23 @@ } +/** + * pReturns new instance of codeklazz/code created using constructor + * with signature codeparameterTypes/code and actual arguments +codeargs/code./p + * + * pThe signatures should be assignment compatible./p + * + * @param klass the class to be constructed. + * @param args actual argument array + * @param parameterTypes parameter types array + * @return new instance of codeklazz/code + * + * @throws NoSuchMethodException if matching constructor cannot be found + * @throws IllegalAccessException thrown on the constructor's invocation + * @throws InvocationTargetException thrown on the constructor's invocation + * @throws InstantiationException thrown on the constructor's invocation + * @see Constructor#newInstance + */ public static Object invokeConstructor( Class klass, Object[] args, @@ -139,6 +197,20 @@ return ctor.newInstance(args); } + +/** + * pConvenience method returning new instance of codeklazz/code using a +single argument constructor. + * The formal parameter type is inferred from the actual values of +codearg/code. + * See {@link #invokeExactConstructor(Class, Object[], Class[])} for more +details./p + * + * pThe signatures should match exactly./p + * + * @param klass the class to be constructed. + * @param arg the actual argument + * @return new instance of codeklazz/code + * + * @see #invokeExactConstructor(java.lang.Class, java.lang.Object[], +java.lang.Class[]) + */ public static Object invokeExactConstructor(Class klass, Object arg) throws NoSuchMethodException, @@ -150,6 +222,20 @@ return invokeExactConstructor(klass, args); } + +/** + * pReturns new instance of codeklazz/code created using the actual +arguments codeargs/code. +
cvs commit: jakarta-commons/beanutils/src/java/org/apache/commons/beanutils ConstructorUtils.java
mvdb2003/02/03 12:50:49 Modified:beanutils/src/java/org/apache/commons/beanutils ConstructorUtils.java Log: Applying patch supplied by dimiter at blue-edge dot bg In case you're interested here is a patch containing JavaDoc for the ConstructorUtils class. It's not perfect and I have borrowed some parts from the MethodUtils, but I hope it's better than nothing :). Revision ChangesPath 1.3 +141 -2 jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/ConstructorUtils.java Index: ConstructorUtils.java === RCS file: /home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/ConstructorUtils.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ConstructorUtils.java 15 Jan 2003 21:59:38 - 1.2 +++ ConstructorUtils.java 3 Feb 2003 20:50:49 - 1.3 @@ -63,6 +63,21 @@ /** * @version $Revision$ $Date$ + * + * p Utility reflection methods focussed on constructors, modelled after {@link MethodUtils}. /p + * + * h3Known Limitations/h3 + * h4Accessing Public Constructors In A Default Access Superclass/h4 + * pThere is an issue when invoking public constructors contained in a default access superclass. + * Reflection locates these constructors fine and correctly assigns them as public. + * However, an codeIllegalAccessException/code is thrown if the constructors is invoked./p + * + * pcodeConstructorUtils/code contains a workaround for this situation. + * It will attempt to call codesetAccessible/code on this constructor. + * If this call succeeds, then the method can be invoked as normal. + * This call will only succeed when the application has sufficient security privilages. + * If this call fails then a warning will be logged and the method may fail./p + * * @author Craig R. McClanahan * @author Ralph Schaer * @author Chris Audley @@ -82,6 +97,19 @@ // - Public Methods +/** + * pConvenience method returning new instance of codeklazz/code using a single argument constructor. + * The formal parameter type is inferred from the actual values of codearg/code. + * See {@link #invokeExactConstructor(Class, Object[], Class[])} for more details./p + * + * pThe signatures should be assignment compatible./p + * + * @param klass the class to be constructed. + * @param arg the actual argument + * @return new instance of codeklazz/code + * + * @see #invokeConstructor(java.lang.Class, java.lang.Object[], java.lang.Class[]) + */ public static Object invokeConstructor(Class klass, Object arg) throws NoSuchMethodException, @@ -94,6 +122,19 @@ } +/** + * pReturns new instance of codeklazz/code created using the actual arguments codeargs/code. + * The formal parameter types are inferred from the actual values of codeargs/code. + * See {@link #invokeExactConstructor(Class, Object[], Class[])} for more details./p + * + * pThe signatures should be assignment compatible./p + * + * @param klass the class to be constructed. + * @param args actual argument array + * @return new instance of codeklazz/code + * + * @see #invokeConstructor(java.lang.Class, java.lang.Object[], java.lang.Class[]) + */ public static Object invokeConstructor(Class klass, Object[] args) throws NoSuchMethodException, @@ -113,6 +154,23 @@ } +/** + * pReturns new instance of codeklazz/code created using constructor + * with signature codeparameterTypes/code and actual arguments codeargs/code./p + * + * pThe signatures should be assignment compatible./p + * + * @param klass the class to be constructed. + * @param args actual argument array + * @param parameterTypes parameter types array + * @return new instance of codeklazz/code + * + * @throws NoSuchMethodException if matching constructor cannot be found + * @throws IllegalAccessException thrown on the constructor's invocation + * @throws InvocationTargetException thrown on the constructor's invocation + * @throws InstantiationException thrown on the constructor's invocation + * @see Constructor#newInstance + */ public static Object invokeConstructor( Class klass, Object[] args, @@ -139,6 +197,20 @@ return ctor.newInstance(args); } + +/** + * pConvenience method returning new instance of codeklazz/code using a single argument constructor. + * The formal parameter type is inferred from the actual values of codearg/code. + *
RE: [beanutils][patch] ConstructorUtils javadoc
Applied thanx ! Mvgr, Martin On Mon, 2003-02-03 at 20:58, LOX wrote: here we go again... Index: ConstructorUtils.java === RCS file: /home/cvspublic/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/ConstructorUtils.java,v retrieving revision 1.2 diff -u -r1.2 ConstructorUtils.java --- ConstructorUtils.java 15 Jan 2003 21:59:38 - 1.2 +++ ConstructorUtils.java 3 Feb 2003 14:38:06 - @@ -63,6 +63,21 @@ /** * @version $Revision: 1.2 $ $Date: 2003/01/15 21:59:38 $ + * + * p Utility reflection methods focussed on constructors, modelled after {@link MethodUtils}. /p + * + * h3Known Limitations/h3 + * h4Accessing Public Constructors In A Default Access Superclass/h4 + * pThere is an issue when invoking public constructors contained in a default access superclass. + * Reflection locates these constructors fine and correctly assigns them as public. + * However, an codeIllegalAccessException/code is thrown if the constructors is invoked./p + * + * pcodeConstructorUtils/code contains a workaround for this situation. + * It will attempt to call codesetAccessible/code on this constructor. + * If this call succeeds, then the method can be invoked as normal. + * This call will only succeed when the application has sufficient security privilages. + * If this call fails then a warning will be logged and the method may fail./p + * * @author Craig R. McClanahan * @author Ralph Schaer * @author Chris Audley @@ -82,6 +97,19 @@ // - Public Methods +/** + * pConvenience method returning new instance of codeklazz/code using a single argument constructor. + * The formal parameter type is inferred from the actual values of codearg/code. + * See {@link #invokeExactConstructor(Class, Object[], Class[])} for more details./p + * + * pThe signatures should be assignment compatible./p + * + * @param klass the class to be constructed. + * @param arg the actual argument + * @return new instance of codeklazz/code + * + * @see #invokeConstructor(java.lang.Class, java.lang.Object[], java.lang.Class[]) + */ public static Object invokeConstructor(Class klass, Object arg) throws NoSuchMethodException, @@ -94,6 +122,19 @@ } +/** + * pReturns new instance of codeklazz/code created using the actual arguments codeargs/code. + * The formal parameter types are inferred from the actual values of codeargs/code. + * See {@link #invokeExactConstructor(Class, Object[], Class[])} for more details./p + * + * pThe signatures should be assignment compatible./p + * + * @param klass the class to be constructed. + * @param args actual argument array + * @return new instance of codeklazz/code + * + * @see #invokeConstructor(java.lang.Class, java.lang.Object[], java.lang.Class[]) + */ public static Object invokeConstructor(Class klass, Object[] args) throws NoSuchMethodException, @@ -113,6 +154,23 @@ } +/** + * pReturns new instance of codeklazz/code created using constructor + * with signature codeparameterTypes/code and actual arguments codeargs/code./p + * + * pThe signatures should be assignment compatible./p + * + * @param klass the class to be constructed. + * @param args actual argument array + * @param parameterTypes parameter types array + * @return new instance of codeklazz/code + * + * @throws NoSuchMethodException if matching constructor cannot be found + * @throws IllegalAccessException thrown on the constructor's invocation + * @throws InvocationTargetException thrown on the constructor's invocation + * @throws InstantiationException thrown on the constructor's invocation + * @see Constructor#newInstance + */ public static Object invokeConstructor( Class klass, Object[] args, @@ -139,6 +197,20 @@ return ctor.newInstance(args); } + +/** + * pConvenience method returning new instance of codeklazz/code using a single argument constructor. + * The formal parameter type is inferred from the actual values of codearg/code. + * See {@link #invokeExactConstructor(Class, Object[], Class[])} for more details./p + * + * pThe signatures should match exactly./p + * + * @param klass the class to be constructed. + * @param arg the actual argument + * @return new instance of codeklazz/code + * + * @see #invokeExactConstructor(java.lang.Class, java.lang.Object[], java.lang.Class[]) + */ public static Object invokeExactConstructor(Class klass, Object arg) throws NoSuchMethodException, @@ -150,6 +222,20
[ANNOUCEMENT] Commons Digester 1.4 Released
The Jakarta Commons Team is pleased to announce the 1.4 release of Digester from the Apache Software Foundation. Digester is an XML-to-object mapper used for (amongst other things) parsing XML configuration files. This release contains several bug fixes together with enhanced support for XML schema and namespace-aware rules. For more details see http://www.apache.org/dist/jakarta/commons/digester/RELEASE-NOTES.txt The binary distribution is available for downloaded from http://jakarta.apache.org/site/binindex.cgi and the source from http://jakarta.apache.org/site/sourceindex.cgi When downloading from a mirror please check the signature using the keys from the main apache site http://www.apache.org/dist/jakarta/commons/beanutils/KEYS - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Transition of commons-sql to db.apache.org
Hi, If anyone wants to add anything to commons-sql then do so now. I'm going to copy the repo over to db.apache.org and rename the one in the jakarta-commons. Also, if the committers of dbutils and dbcp are interested in moving their stuff over to db.apache.org I will help with that also. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/beanutils/src/java/org/apache/commons/beanutils ConstructorUtils.java
hey martin! since you're now a member of the beanutils team, you need to add your name to the status file :) - robert On Monday, February 3, 2003, at 08:50 PM, [EMAIL PROTECTED] wrote: mvdb2003/02/03 12:50:49 Modified:beanutils/src/java/org/apache/commons/beanutils ConstructorUtils.java Log: Applying patch supplied by dimiter at blue-edge dot bg In case you're interested here is a patch containing JavaDoc for the ConstructorUtils class. It's not perfect and I have borrowed some parts from the MethodUtils, but I hope it's better than nothing :). Revision ChangesPath 1.3 +141 -2jakarta- commons/beanutils/src/java/org/apache/commons/beanutils/ConstructorUtils. java Index: ConstructorUtils.java === RCS file: /home/cvs/jakarta- commons/beanutils/src/java/org/apache/commons/beanutils/ConstructorUtils. java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ConstructorUtils.java 15 Jan 2003 21:59:38 - 1.2 +++ ConstructorUtils.java 3 Feb 2003 20:50:49 - 1.3 @@ -63,6 +63,21 @@ /** * @version $Revision$ $Date$ + * + * p Utility reflection methods focussed on constructors, modelled after {@link MethodUtils}. /p + * + * h3Known Limitations/h3 + * h4Accessing Public Constructors In A Default Access Superclass/h4 + * pThere is an issue when invoking public constructors contained in a default access superclass. + * Reflection locates these constructors fine and correctly assigns them as public. + * However, an codeIllegalAccessException/code is thrown if the constructors is invoked./p + * + * pcodeConstructorUtils/code contains a workaround for this situation. + * It will attempt to call codesetAccessible/code on this constructor. + * If this call succeeds, then the method can be invoked as normal. + * This call will only succeed when the application has sufficient security privilages. + * If this call fails then a warning will be logged and the method may fail./p + * * @author Craig R. McClanahan * @author Ralph Schaer * @author Chris Audley @@ -82,6 +97,19 @@ // - Public Methods +/** + * pConvenience method returning new instance of codeklazz/code using a single argument constructor. + * The formal parameter type is inferred from the actual values of codearg/code. + * See {@link #invokeExactConstructor(Class, Object[], Class[])} for more details./p + * + * pThe signatures should be assignment compatible./p + * + * @param klass the class to be constructed. + * @param arg the actual argument + * @return new instance of codeklazz/code + * + * @see #invokeConstructor(java.lang.Class, java.lang.Object[], java.lang.Class[]) + */ public static Object invokeConstructor(Class klass, Object arg) throws NoSuchMethodException, @@ -94,6 +122,19 @@ } +/** + * pReturns new instance of codeklazz/code created using the actual arguments codeargs/code. + * The formal parameter types are inferred from the actual values of codeargs/code. + * See {@link #invokeExactConstructor(Class, Object[], Class[])} for more details./p + * + * pThe signatures should be assignment compatible./p + * + * @param klass the class to be constructed. + * @param args actual argument array + * @return new instance of codeklazz/code + * + * @see #invokeConstructor(java.lang.Class, java.lang.Object[], java.lang.Class[]) + */ public static Object invokeConstructor(Class klass, Object[] args) throws NoSuchMethodException, @@ -113,6 +154,23 @@ } +/** + * pReturns new instance of codeklazz/code created using constructor + * with signature codeparameterTypes/code and actual arguments codeargs/code./p + * + * pThe signatures should be assignment compatible./p + * + * @param klass the class to be constructed. + * @param args actual argument array + * @param parameterTypes parameter types array + * @return new instance of codeklazz/code + * + * @throws NoSuchMethodException if matching constructor cannot be found + * @throws IllegalAccessException thrown on the constructor's invocation + * @throws InvocationTargetException thrown on the constructor's invocation + * @throws InstantiationException thrown on the constructor's invocation + * @see Constructor#newInstance + */ public static Object invokeConstructor( Class klass, Object[] args, @@ -139,6 +197,20 @@ return ctor.newInstance(args); } + +/** + * pConvenience method returning new instance
Re: cvs commit:jakarta-commons/beanutils/src/java/org/apache/commons/beanutilsConstructorUtils.java
I don't consider myself a developer of beanutils when I apply a patch from someone else ;) But hey, rules are rules :) Mvgr, Martin On Mon, 2003-02-03 at 22:02, robert burrell donkin wrote: hey martin! since you're now a member of the beanutils team, you need to add your name to the status file :) - robert On Monday, February 3, 2003, at 08:50 PM, [EMAIL PROTECTED] wrote: mvdb2003/02/03 12:50:49 Modified:beanutils/src/java/org/apache/commons/beanutils ConstructorUtils.java Log: Applying patch supplied by dimiter at blue-edge dot bg In case you're interested here is a patch containing JavaDoc for the ConstructorUtils class. It's not perfect and I have borrowed some parts from the MethodUtils, but I hope it's better than nothing :). Revision ChangesPath 1.3 +141 -2jakarta- commons/beanutils/src/java/org/apache/commons/beanutils/ConstructorUtils. java Index: ConstructorUtils.java === RCS file: /home/cvs/jakarta- commons/beanutils/src/java/org/apache/commons/beanutils/ConstructorUtils. java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ConstructorUtils.java 15 Jan 2003 21:59:38 - 1.2 +++ ConstructorUtils.java 3 Feb 2003 20:50:49 - 1.3 @@ -63,6 +63,21 @@ /** * @version $Revision$ $Date$ + * + * p Utility reflection methods focussed on constructors, modelled after {@link MethodUtils}. /p + * + * h3Known Limitations/h3 + * h4Accessing Public Constructors In A Default Access Superclass/h4 + * pThere is an issue when invoking public constructors contained in a default access superclass. + * Reflection locates these constructors fine and correctly assigns them as public. + * However, an codeIllegalAccessException/code is thrown if the constructors is invoked./p + * + * pcodeConstructorUtils/code contains a workaround for this situation. + * It will attempt to call codesetAccessible/code on this constructor. + * If this call succeeds, then the method can be invoked as normal. + * This call will only succeed when the application has sufficient security privilages. + * If this call fails then a warning will be logged and the method may fail./p + * * @author Craig R. McClanahan * @author Ralph Schaer * @author Chris Audley @@ -82,6 +97,19 @@ // - Public Methods +/** + * pConvenience method returning new instance of codeklazz/code using a single argument constructor. + * The formal parameter type is inferred from the actual values of codearg/code. + * See {@link #invokeExactConstructor(Class, Object[], Class[])} for more details./p + * + * pThe signatures should be assignment compatible./p + * + * @param klass the class to be constructed. + * @param arg the actual argument + * @return new instance of codeklazz/code + * + * @see #invokeConstructor(java.lang.Class, java.lang.Object[], java.lang.Class[]) + */ public static Object invokeConstructor(Class klass, Object arg) throws NoSuchMethodException, @@ -94,6 +122,19 @@ } +/** + * pReturns new instance of codeklazz/code created using the actual arguments codeargs/code. + * The formal parameter types are inferred from the actual values of codeargs/code. + * See {@link #invokeExactConstructor(Class, Object[], Class[])} for more details./p + * + * pThe signatures should be assignment compatible./p + * + * @param klass the class to be constructed. + * @param args actual argument array + * @return new instance of codeklazz/code + * + * @see #invokeConstructor(java.lang.Class, java.lang.Object[], java.lang.Class[]) + */ public static Object invokeConstructor(Class klass, Object[] args) throws NoSuchMethodException, @@ -113,6 +154,23 @@ } +/** + * pReturns new instance of codeklazz/code created using constructor + * with signature codeparameterTypes/code and actual arguments codeargs/code./p + * + * pThe signatures should be assignment compatible./p + * + * @param klass the class to be constructed. + * @param args actual argument array + * @param parameterTypes parameter types array + * @return new instance of codeklazz/code + * + * @throws NoSuchMethodException if matching constructor cannot be found + * @throws IllegalAccessException thrown on the constructor's invocation
cvs commit: jakarta-commons/digester build.xml
rdonkin 2003/02/03 13:03:19 Modified:digester build.xml Log: Updated to new version number after 1.4 release Revision ChangesPath 1.35 +2 -2 jakarta-commons/digester/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-commons/digester/build.xml,v retrieving revision 1.34 retrieving revision 1.35 diff -u -r1.34 -r1.35 --- build.xml 3 Feb 2003 18:40:28 - 1.34 +++ build.xml 3 Feb 2003 21:03:19 - 1.35 @@ -55,7 +55,7 @@ property name=component.title value=Digester - XML to Java Object Configuration/ !-- The current version number of this component -- - property name=component.version value=1.4/ + property name=component.version value=1.5-dev/ !-- The base directory for compilation targets -- property name=build.home value=target/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestMethodsNoHost.java TestWebappPostMethod.java
olegk 2003/02/03 13:21:20 Modified:httpclient/src/java/org/apache/commons/httpclient HttpConstants.java httpclient/src/java/org/apache/commons/httpclient/methods PostMethod.java httpclient/src/test/org/apache/commons/httpclient TestMethodsNoHost.java TestWebappPostMethod.java Log: - fixes the problem with request content-encoding not taken into account when url-enconding parameters in POST method - adds test case to ensure appropriate encoding of non-ascii characters such as German umlauts in POST method parameters Problem reported by Mathis Thomas Contributed by Oleg Kalnichevski Revision ChangesPath 1.5 +4 -4 jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConstants.java Index: HttpConstants.java === RCS file: /home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConstants.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- HttpConstants.java28 Jan 2003 04:40:20 - 1.4 +++ HttpConstants.java3 Feb 2003 21:21:15 - 1.5 @@ -81,7 +81,7 @@ public static final String HTTP_ELEMENT_CHARSET = US-ASCII; /** Default content encoding chatset */ -protected static final String DEFAULT_CONTENT_CHARSET = ISO-8859-1; +public static final String DEFAULT_CONTENT_CHARSET = ISO-8859-1; /** Log object for this class. */ private static final Log LOG = LogFactory.getLog(HttpConstants.class); 1.38 +21 -15 jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/PostMethod.java Index: PostMethod.java === RCS file: /home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/PostMethod.java,v retrieving revision 1.37 retrieving revision 1.38 diff -u -r1.37 -r1.38 --- PostMethod.java 2 Feb 2003 04:30:13 - 1.37 +++ PostMethod.java 3 Feb 2003 21:21:19 - 1.38 @@ -123,9 +123,9 @@ /** My content encoding. */ private int contentEncoding = CUSTOM_CONTENT; -/** The Content-Type header for www-form-urlcoded. */ -public static final Header URL_ENCODED_CONTENT_TYPE = new Header(Content-Type, -application/x-www-form-urlencoded); +/** The Content-Type for www-form-urlcoded. */ +public static final String FORM_URL_ENCODED_CONTENT_TYPE = +application/x-www-form-urlencoded; /** * The buffered request body consisting of codeNameValuePair/codes. @@ -434,7 +434,7 @@ * * @throws IllegalArgumentException if parameters is null */ -protected static String generateRequestBody(NameValuePair[] parameters) +protected static String generateRequestBody(NameValuePair[] parameters, final String charset) throws IllegalArgumentException { LOG.trace(enter PostMethod.generateRequestBody(NameValuePair[])); @@ -452,9 +452,11 @@ String queryName = null; try { -queryName = URIUtil.encodeWithinQuery(parameter.getName()); -} catch (URIException urie) { -LOG.error(encoding error within query name, urie); +queryName = URIUtil.encodeWithinQuery(parameter.getName(), charset); +} catch (URIException e) { +if (LOG.isWarnEnabled()) { +LOG.warn(Encosing error: + e.toString()); +} queryName = parameter.getName(); } @@ -462,9 +464,11 @@ String queryValue = null; try { -queryValue = URIUtil.encodeWithinQuery(parameter.getValue()); +queryValue = URIUtil.encodeWithinQuery(parameter.getValue(), charset); } catch (URIException e) { -LOG.error(Encoding error within query value, e); +if (LOG.isWarnEnabled()) { +LOG.warn(Encosing error: + e.toString()); +} queryValue = parameter.getValue(); } buff.append(queryValue); @@ -529,7 +533,7 @@ if (parametersBody == null) { throw new IllegalArgumentException(Array of parameters may not be null); } -super.setRequestBody(generateRequestBody(parametersBody)); +super.setRequestBody(generateRequestBody(parametersBody, getRequestCharSet())); this.contentEncoding = URL_ENCODED_CONTENT; } @@ -551,7 +555,9 @@ if (this.contentEncoding == URL_ENCODED_CONTENT) { //there are some parameters, so set the contentType header -
cvs commit: jakarta-commons/modeler/src/java/org/apache/commons/modeler AttributeInfo.java
costin 2003/02/03 13:42:32 Modified:modeler/src/java/org/apache/commons/modeler AttributeInfo.java Log: Some implementation of JMX require it to be false (it is used for base mbean, not for model mbeans ) Revision ChangesPath 1.5 +5 -5 jakarta-commons/modeler/src/java/org/apache/commons/modeler/AttributeInfo.java Index: AttributeInfo.java === RCS file: /home/cvs/jakarta-commons/modeler/src/java/org/apache/commons/modeler/AttributeInfo.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- AttributeInfo.java23 Jan 2003 19:42:03 - 1.4 +++ AttributeInfo.java3 Feb 2003 21:42:32 - 1.5 @@ -255,7 +255,7 @@ // Create and return a new information object info = new ModelMBeanAttributeInfo (getName(), getType(), getDescription(), - isReadable(), isWriteable(), isIs()); + isReadable(), isWriteable(), false); Descriptor descriptor = info.getDescriptor(); if (getDisplayName() != null) descriptor.setField(displayName, getDisplayName()); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[codec] choosing a Base64, brings up some larger issues...
Here's some analysis: These four classes are what I'm working from right now. Base64.java in [codec] started out in HttpClient. XML-RPC also took the same Base64 source and it looks like XML-RPC has given Base64 the most attention over the last few months, fixing bugs, etc. I propose that [codec] take the Base64 class from the XML-RPC group, as it looks to be the most definitive in the group below. We'll present this interface to the world, and deal with requests to change the interface as they come in - initially, I'd lke to get this to work for the HttpClient team. If there are no objections in the next day or so, I'll make this happen. Here are links to the various ViewCVS pages: http://cvs.apache.org/viewcvs/xml-rpc/src/java/org/apache/xmlrpc/Base64.java http://cvs.apache.org/viewcvs/jakarta-commons/httpclient/src/java/org/apache /commons/httpclient/util/Base64.java http://cvs.apache.org/viewcvs/xml-rpc/src/java/org/apache/xmlrpc/Base64.java Excluding files in the Attic, or unit tests, we've got about 35 classes ASF-wide dealing with Base64. I think that to minimize the scope of this task, we should first focus on the needs of Jakarta. In the future this looks like something that could be in Apache Commons. There is clearly a need for base64 encoding via a method, and via a Stream or Reader. From my perspective, it isn't necessarily the goal of [codec] to create a slick reusable model to support pluggable encoders and decoders - as we currently have this for our language encoders. For Base64, I think it is a priority to settle on a definitive implementation to reduce the amount of duplication across subproject and PMC boundaries. Jakarta PMC: ./jakarta-slide/src/util/org/apache/util/Base64.java,v ./jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/Base64.java ,v ./jakarta-jmeter/src/protocol/http/org/apache/jmeter/protocol/http/util/Base 64Encoder.java,v ./jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/util/Bas e64.java,v ./jakarta-jetspeed/src/java/org/apache/jetspeed/util/Base64.java,v ./jakarta-commons-sandbox/util/src/java/org/apache/commons/util/Attic/Base64 .java,v ./jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/base64/Bas e64.java,v ./jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/Base64.java ,v James PMC: ./jakarta-james/src/java/org/apache/james/util/Base64.java,v Ant PMC: ./jakarta-ant/proposal/sandbox/httptasks/src/main/org/apache/tools/ant/taskd efs/optional/http/Base64Encode.java,v XML PMC: ./xml-xerces/java/src/org/apache/xerces/impl/dv/xs/Base64BinaryDV.java,v ./xml-xerces/java/src/org/apache/xerces/impl/dv/util/Base64.java,v ./xml-xang/java/src/org/apache/xang/util/base64/Base64.java,v ./xml-contrib/spinnaker/util/org/apache/auc/Base64.java,v ./xml-batik/sources/org/apache/batik/util/Base64DecodeStream.java,v ./xml-batik/sources/org/apache/batik/util/Base64EncoderStream.java,v ./xml-security/src/org/apache/xml/security/exceptions/Base64DecodingExceptio n.java,v ./xml-security/src/org/apache/xml/security/utils/Base64.java,v Web Services PMC: ./xml-soap/java/src/org/apache/soap/encoding/soapenc/Base64Serializer.java,v ./xml-soap/java/src/org/apache/soap/encoding/soapenc/Base64.java,v ./xml-soap/java/test/encoding/soapenc/Base64Test.java,v ./xml-axis/java/src/org/apache/axis/utils/Base64.java,v ./xml-axis/java/src/org/apache/axis/encoding/Base64.java,v ./xml-axis/java/src/org/apache/axis/encoding/ser/Base64Deserializer.java,v ./xml-axis/java/src/org/apache/axis/encoding/ser/Base64DeserializerFactory.j ava,v ./xml-axis/java/src/org/apache/axis/encoding/ser/Base64Serializer.java,v ./xml-axis/java/src/org/apache/axis/encoding/ser/Base64SerializerFactory.jav a,v ./xml-rpc/src/java/org/apache/xmlrpc/Base64.java,v ./xml-rpc/src/test/org/apache/xmlrpc/Base64Test.java,v DB PMC: ./db-ojb/src/java/org/apache/ojb/broker/util/Base64.java,v Tim O'Brien -Original Message- From: Jeffrey Dever [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 2:28 PM To: O'brien, Tim Cc: 'Commons HttpClient Project' Subject: Re: Moving Base64 in HttpClient to commons-codec Tim, I think that what Ryan is saying here, is that xml-rpc has a Base64 that is also based on HttpClients (or some other ancestor like Slide) that has some fixes and improvements that the current HttpClient one does not have. So you might want to diff with the xml-rpc one to see what is different. That will motivate them to use the codec package as well, which is good for everyone. O'brien, Tim wrote: I will commit the current version of Base64 from the HttpClient project in jakarta-commons-sandbox/codec/src/java/org/apache/commons/cod ec/binary/Base6 4.java, the existing [codec] Base64 class (based off of an old HttpClient Base64) will be deprecated for a week and then removed. Tim O'Brien -Original Message- From: Jeffrey Dever [mailto:[EMAIL
Re: Transition of commons-sql to db.apache.org
I think I'd like to see dbcp follow dbutils, since we're in the processing of refactoring some of the dbcp code out to dbutils. I don't know if anyone else has an opinion on this however. On Mon, 3 Feb 2003, Jason van Zyl wrote: Hi, If anyone wants to add anything to commons-sql then do so now. I'm going to copy the repo over to db.apache.org and rename the one in the jakarta-commons. Also, if the committers of dbutils and dbcp are interested in moving their stuff over to db.apache.org I will help with that also. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16525] - BeanUtils.setProperty is over-zealous at converting types
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16525 BeanUtils.setProperty is over-zealous at converting types --- Additional Comments From [EMAIL PROTECTED] 2003-02-03 23:52 --- W.R.T. the first patch I agree. It was more a case of The current behaviour breaks a previously existing usage, this change would allow that behaviour back. I don't think it should be applied it just helped to illustrate why the curren behaviour doesn't work. The 2nd patch is my proposal, but as you say, it is quite large. I wouldn't rush out a release that uses it, I'd probably hold it for a 1.6.5 or 1.7 (as oppposed to a 1.6.1 that contains Craig's DyanBean change). My guess is that Struts is the biggest user of setProperty() so if this change works with struts, then it's probably safe. W.R.T the new class, it's package scoped, so I think your fears are alleviated by that - I could have made it an inner class or included it another compilation unit, but that tends not to be a style I opt for. I'm happy if you want to change it, but I'm not sure there's a problem (unless I'm missing something) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Transition of commons-sql to db.apache.org
For us uninitiated, could someone give a short dissertation on what is db.apache.org and why it would make sense to move these over? Not objecting, but inquiring minds would like to know. TIA 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: Rodney Waldhoff [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 6:26 PM To: Jakarta Commons Developers List Subject: Re: Transition of commons-sql to db.apache.org I think I'd like to see dbcp follow dbutils, since we're in the processing of refactoring some of the dbcp code out to dbutils. I don't know if anyone else has an opinion on this however. On Mon, 3 Feb 2003, Jason van Zyl wrote: Hi, If anyone wants to add anything to commons-sql then do so now. I'm going to copy the repo over to db.apache.org and rename the one in the jakarta-commons. Also, if the committers of dbutils and dbcp are interested in moving their stuff over to db.apache.org I will help with that also. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/el - Imported sources
luehe 2003/02/03 16:22:32 Log: Import of EL source files Status: Vendor Tag: commons_el Release Tags: r1-0 N jakarta-commons/el/project.properties N jakarta-commons/el/LICENSE.txt N jakarta-commons/el/PROPOSAL.html N jakarta-commons/el/build.xml N jakarta-commons/el/maven.xml N jakarta-commons/el/build.properties.sample N jakarta-commons/el/project.xml N jakarta-commons/el/build.properties N jakarta-commons/el/src/conf/MANIFEST.MF N jakarta-commons/el/src/java/org/apache/commons/el/ArithmeticOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/AndOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/BeanInfoManager.java N jakarta-commons/el/src/java/org/apache/commons/el/ArraySuffix.java N jakarta-commons/el/src/java/org/apache/commons/el/BeanInfoIndexedProperty.java N jakarta-commons/el/src/java/org/apache/commons/el/BeanInfoProperty.java N jakarta-commons/el/src/java/org/apache/commons/el/BinaryOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/BinaryOperatorExpression.java N jakarta-commons/el/src/java/org/apache/commons/el/BooleanLiteral.java N jakarta-commons/el/src/java/org/apache/commons/el/Coercions.java N jakarta-commons/el/src/java/org/apache/commons/el/ComplexValue.java N jakarta-commons/el/src/java/org/apache/commons/el/Constants.java N jakarta-commons/el/src/java/org/apache/commons/el/DivideOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/ELParser.jj N jakarta-commons/el/src/java/org/apache/commons/el/EmptyOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/FloatingPointLiteral.java N jakarta-commons/el/src/java/org/apache/commons/el/EnumeratedMap.java N jakarta-commons/el/src/java/org/apache/commons/el/EqualityOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/EqualsOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/Expression.java N jakarta-commons/el/src/java/org/apache/commons/el/ExpressionString.java N jakarta-commons/el/src/java/org/apache/commons/el/ExpressionEvaluatorImpl.java N jakarta-commons/el/src/java/org/apache/commons/el/FunctionInvocation.java N jakarta-commons/el/src/java/org/apache/commons/el/GreaterThanOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/GreaterThanOrEqualsOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/ImplicitObjects.java N jakarta-commons/el/src/java/org/apache/commons/el/IntegerDivideOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/IntegerLiteral.java N jakarta-commons/el/src/java/org/apache/commons/el/LessThanOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/LessThanOrEqualsOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/Literal.java N jakarta-commons/el/src/java/org/apache/commons/el/Logger.java N jakarta-commons/el/src/java/org/apache/commons/el/MinusOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/ModulusOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/MultiplyOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/NamedValue.java N jakarta-commons/el/src/java/org/apache/commons/el/NotEqualsOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/NotOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/NullLiteral.java N jakarta-commons/el/src/java/org/apache/commons/el/OrOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/PlusOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/PrimitiveObjects.java N jakarta-commons/el/src/java/org/apache/commons/el/PropertySuffix.java N jakarta-commons/el/src/java/org/apache/commons/el/RelationalOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/Resources.properties N jakarta-commons/el/src/java/org/apache/commons/el/Resources_ja.properties N jakarta-commons/el/src/java/org/apache/commons/el/StringLiteral.java N jakarta-commons/el/src/java/org/apache/commons/el/UnaryOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/UnaryMinusOperator.java N jakarta-commons/el/src/java/org/apache/commons/el/UnaryOperatorExpression.java N jakarta-commons/el/src/java/org/apache/commons/el/ValueSuffix.java N jakarta-commons/el/src/java/org/apache/commons/el/VariableResolverImpl.java N jakarta-commons/el/src/java/org/apache/commons/el/parser/ELParser.java N jakarta-commons/el/src/java/org/apache/commons/el/parser/ParseException.java N jakarta-commons/el/src/java/org/apache/commons/el/parser/ELParserConstants.java N jakarta-commons/el/src/java/org/apache/commons/el/parser/ELParserTokenManager.java N jakarta-commons/el/src/java/org/apache/commons/el/parser/SimpleCharStream.java N jakarta-commons/el/src/java/org/apache/commons/el/parser/Token.java N jakarta-commons/el/src/java/org/apache/commons/el/parser/TokenMgrError.java N
DO NOT REPLY [Bug 16744] New: - Allow special positioning of error messages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16744. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16744 Allow special positioning of error messages Summary: Allow special positioning of error messages Product: Commons Version: 1.0 Final Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Validator AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We have identified a case when it would be handy if you could set the key for a validation in the configuration file. Unfortunately, the key is replaced by generateKey when it is called. It would be nice if it did not generate a key if one already existed. Why? That way you can create two different validations for the same field and have them displayed at different places on the screen. e.g. A message like You must have at least one item in your cart could be given a different key and then displayed at the top of the page using the errors tag while the same field could have a format validation and have the errors tag next to it on the page. I hope this makes sense as it is a little hard to explain. Send me an email if you need more. Thanks...Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EL] Unable to remove jakarta-commons/el/[dist/target]
When I did a cvs import for jakarta-commons/el, I accidentally also imported the jakarta-commons/el/dist and jakarta-commons/el/target dirs which were created after executing ant dist. I've tried to remove them from the repository, but keep getting this error message: Access denied: Insufficient Karma (luehe|jakarta-commons/el/dist) etc. Any help appreciated. Thanks, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DBCP deadlock patch
Has anyone looked at the bug #16581? I've attached a patch which merely propagates the idle eviction properties to BasicDataSourceFactory. -- Gerald TurnerEmail: [EMAIL PROTECTED]Phone: (503) 788-1720 GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EL] Unable to remove jakarta-commons/el/[dist/target]
On Mon, 3 Feb 2003, Jan Luehe wrote: Date: Mon, 3 Feb 2003 18:55:03 -0800 (PST) From: Jan Luehe [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED], Jan Luehe [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [EL] Unable to remove jakarta-commons/el/[dist/target] When I did a cvs import for jakarta-commons/el, I accidentally also imported the jakarta-commons/el/dist and jakarta-commons/el/target dirs which were created after executing ant dist. I've tried to remove them from the repository, but keep getting this error message: Access denied: Insufficient Karma (luehe|jakarta-commons/el/dist) etc. Any help appreciated. I just fixed your commit karma, so you can successfully cvs delete things that should not be there now. Thanks, Jan Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec Soundex.java RefinedSoundex.java Metaphone.java
tobrien 2003/02/03 20:43:36 Modified:codec/src/java/org/apache/commons/codec Soundex.java RefinedSoundex.java Metaphone.java Log: deprecated language codecs in codec package, well remove in 1 week Revision ChangesPath 1.7 +3 -3 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/Soundex.java Index: Soundex.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/Soundex.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- Soundex.java 3 Feb 2003 16:03:54 - 1.6 +++ Soundex.java 4 Feb 2003 04:43:35 - 1.7 @@ -61,11 +61,11 @@ * * http://www.bluepoof.com/Soundex/info2.html * - * @todo Needs internationalisation in a future release. - * * @author [EMAIL PROTECTED] * @author [EMAIL PROTECTED] * @version $Revision$ $Date$ + * + * @deprecated This class has been moved to {@link org.apache.commons.codec.language.Soundex} */ public class Soundex implements Encoder { 1.6 +3 -3 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/RefinedSoundex.java Index: RefinedSoundex.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/RefinedSoundex.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- RefinedSoundex.java 3 Feb 2003 16:03:54 - 1.5 +++ RefinedSoundex.java 4 Feb 2003 04:43:35 - 1.6 @@ -60,10 +60,10 @@ * scheme to find word with similar phonemes. * More information may be found at: http://www.bluepoof.com/Soundex/info2.html * - * @todo Needs internationalisation in a future release. - * * @author [EMAIL PROTECTED] * @version $Revision$ $Date$ + * + * @deprecated This class has been moved to {@link org.apache.commons.codec.language.RefinedSoundex} */ public class RefinedSoundex implements Encoder { 1.7 +4 -2 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/Metaphone.java Index: Metaphone.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/Metaphone.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- Metaphone.java3 Feb 2003 16:03:54 - 1.6 +++ Metaphone.java4 Feb 2003 04:43:35 - 1.7 @@ -58,13 +58,15 @@ * The initial Java implementation, William B. Brogden. December, 1997 * Permission given by wbrogden for code to be used anywhere. * - * @see Hanging on the Metaphone by Lawrence Philips + * Hanging on the Metaphone by Lawrence Philips * iComputer Language/i of Dec. 1990, p 39 * * @version $Revision$ $Date$ * @author [EMAIL PROTECTED] * @author [EMAIL PROTECTED] * @author [EMAIL PROTECTED] + * + * @deprecated This class has been moved to {@link org.apache.commons.codec.language.Metaphone} */ public class Metaphone implements Encoder { - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language Metaphone.java RefinedSoundex.java Soundex.java DoubleMetaphone.java Nysiis.java
tobrien 2003/02/03 20:43:59 Modified:codec/src/java/org/apache/commons/codec/language DoubleMetaphone.java Nysiis.java Added: codec/src/java/org/apache/commons/codec/language Metaphone.java RefinedSoundex.java Soundex.java Log: Moved language codecs to language package Revision ChangesPath 1.3 +2 -2 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java Index: DoubleMetaphone.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- DoubleMetaphone.java 3 Feb 2003 16:03:54 - 1.2 +++ DoubleMetaphone.java 4 Feb 2003 04:43:58 - 1.3 @@ -62,7 +62,7 @@ * bPLEASE NOTE:/b This implementation is not thread-safe. Please * see TODO list for [codec] - Tim O'Brien * - * @see http://www.cse.ucsc.edu/~eparrish/toolbox/search.html + * @see a href=http://www.cse.ucsc.edu/~eparrish/toolbox/search.html;Ed Parrish, Developing a Search Engine/a * * @version $Revision$ * @author Ed Parish 1.3 +4 -8 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language/Nysiis.java Index: Nysiis.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language/Nysiis.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- Nysiis.java 3 Feb 2003 16:02:16 - 1.2 +++ Nysiis.java 4 Feb 2003 04:43:58 - 1.3 @@ -61,13 +61,9 @@ * the code from the Perl module available from CPAN, which derives from an * implementation by Ben Kennedy. * - * @see http://www.nist.gov/dads/HTML/nysiis.html - * @see http://search.cpan.org/search?query=nysiismode=all - * - * @see Atack, J., and F. Bateman. 1992 . - * iMatchmaker, matchmaker, make me a match/i : a general - * computer-based matching program for historical researc. - * Historical Methods 25: 53-65. + * @see a href=http://www.nist.gov/dads/HTML/nysiis.html;NIST Nysiis definition/a + * @see a href=http://search.cpan.org/search?query=nysiismode=all;Nysiis implementation at CPAN/a + * @see a href=http://www.ssha.org/mainsite/news/methodsad.html;Atack, J., and F. Bateman. 1992 . iMatchmaker, matchmaker, make me a match/i : a general computer-based matching program for historical researc. Historical Methods 25: 53-65./a * * @version $Revision$ * @author a href=[EMAIL PROTECTED]Kyle R. Burton/a 1.1 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language/Metaphone.java Index: Metaphone.java === /* * The Apache Software License, Version 1.1 * * Copyright (c) 2001-2002 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, *if any, must include the following acknowledgment: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgment may appear in the software itself, *if and wherever such third-party acknowledgments normally appear. * * 4. The names Apache and Apache Software Foundation and *Apache Commons must not be used to endorse or promote products *derived from this software without prior written permission. For *written permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache, *Apache Commons, nor may Apache appear in their name, without *prior written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS
cvs commit: jakarta-commons-sandbox/codec/src/test/org/apache/commons/codec/language TestMetaphone.java TestRefinedSoundex.java TestSoundex.java
tobrien 2003/02/03 20:46:01 Modified:codec/src/test/org/apache/commons/codec TestAll.java Added: codec/src/test/org/apache/commons/codec/language TestMetaphone.java TestRefinedSoundex.java TestSoundex.java Removed: codec/src/test/org/apache/commons/codec TestMetaphone.java TestRefinedSoundex.java TestSoundex.java Log: migrated language tests to language package Revision ChangesPath 1.5 +5 -6 jakarta-commons-sandbox/codec/src/test/org/apache/commons/codec/TestAll.java Index: TestAll.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/test/org/apache/commons/codec/TestAll.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- TestAll.java 3 Feb 2003 15:48:14 - 1.4 +++ TestAll.java 4 Feb 2003 04:46:01 - 1.5 @@ -61,8 +61,7 @@ package org.apache.commons.codec; -import org.apache.commons.codec.language.TestDoubleMetaphone; -import org.apache.commons.codec.language.TestNysiis; +import org.apache.commons.codec.language.*; import junit.framework.Test; import junit.framework.TestCase; 1.1 jakarta-commons-sandbox/codec/src/test/org/apache/commons/codec/language/TestMetaphone.java Index: TestMetaphone.java === /* * $Header: /home/cvs/jakarta-commons-sandbox/codec/src/test/org/apache/commons/codec/language/TestMetaphone.java,v 1.1 2003/02/04 04:46:01 tobrien Exp $ * $Revision: 1.1 $ * $Date: 2003/02/04 04:46:01 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 2002 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names The Jakarta Project, Commons, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. * */ package org.apache.commons.codec.language; import junit.framework.Test; import junit.framework.TestCase; import junit.framework.TestSuite; import org.apache.commons.codec.Encoder; import org.apache.commons.codec.TestEncoder; /** * @version $Revision: 1.1 $ $Date: 2003/02/04 04:46:01 $ * @author Rodney Waldhoff */ public class TestMetaphone extends TestEncoder { public TestMetaphone(String name) { super(name); } public static Test suite() {
cvs commit: jakarta-commons-sandbox/codec build.xml
tobrien 2003/02/03 20:46:29 Modified:codecbuild.xml Log: Removed dedicated base64 test target Revision ChangesPath 1.7 +2 -2 jakarta-commons-sandbox/codec/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-commons-sandbox/codec/build.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- build.xml 18 Nov 2002 12:41:24 - 1.6 +++ build.xml 4 Feb 2003 04:46:29 - 1.7 @@ -111,7 +111,7 @@ version=true doctitle=lt;h1gt;${component.title}lt;/h1gt; windowtitle=${component.title} (Version ${component.version}) - bottom=Copyright (c) 2001-2002 - Apache Software Foundation + bottom=Copyright (c) 2001-2003 - Apache Software Foundation classpath refid=compile.classpath/ /javadoc /target - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/codec TODO
tobrien 2003/02/03 20:49:00 Modified:codecTODO Log: updated TODO list Revision ChangesPath 1.5 +3 -2 jakarta-commons-sandbox/codec/TODO Index: TODO === RCS file: /home/cvs/jakarta-commons-sandbox/codec/TODO,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- TODO 3 Feb 2003 20:44:43 - 1.4 +++ TODO 4 Feb 2003 04:49:00 - 1.5 @@ -13,6 +13,8 @@ ** TODO List +* Delete language encoders in codec package by 2/10 + * Add a ship encode and decode * Add a btoa encode and decode @@ -27,8 +29,6 @@ * Add a Rot13 implementation -* Move phonetic encoders into dedicated package. - * Add a Decoder interface * Refactor Base64 to implement both Encoder and Decoder @@ -47,6 +47,7 @@ ** DONE +2/3/03 - TOB - Moved phonetic encoders into dedicated language package. 2/3/03 - TOB - Added Nysiis code and tests from Kyle Burton 2/3/03 - TOB - Added DoubleMetaphone code and tests from Kyle Burton 2/2/03 - TOB - language package created to hold language and phonetic encodings - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote el from commons-sandbox to commons-proper
On Mon, 3 Feb 2003, Jan Luehe wrote: Robert, (4) Initial Committers The initial committers will be identical to those of the Standard Taglib project. i'm unhappy with this since it implies that all current taglib committers will be grandfathered in. a list of the people being proposed would be much better. OK, I've set the list of initial committers to include the following names: Shawn Bayern Nathan Abramson Pierre Delisle Hans Bergsten Justyna Horwat Craig R. McClanahan Jan Luehe I've also removed jakarta-commons-el from 3.1. The mailing list to be used shall be jakarta-commons. Attached is the updated proposal. +1 -- Martin Cooper Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] release?
On Sun, 2 Feb 2003, robert burrell donkin wrote: On Saturday, February 1, 2003, at 07:33 AM, Martin Cooper wrote: On Wed, 29 Jan 2003, robert burrell donkin wrote: we've had some requests from users who wanted to download a file upload release. it'd be good to have a definite release for file upload even if it's only an alpha or a beta. i don't really have much idea about what's holding a release up but if it's the lack of a release manager, i'd be willing to volunteer. Sorry, I've been off air for a few days. Yes, we should probably get a beta release out sooner rather than later. IMHO, we can reasonably skip alpha, since both Struts and Turbine have been using this component for a while. I had been anticipating doing the RM thing, and am still willing to step up to the plate. excellent :) There are basically three issues holding up a *final* release of FileUpload: 1) Two outstanding bugs in Bugzilla that need to be addressed. 2) Lack of comprehensive unit tests. What's there now is very limited. 3) Lack of documentation web site organisation (e.g. download links). We can probably shoot for a beta release without these being resolved, although we really do need to sort out the web site. What's there now is a bare-bones Maven-generated site, and at this time I don't know enough about how Maven generates sites to know how to get this into shape. Seemingly simple things like modifying the navigation bar, and getting the window title to say what I want it to say, are still a mystery to me. If someone more Maven-savvy than myself is willing to help sort out the web site, and, in particular, add download links for the nightly builds, and a slot for links to a forthcoming beta, then I think we could get a beta 1 release into the world in fairly short order. i'd be willing to sort out a basic site using maven if you're happy to have me aboard as a file upload committer. Absolutely! Thanks! -- Martin Cooper - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] basic maven-based site
On Mon, 3 Feb 2003, robert burrell donkin wrote: i've committed a basic maven based site for fileupload. shouldn't be too hard to tweak it into shape (even for maven newbies ;) Cool! Looks like the ball is in my court now... ;-) -- Martin Cooper - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] moving code to commons proper
On Mon, 3 Feb 2003, robert burrell donkin wrote: the code for jexl is in the sandbox. now that jexl has been promoted, this code needs to be moved into the commons repository and the commons web site updated. unless anyone else jumps in, i'll volunteer to make the move. I have moved (actually, copied, for now) the jexl code from the sandbox to Commons Proper, preserving all of the history. I have *not* made any attempt to adjust the build, or anything else, for its new location, though. Let me know if you see any problems with the move itself. Once it's sorted out, we'll need to fix the Gump descriptor too. -- Martin Cooper - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/binary - New directory
tobrien 2003/02/03 21:46:47 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/binary - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/codec/src/test/org/apache/commons/codec/binary - New directory
tobrien 2003/02/03 21:48:30 jakarta-commons-sandbox/codec/src/test/org/apache/commons/codec/binary - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/codec/src/test/org/apache/commons/codec/binary TestBase64.java
tobrien 2003/02/03 21:50:00 Modified:codecTODO codec/src/java/org/apache/commons/codec/base64 Base64.java codec/src/test/org/apache/commons/codec TestAll.java Added: codec/src/java/org/apache/commons/codec/binary Base64.java codec/src/test/org/apache/commons/codec/binary TestBase64.java Log: Added Base64 impl from xml-rpc courtesy of M. Redington Revision ChangesPath 1.6 +10 -6 jakarta-commons-sandbox/codec/TODO Index: TODO === RCS file: /home/cvs/jakarta-commons-sandbox/codec/TODO,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- TODO 4 Feb 2003 04:49:00 - 1.5 +++ TODO 4 Feb 2003 05:50:00 - 1.6 @@ -15,19 +15,23 @@ * Delete language encoders in codec package by 2/10 -* Add a ship encode and decode +* move additional string encoding/decoding method from deprecated Base64 to improved Base64 -* Add a btoa encode and decode +* add flags to new Base64 for the enforcement of different levels of RFC compliance. + +* Add a ship encode and decode to binary package + +* Add a btoa encode and decode to binary package * Move Base64 from HttpClient to Codec -* Add a BinHex endode and decode +* Add a BinHex endode and decode to binary package -* Add a uu encode and decode +* Add a uu encode and decode to binary package -* Add a Hex implementation +* Add a Hex implementation to binary package -* Add a Rot13 implementation +* Add a Rot13 implementation to text package * Add a Decoder interface 1.5 +6 -4 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/base64/Base64.java Index: Base64.java === RCS file: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/base64/Base64.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- Base64.java 30 May 2002 16:14:30 - 1.4 +++ Base64.java 4 Feb 2003 05:50:00 - 1.5 @@ -77,6 +77,8 @@ * /p * @author Jeffrey Rodriguez * @version $Revision$ $Date$ + * + * @deprecated This class has been replaced by {@link org.apache.commons.codec.binary.Base64} */ public final class Base64 { 1.1 jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/binary/Base64.java Index: Base64.java === package org.apache.commons.codec.binary; /* * $Header: /home/cvs/jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/binary/Base64.java,v 1.1 2003/02/04 05:50:00 tobrien Exp $ * $Revision: 1.1 $ * $Date: 2003/02/04 05:50:00 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names The Jakarta Project, Tomcat, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS
RE: [codec] base64 improved....
Is there such a thing as conceptual dyslexia? I think I have it.. I left out a parameter... Redo those signatures: public static byte[] encode( byte[] binaryData ) throws EncoderException public static byte[] encode( byte[] binaryData, boolean addNewline, int errorLevel ) throws EncoderException * Where errorLevel would be either Base64.IGNORE, Base64.WARN, or Base64.EXCEPTION Tim O'Brien -Original Message- From: O'brien, Tim [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 12:08 AM To: Jakarta Commons Developers List Subject: [codec] base64 improved An improved Base64 was added to a binary subpackage of codec. Martin Redington who is involved in xml-rpc submitted this version of the class as he has been actively contributing to the xml-rpc effort. This new version of the Base64 class improves performance of the decode and also is more compatible with RFC. There is a thread on rpc-dev to this effect: http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]m sgNo=713 So, [codec] now contains an implementation compatible with the xml-rpc project, and the next step is to reconcile this version with the needs of [httpclient]. Possible controversy here may be that the RFC was interpreted as requiring a terminating newline. The RFC also mentions that a warning or exception should be thrown when the encoder/decoder encounters invalid characters or whitespace. My proposal is that we add a series of boolean flags, int fields to the method signature to allow client projects to specify different levels of RFC compliance. public static byte[] encode( byte[] binaryData ) throws EncoderException public static byte[] encode( byte[] binaryData, int errorLevel ) throws EncoderException Where errorLevel would be either Base64.IGNORE, Base64.WARN, or Base64.EXCEPTION Tim O'Brien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [codec] base64 improved....
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] My proposal is that we add a series of boolean flags, int fields to the method signature to allow client projects to specify different levels of RFC compliance. Alternatively you could support an ErrorHandler interface, and delegate to that (as SAX does) NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/codec RELEASE-PLAN
tobrien 2003/02/03 22:37:42 Added: codecRELEASE-PLAN Log: Added a release plan Revision ChangesPath 1.1 jakarta-commons-sandbox/codec/RELEASE-PLAN Index: RELEASE-PLAN === Jakarta Commons Codec *** Release Plan This document outline the current goals for the next release. This document defines objectives and action items that should be met before the next release. Longer term goals should be placed in the file named ROADMAP. Objective: The main objective of 1.1 release is to package a definitive implementation of Base64 and Hex in addition to the phonetic encoders currently implemented in the language package. It is the objective of the [codec] project to provide a point of consolidation for [binary|text|language] codecs. The 1.1 release will be a foundation for further expansion of the available binary encoders and decoders, but it should be noted that the objective is to provide an implementation of Base64 and Hex - byte[] and IO stream. Status: * As described in the TODO Codec 1.1 Beta: * Code freeze date: Feb 15, 2003 * Tag date: Feb 17, 2003 * Goals: * Cut a release which can be used to as the base for performing tests and reporting bugs. * Evaluate and clean up as many bugs that are there jakarta.apache.org/bugs. Codec 1.1 Final: * Code freeze date: Feb 25, 2003 * Tag date: Mar 1, 2003 * Goals: * Fix bugs reported on the beta and subsequent builds. * Evaluate after the code freeze date if codec 1.1 is ready to be called final. * Build out documentation using Forrest * Release Manager: To be determined - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/codec TODO
tobrien 2003/02/03 22:37:58 Modified:codecTODO Log: updated TODO Revision ChangesPath 1.7 +1 -0 jakarta-commons-sandbox/codec/TODO Index: TODO === RCS file: /home/cvs/jakarta-commons-sandbox/codec/TODO,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- TODO 4 Feb 2003 05:50:00 - 1.6 +++ TODO 4 Feb 2003 06:37:58 - 1.7 @@ -51,6 +51,7 @@ ** DONE +2/4/03 - TOB - Integrated a Base64 impl from xml-rpc - Martin Redington 2/3/03 - TOB - Moved phonetic encoders into dedicated language package. 2/3/03 - TOB - Added Nysiis code and tests from Kyle Burton 2/3/03 - TOB - Added DoubleMetaphone code and tests from Kyle Burton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] RE: more common classes need a home
I tried to read to the end of the thread so far before replying. If the feeling is that the classes will see more use distributed separately from HttpClient, I concur with Henri's assessment below. In message [EMAIL PROTECTED], Hen ri Yandell writes: I'm +1 to commons-uri. As Tim points out, it's not just URLs, so we could even have pieces of code for dealing with ISBNs etc if the need arose. I don't think they really tie well to commons-io, and losing them in commons-net would be a mistake probably. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils/src/test/org/apache/commons/beanutils BeanUtilsTestCase.java DynaBeanUtilsTestCase.java
craigmcc2003/02/03 23:28:14 Modified:beanutils/src/java/org/apache/commons/beanutils BeanUtils.java beanutils/src/test/org/apache/commons/beanutils BeanUtilsTestCase.java DynaBeanUtilsTestCase.java Log: Enhance BeanUtils.copyProperty() to deal with about 80% of the use cases for copying indexed, mapped, and nested properties with type conversions. The remaining restrictions are documented in the Javadocs for this method. This is a partial response to Bugzilla #16525, which documents some restrictions in the functionality of copyProperty() that leads people to try setProperty() instead -- which they should not do. It is much more conservative than the proposed patch, which (as the reporter acknowledges) is more appropriate in a minor update (1.7) versus a bugfix patch (1.6.1) which is currently contemplated. PR: Bugzilla #16525 Submitted by: Tim Vernum tpv at spamcop.net Revision ChangesPath 1.36 +147 -62 jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/BeanUtils.java Index: BeanUtils.java === RCS file: /home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/BeanUtils.java,v retrieving revision 1.35 retrieving revision 1.36 diff -u -r1.35 -r1.36 --- BeanUtils.java15 Jan 2003 21:59:38 - 1.35 +++ BeanUtils.java4 Feb 2003 07:28:14 - 1.36 @@ -153,7 +153,7 @@ * @exception InvocationTargetException if the property accessor method * throws an exception * @exception NoSuchMethodException if an accessor method for this - * propety cannot be found + * property cannot be found */ public static Object cloneBean(Object bean) throws IllegalAccessException, InstantiationException, @@ -275,18 +275,28 @@ /** * pCopy the specified property value to the specified destination bean, * performing any type conversion that is required. If the specified - * bean does not have a property of the specified name, return without + * bean does not have a property of the specified name, or the property + * is read only on the destination bean, return without * doing anything. If you have custom destination property types, register * {@link Converter}s for them by calling the coderegister()/code * method of {@link ConvertUtils}./p * - * pstrongFIXME/strong - Indexed and mapped properties that do not - * have getter and setter methods for the underlying array or Map are not - * copied by this method./p + * pstrongIMPLEMENTATION RESTRICTIONS/strong:/p + * ul + * liDoes not support destination properties that are indexed, + * but only an indexed setter (as opposed to an array setter) + * is available./li + * liDoes not support destination properties that are mapped, + * but only a keyed setter (as opposed to a Map setter) + * is available./li + * liThe desired property type of a mapped setter cannot be + * determined (since Maps support any data type), so no conversion + * will be performed./li + * /ul * * @param bean Bean on which setting is to be performed - * @param name Simple property name of the property to be set - * @param value Property value to be set + * @param name Property name (can be nested/indexed/mapped/combo) + * @param value Value to be set * * @exception IllegalAccessException if the caller does not have * access to the property accessor method @@ -296,6 +306,7 @@ public static void copyProperty(Object bean, String name, Object value) throws IllegalAccessException, InvocationTargetException { +// Trace logging (if enabled) if (log.isTraceEnabled()) { StringBuffer sb = new StringBuffer( copyProperty(); sb.append(bean); @@ -323,55 +334,123 @@ log.trace(sb.toString()); } -if (bean instanceof DynaBean) { -DynaProperty propDescriptor = -((DynaBean) bean).getDynaClass().getDynaProperty(name); -if (propDescriptor != null) { -Converter converter = -ConvertUtils.lookup(propDescriptor.getType()); -if (converter != null) { -value = converter.convert(propDescriptor.getType(), value); -} -try { -PropertyUtils.setSimpleProperty(bean, name, value); -} catch (NoSuchMethodException e) { -log.error(--Should not have happened, e); -; // Silently ignored +// Resolve any nested expression
DO NOT REPLY [Bug 16525] - BeanUtils.setProperty is over-zealous at converting types
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16525 BeanUtils.setProperty is over-zealous at converting types [EMAIL PROTECTED] changed: What|Removed |Added Severity|Blocker |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2003-02-04 07:35 --- I've applied a more conservative version of the proposed patch to copyProperty(), which covers about 80% of the use cases for indexed and mapped properties, and 100% of the use cases for nested properties. The existing functionality of setProperty remains untouched. This is available in nightly build 20030204 of commons-beanutils, and is very likely to be made available in a 1.6.1 patch release of commons-beanutils. The concept of abstracting out a common BeanPropertySpecifier is an *excellent* idea, and will offer many opportunities to reduce the code bloat that has grown in the (nearly) three years of the existence of BeanUtils. Yet, I agree with Tim's assessment that this is more appropriate for a major (2.0) or minor (1.7) version change, rather than a 1.6.1 patch release that is urgently desired by several projects. When we decide to formally review this idea, we should also evaluate whether it makes sense to use something like the commons-clazz project APIs to represent the metadata about a bean property that works across standard JavaBeans and DynaBeans, or go ahead and implement a commons-beanutils-proprietary API like BeanPropertySpecifier. Because the majority of use cases are fixed by the checked-in patch, changing this to an enhancement request so it won't get forgotten. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: POST method - Default content encoding
Is that fixed now? I tested this issue with HttpClient 2.0 alpha2 and the result was the same (wrong encoding)! Thomas -Ursprüngliche Nachricht- Von: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 15. Januar 2003 10:22 An: Commons HttpClient Project Betreff: RE: POST method - Default content encoding Thomas It undoubtedly *should* be ISO-8859-1 by default. Currently system default encoding is used regardless of the 'Content-Type' header value. We are aware of the bug. I have already posted a patch that fixes (well, attempts to fix) all known encoding related problems. Unfortunately, all our committers are currently either missing in action or too busy. So, please, stay tuned. The fix is expected soon Oleg -Original Message- From: Mathis Thomas (VTG) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 10:11 AM To: 'Commons HttpClient Project' Subject: POST method - Default content encoding I think that the default encoding for a post should also be ISO-8859-1, is that right? With the latest nightly build I sent a post to a server with german umlauts and these characters were endoded with UTF-8. I used following code: PostMethod post = new PostMethod(); post.setHttp11( true ); post.setPath( /samplepath ); post.addParameter( TXT, Testtext: öäüÖÄÜß); String s; try { //post.setRequestHeader( Content-Type, text/plain; charset=ISO-8859-1 ); int ret = client.executeMethod( post ); s = post.getRequestBodyAsString(); System.out.println( requestBody= + s ); } catch (Exception ex ) { ex.printStackTrace(); } The output is : requestBody=TXT=Testtext%3A%20%C3%B6%C3%A4%C3%BC%C3%96%C3%84%C3%9C%C3%9F but schould be: requestBody=TXT=Testtext%3A%20%F6%E4%FC%D6%C4%DC%DF Even if I use the outcommented line it does not change the output. Thanks in advance, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running out of connections
There is one further alternative to Jeffrey's suggestion. You can call executeMethod, then get the response stream, then call close() on that. The close on the response stream will trigger the right sequence of events. -Eric. Simon Roberts wrote: I guess the problem is really mine. I was somewhat expecting the connection to be released after it gets a connection: close. /** * A test that illustrates the problem with connections not being recovered from a Connection: close response. */ public void testConnectionPool() throws IOException, HttpException { final MultiThreadedHttpConnectionManager manager = new MultiThreadedHttpConnectionManager(); HttpClient httpClient = new HttpClient(manager); httpClient.getHostConfiguration().setHost(www.slashdot.org, 80, http); httpClient.setHttpConnectionFactoryTimeout(2000); // wait up to 2 seconds when getting a HttpConnection for (int i = 0; i 30; i++) { HttpMethod method = new GetMethod(http://www.slashdot.org/notfound;); int res = httpClient.executeMethod(method); // System.gc(); // method.releaseConnection(); } } Uncommenting either of the last two lines makes the problem go away... - Original Message - From: Michael Becke [EMAIL PROTECTED] To: Commons HttpClient Project [EMAIL PROTECTED] Sent: Sunday, February 02, 2003 6:18 AM Subject: Re: Running out of connections Hello Simon, Sorry to be replying so late. Connections are released when: 1) the response is fully read 2) the connection is manually released via HttpMethod.releaseConnection() or HttpConnection.releaseConnection() 3) the garbage collector runs and reclaims any connections that are no longer being used The most reliable way is to manually release the connection after use. This goes for successful or unsuccessful requests. Can you send a sample of the code you are using that causes this problem? Mike On Wednesday, January 29, 2003, at 09:04 PM, Simon Roberts wrote: Gidday, With the current CVS version, I seem to be having a problem where I run out of connections to a server. It happens if I do a bunch of HTTP operations that fail (404, as it happens) and the reply include a Connection: close. If no garbage-collect happens then the connections are not freed! Shouldn't we expire them if we're running out of connections? Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15654] - HttpMethodBase does not handle response headers with missing ':'
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15654. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15654 HttpMethodBase does not handle response headers with missing ':' [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID Target Milestone|2.0 Beta 1 |--- --- Additional Comments From [EMAIL PROTECTED] 2003-02-03 15:02 --- I honestly can't accept that any server that does not seperate header names from header values with a ':' is worth anything at all. If the server does this, the manufacturer should be notified and the problem corrected by the broken server. HttpClient will not be modified to accomodate. I tested the url in question, http://www.porsche.com, and found that the response headers are well formed. There is a redirect to a web hosting service, Netidentity, running IIS which works perfectly using HttpClient. Marking this bug as INVALID - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with recycling methods - use case
Michael Becke wrote: [snip] I've been looking into this a little more and I'm actually not sure if AutoCloseInputStream should close the stream or not. I vaguely remember when this was first written and the various interactions are quite complex. In most cases the AutoCloseInputStream is not wrapping the actual socket stream. Usually there is another stream in the middle, either a ContentLengthInputStream or ChunkedInputStream. Both of which do not close the socket stream. The only case a socket input stream will be closed is when there is no chunking or content length. For this case it is difficult to determine when the response content is complete and therefore when it can be reused. In this case it might actually be reasonable to close the socket stream and force a reconnect. What does everyone think? I spent quite a while crawling over this part of the code, and it seems to me that if you don't have a content length or chunked encoding on the response, the RFC indicates that the only way for the client to detect the end of the content on the response is to actually close the socket. In the case where the AutoCloseInputStream wraps the raw socket, the raw socket should be closed, because the server is going to close it anyway. I went over this code carefully to try to insure that calling close on the getResponseBodyAsStream() result would _always_ be safe. As a result, there is a fairly intricate dance between the stream wrapper, the method, and the connection manager, so that they all stay in sync with each other, and the appropriate amount of data from a persistent connection will be read, rather than attempting to scan to find the next occurrence of HTTP/1.1 in the byte stream. -Eric. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]