DO NOT REPLY [Bug 16525] - BeanUtils.setProperty is over-zealous at converting types

2003-02-03 Thread bugzilla
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

2003-02-03 Thread bugzilla
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

2003-02-03 Thread James Strachan
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

2003-02-03 Thread bugzilla
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

2003-02-03 Thread tobrien
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

2003-02-03 Thread Roper, Michael
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 L’OREAL 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

2003-02-03 Thread mvdb
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

2003-02-03 Thread Incze Lajos
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

2003-02-03 Thread tobrien
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

2003-02-03 Thread tobrien
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

2003-02-03 Thread bugzilla
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

2003-02-03 Thread bugzilla
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

2003-02-03 Thread tobrien
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

2003-02-03 Thread O'brien, Tim
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

2003-02-03 Thread bayard
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

2003-02-03 Thread bayard
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

2003-02-03 Thread Henri Yandell

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

2003-02-03 Thread Roper, Michael
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

2003-02-03 Thread O'brien, Tim
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

2003-02-03 Thread O'brien, Tim
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

2003-02-03 Thread Jason van Zyl
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?

2003-02-03 Thread Alan Marcinkowski
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

2003-02-03 Thread Jeffrey Dever
+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

2003-02-03 Thread Henri Yandell

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?

2003-02-03 Thread Jan Luehe
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

2003-02-03 Thread Ortwin Glück
+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

2003-02-03 Thread Henri Yandell

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

2003-02-03 Thread O'brien, Tim
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

2003-02-03 Thread rdonkin
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

2003-02-03 Thread jstrachan
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

2003-02-03 Thread rdonkin
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

2003-02-03 Thread Henri Yandell

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

2003-02-03 Thread Scott Sanders
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

2003-02-03 Thread Steve Cohen
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

2003-02-03 Thread O'brien, Tim
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

2003-02-03 Thread Jeffrey Dever
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

2003-02-03 Thread Henri Yandell

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

2003-02-03 Thread James Strachan
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

2003-02-03 Thread robert burrell donkin
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

2003-02-03 Thread James Strachan
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

2003-02-03 Thread robert burrell donkin
+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

2003-02-03 Thread Martin van den Bemt
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?

2003-02-03 Thread robert burrell donkin
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

2003-02-03 Thread luehe
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

2003-02-03 Thread rdonkin
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

2003-02-03 Thread Jan Luehe
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!]

2003-02-03 Thread Craig R. McClanahan


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

2003-02-03 Thread Craig R. McClanahan

-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

2003-02-03 Thread bugzilla
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?

2003-02-03 Thread O'brien, Tim
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

2003-02-03 Thread Henri Yandell

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

2003-02-03 Thread Martin van den Bemt
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

2003-02-03 Thread Ortwin Glück
-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

2003-02-03 Thread Martin van den Bemt
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

2003-02-03 Thread Henri Yandell
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

2003-02-03 Thread Gary Gregory
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

2003-02-03 Thread Martin van den Bemt
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

2003-02-03 Thread Henri Yandell


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

2003-02-03 Thread LOX
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

2003-02-03 Thread mvdb
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

2003-02-03 Thread Martin van den Bemt
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

2003-02-03 Thread robert burrell donkin
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

2003-02-03 Thread Jason van Zyl
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

2003-02-03 Thread robert burrell donkin
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

2003-02-03 Thread Martin van den Bemt
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

2003-02-03 Thread rdonkin
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

2003-02-03 Thread olegk
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

2003-02-03 Thread costin
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...

2003-02-03 Thread O'brien, Tim
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

2003-02-03 Thread Rodney Waldhoff
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

2003-02-03 Thread bugzilla
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

2003-02-03 Thread Steven Caswell
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

2003-02-03 Thread luehe
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

2003-02-03 Thread bugzilla
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]

2003-02-03 Thread Jan Luehe
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

2003-02-03 Thread Gerald Turner
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]

2003-02-03 Thread Craig R. McClanahan


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

2003-02-03 Thread tobrien
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

2003-02-03 Thread tobrien
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

2003-02-03 Thread tobrien
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

2003-02-03 Thread tobrien
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

2003-02-03 Thread tobrien
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

2003-02-03 Thread Martin Cooper


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?

2003-02-03 Thread Martin Cooper


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

2003-02-03 Thread Martin Cooper


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

2003-02-03 Thread Martin Cooper


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

2003-02-03 Thread tobrien
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

2003-02-03 Thread tobrien
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

2003-02-03 Thread tobrien
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....

2003-02-03 Thread O'brien, Tim
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....

2003-02-03 Thread Tim Vernum
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

2003-02-03 Thread tobrien
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

2003-02-03 Thread tobrien
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

2003-02-03 Thread Daniel F. Savarese

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

2003-02-03 Thread craigmcc
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

2003-02-03 Thread bugzilla
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

2003-02-03 Thread Mathis Thomas (VTG)
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

2003-02-03 Thread Eric Johnson
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 ':'

2003-02-03 Thread bugzilla
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

2003-02-03 Thread Eric Johnson
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]



  1   2   >