date:20031112

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=22692.
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=22692

StringUtils.split ignores empty items





--- Additional Comments From [EMAIL PROTECTED]  2003-11-12 14:56 ---
Created an attachment (id=9070)
Delimited Tokenizer source code

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SUBMITING new StringUtils.method

2003-11-12 Thread Inger, Matthew

Is there any way to delete an attachment.  I uploaded a newver
version of the code (to allow for passing of a char[] in the
constructor in addition to String).


-Original Message-
From: Arun Thomas [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 11, 2003 7:29 PM
To: Jakarta Commons Developers List
Subject: SUBMITING new StringUtils.method


Goto http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22692

Attach your source and test files.

-AMT

P.S. 

// defaults to true
public boolean isIgnoreLeadingWhitespace();
public void setIgnoreLeadingWhitespace(boolean ignoreLeadingWhitespace);

// defaults to true
public boolean isIgnoreTrailingWhitespace();
public void setIgnoreTrailingWhitespace(boolean
ignoreTrailingWhitespace);

// defaults to false
public boolean isTreatEmptyAsNull();
public void setTreatEmptyAsNull(boolean treatEmptyAsNull);

The is methods read strangely to me.  I think they may read better for
both the is and set methods if the signatures were as follows:

// defaults to true
public boolean isIgnoringLeadingWhitespace();
public void setIgnoringLeadingWhitespace(boolean
ignoreLeadingWhitespace);

// defaults to true
public boolean isIgnoringTrailingWhitespace();
public void setIgnoringTrailingWhitespace(boolean
ignoreTrailingWhitespace);

// defaults to false
public boolean isTreatingEmptyAsNull();
public void setTreatingEmptyAsNull(boolean treatEmptyAsNull);


-Original Message-
From: Inger, Matthew [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 11, 2003 4:08 PM
To: 'Jakarta Commons Developers List'
Subject: RE: suggestion for new StringUtils.method


I've come up with the following class for this.
(I also have a test class which tests a few of the
 simple cases).  Token parsing is done semi-lazily,
in that when the first token is requested (or the
token count), the whole thing is parsed.  And the
reset forgets about the tokens, so you can change
parameters, and re-parse.


public class DelimitedTokenizer
{
public static final char DEFAULT_DELIMITER = ',';
public static final char DEFAULT_QUOTE = '';
public static final String WHITESPACE =  \t\n\r;

public DelimitedTokenizer(String input);
public DelimitedTokenizer(String input, char delim);
public DelimitedTokenizer(String input, char delim, char quote);

public char getDelim();
public void setDelim(char delim);

public char getQuote();
public void setQuote(char quote);

// defaults to true
public boolean isIgnoreLeadingWhitespace();
public void setIgnoreLeadingWhitespace(boolean ignoreLeadingWhitespace);

// defaults to true
public boolean isIgnoreTrailingWhitespace();
public void setIgnoreTrailingWhitespace(boolean
ignoreTrailingWhitespace);

// defaults to false
public boolean isTreatEmptyAsNull();
public void setTreatEmptyAsNull(boolean treatEmptyAsNull);

public int countTokens();
public String nextToken();
public void reset();
public String [] getAllTokens();
}


Now the question is how to submit it

-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 11, 2003 2:28 PM
To: Jakarta Commons Developers List
Subject: Re: suggestion for new StringUtils.method


Inger, Matthew wrote:
 String [] undelimit(String input, char separatorChar, char quoteChar);

It's a tokenizer. It would be handy to have it as an iterator pattern too
(like StringTokenizer).

J.Pietschmann



-
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 22692] - StringUtils.split ignores empty items

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=22692.
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=22692

StringUtils.split ignores empty items





--- Additional Comments From [EMAIL PROTECTED]  2003-11-12 14:59 ---
The attachment uploaded at 14:56 supercedes the one uploaded at 13:20

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [betwixt] Betwixt troubles...

2003-11-12 Thread Martin van den Bemt

You don't have to resend :)

Mvgr,
Martin

On Wed, 2003-11-12 at 15:37, Mike Stanley wrote:
 ok.
 
 and yes you have permission to use it in any way that matters.  I just
 looked it over though, and I accidentally included copyright disclaimers at
 the top of some of the files.  I will resend them without the disclaimers.
 It was written from scratch, no real world code used, completely
 fictitious -- my class templates include the disclaimer and I just forgot to
 remove it in some places.  I can either resend it with this stuff removed -
 or - give you permission to remove it and add the APL to it.  Whatever
 satisfies the legal requirement.  Your call.
 
 Thanks, and like I said before I'd be more than happy to look into / patch
 the issue(s).  Just waiting for confirmation.
 
 - Mike
 
  -Original Message-
  From: Martin van den Bemt [mailto:[EMAIL PROTECTED]
  Sent: Wednesday, November 12, 2003 9:21 AM
  To: Jakarta Commons Developers List
  Subject: RE: [betwixt] Betwixt troubles...
 
 
  I'll try to find some time to confirm it tonight, but since a lot of
  family matters atm, that time can be consumed by that..
  Do we have permission (when needed) to add your scenario to the betwixt
  CVS tree ? (and therefor give it an apache license?)
 
  Mvgr,
  Martin
 
  On Wed, 2003-11-12 at 15:12, Mike Stanley wrote:
   Please confirm this is a bug, or please offer some advice on
  what I'm doing
   wrong.  If this isn't sufficient to confirm the bug please let
  me know, and
   I will modify the example.
  
   - Mike
  
-Original Message-
From: Mike Stanley [mailto:[EMAIL PROTECTED]
Sent: Monday, November 10, 2003 2:07 PM
To: Jakarta Commons Developers List
Subject: RE: [betwixt] Betwixt troubles...
   
   
here is a zipped up eclipse project (minus the jar dependencies).
 There is
a unit test that demonstrates the bug that I'm talking about.
The unit test
has to test methods, testGetAsXml which passes, and testParseMsg which
fails.
   
Aside from the betwixt dependencies, this project is also dependent on
log4j, and commons-lang.  Hope this provides a decent enough
  demo of the
bugs.
   
Note: I've tried this with the alpha release of betwixt, as
  well as the
snapshot from 2/11/2003.  When using the snapshot, the
  testGetAsXml fails
with a null pointer exception.  The alpha release shows the
marshalling/unmarshalling behavior noted in this thread.  I also tried
variations on the parser configurations.
   
Thanks for the help.
- Mike
   
 -Original Message-
 From: Martin van den Bemt [mailto:[EMAIL PROTECTED]
 Sent: Sunday, November 09, 2003 12:14 PM
 To: Jakarta Commons Developers List
 Subject: RE: Betwixt troubles...


 Can you supply us with a tescase that shows us the
  bahaviour (esp that
 you believe it is a bug), since there is too little info in
  the mail to
 test this (we needs the beans / bean. One thing I know is that eg
 Bean.betwixt files only supplies beaninfo for Bean.java and
  not for any
 classes embedded in Bean.java.

 Mvgr,
 Martin

 On Fri, 2003-11-07 at 19:51, Mike Stanley wrote:
  Please note: I sent this to the developers list and not the
users list,
  because I believe it to be a bug, and if confirmed - I
  may patch it.
 
  - Mike
 
   -Original Message-
   From: Mike Stanley [mailto:[EMAIL PROTECTED]
   Sent: Friday, November 07, 2003 1:26 PM
   To: Jakarta Commons Dev
   Subject: Betwixt troubles...
  
  
   Hey everyone,
  
   I'm running into an issue with some Betwixt code.  I'm trying to
   Write/Read
   a bean associated with .betwixt file.
  
   I can't seem to get attributes to be set when reading in the
 xml.  writing
   works fine.  I've tried several ways (including defaulting to
   primitiveTypes
   and specificing an updater method).  Here is the content of
the file:
  
   ?xml version=1.0 encoding=UTF-8?
   info primitiveTypes=attribute
   element name=rcss
   attribute property=type/
   element name=requests
   element name=isValid
   element name=agent-id
   attribute name=value
  property=agentId/
   /element
   !-- element name=agent-id
  property=agentId
   updater=setAgentId/ --
   /element
   /element
   /element
   /info
  
   
   Results form a write:
  
   ?xml version='1.0' ?
   rcss type=request src=167.154.203.22
  requestor=install_app
   requests
   isValid cert=Z0123456789
   agent-id value=01/
   /isValid
   /requests
   /rcss
  
   ---
   Results from read:

[logging] Resolving Logj4 issue

The Log4J issue on geronimo-dev@ brought out the suggestion that Log4J
(right place) or Commons Logging (expedient place) add TRACE level support
to the core code, thus relieving each app from having to do it.

I also suggest that geronimo-dev give serious consideration to adopting
Log4J v1.3, on the grounds that it will be the Release version long before
Geronimo is ready for Release, and Log4J has changes that effect this code
area.

If either of those things happen, I believe that the Log4J issue goes away.

Having said that, I leave it to the Log4J, Commons Logging, and Geronimo
Committers to resolve it.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SUBMITING new StringUtils.method

2003-11-12 Thread Arun Thomas

Alas, not in the version of bugzilla in use here.  I add Replaces date time to the 
beginning of my description for the new attachment.  If that hides too much of the 
description, then I add a comment which identifies what attachement is being replaced. 
 

-AMT

-Original Message-
From: Inger, Matthew [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 12, 2003 6:59 AM
To: 'Jakarta Commons Developers List'
Subject: RE: SUBMITING new StringUtils.method


Is there any way to delete an attachment.  I uploaded a newver version of the code (to 
allow for passing of a char[] in the constructor in addition to String).


-Original Message-
From: Arun Thomas [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 11, 2003 7:29 PM
To: Jakarta Commons Developers List
Subject: SUBMITING new StringUtils.method


Goto http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22692

Attach your source and test files.

-AMT

P.S. 

// defaults to true
public boolean isIgnoreLeadingWhitespace();
public void setIgnoreLeadingWhitespace(boolean ignoreLeadingWhitespace);

// defaults to true
public boolean isIgnoreTrailingWhitespace();
public void setIgnoreTrailingWhitespace(boolean
ignoreTrailingWhitespace);

// defaults to false
public boolean isTreatEmptyAsNull();
public void setTreatEmptyAsNull(boolean treatEmptyAsNull);

The is methods read strangely to me.  I think they may read better for both the is 
and set methods if the signatures were as follows:

// defaults to true
public boolean isIgnoringLeadingWhitespace();
public void setIgnoringLeadingWhitespace(boolean
ignoreLeadingWhitespace);

// defaults to true
public boolean isIgnoringTrailingWhitespace();
public void setIgnoringTrailingWhitespace(boolean
ignoreTrailingWhitespace);

// defaults to false
public boolean isTreatingEmptyAsNull();
public void setTreatingEmptyAsNull(boolean treatEmptyAsNull);


-Original Message-
From: Inger, Matthew [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 11, 2003 4:08 PM
To: 'Jakarta Commons Developers List'
Subject: RE: suggestion for new StringUtils.method


I've come up with the following class for this.
(I also have a test class which tests a few of the
 simple cases).  Token parsing is done semi-lazily,
in that when the first token is requested (or the
token count), the whole thing is parsed.  And the
reset forgets about the tokens, so you can change
parameters, and re-parse.


public class DelimitedTokenizer
{
public static final char DEFAULT_DELIMITER = ',';
public static final char DEFAULT_QUOTE = '';
public static final String WHITESPACE =  \t\n\r;

public DelimitedTokenizer(String input);
public DelimitedTokenizer(String input, char delim);
public DelimitedTokenizer(String input, char delim, char quote);

public char getDelim();
public void setDelim(char delim);

public char getQuote();
public void setQuote(char quote);

// defaults to true
public boolean isIgnoreLeadingWhitespace();
public void setIgnoreLeadingWhitespace(boolean ignoreLeadingWhitespace);

// defaults to true
public boolean isIgnoreTrailingWhitespace();
public void setIgnoreTrailingWhitespace(boolean
ignoreTrailingWhitespace);

// defaults to false
public boolean isTreatEmptyAsNull();
public void setTreatEmptyAsNull(boolean treatEmptyAsNull);

public int countTokens();
public String nextToken();
public void reset();
public String [] getAllTokens();
}


Now the question is how to submit it

-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 11, 2003 2:28 PM
To: Jakarta Commons Developers List
Subject: Re: suggestion for new StringUtils.method


Inger, Matthew wrote:
 String [] undelimit(String input, char separatorChar, char quoteChar);

It's a tokenizer. It would be handy to have it as an iterator pattern too (like 
StringTokenizer).

J.Pietschmann



-
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: [functor] [patch] contributions

2003-11-12 Thread Herve Quiroz

Well I thought of that before actually... And I believe this could be
done using *BoundProcedure. But I have some trouble trying to define
what the arguments would/should represent and where they would get
passed.

What do you think the run(Object left, Object right) method from
WhileDoBinaryProcedure should do ? IMHO, it should run(left, right) on
the 'action' binary procedure until the condition is false.

Then what should we do about the 'condition' ? Would it still be a
Predicate or instead a BinaryPredicate (used against the 'left' and
'right' parameters each iteration of the loop) ?

I don't know if there's a way to re-use the DoWhile/WhileDo
procedures... or at least re-use the AbstractLoopProcedure. In the later
case, the 'action' constructor argument should probably be Object typed.
Have you ever thought of a Functor interface for such a purpose ? I
don't know if it's a good idea though... This would get to the
following:

public abstract class AbstractLoopFunctor implements Functor, ...
{
public AbstractLoopFunctor(Predicate condition, Functor action)
{
...
}
}

..and the subclasses would implement the right interface themselves.

Okay, I'm late now but I will think of it so we may discuss it further
in the next few days.

Herve

On Tue, Nov 11, 2003 at 04:10:07PM -0800, Rodney Waldhoff wrote:
 This opens the door for Unary and Binary variations of DoWhile and
 WhileDo, of course.  Herve, were you planning on introducing those as
 well?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Resolving Logj4 issue

2003-11-12 Thread James Strachan

On 12 Nov 2003, at 17:00, Noel J. Bergman wrote:
The Log4J issue on geronimo-dev@ brought out the suggestion that Log4J
(right place) or Commons Logging (expedient place) add TRACE level 
support
to the core code, thus relieving each app from having to do it.

I also suggest that geronimo-dev give serious consideration to adopting
Log4J v1.3, on the grounds that it will be the Release version long 
before
Geronimo is ready for Release, and Log4J has changes that effect this 
code
area.

If either of those things happen, I believe that the Log4J issue goes 
away.
From a Geronimo perspective, since commons-logging already has a trace 
level, we could just trash any log4j code from Geronimo for now. Then 
when a log4j and commons-logging release comes out which supports trace 
level then we get the trace level code back again.

Ceki will log4j 1.3 support trace level?

James
---
http://radio.weblogs.com/0112098/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[DIGESTER] access to private members?

2003-11-12 Thread James Carman

Title: Message




I am writing a 
class that uses digester to read a configuration file. I want to use a 
SetNextRule, but my method is private. So, what I would like to do is wrap 
my call to digester.parse() in a PrivilegedExceptionAction and have the 
AccessController run it, thereby giving the digester permissions to call private 
members. This doesn't work, however. This would be a great way to 
use Digester, but NOT break encapsulation. Any thoughts? Shouldn't Digester support this? This may be a limitation of the BeanUtils class, 
I'll run a test. But, in the meantime, give it some thought. I think 
that would be a great enhancement to digester (or BeanUtils as it very well may 
turn out).




  
  

  


  

  
  

  


  
  

  

  


  James CarmanPresident 
  Carman Consulting, Inc.1218 Bobwhite Ct.Edgewood, KY 
41018 

  [EMAIL PROTECTED]IM: 
jwcarman 
  

  
  
tel: fax: 

(513) 325-7977(240) 218-7231 
  
  

  
  


  

  
  


  
  

  


  Powered by Plaxo
  Want a 
signature like this?

Re: [DIGESTER] access to private members?

hi james

this seems to me to be somewhat related to discussions we've been 
having about factoring out the actual implementation used so that 
subclasses can use the setProperties logic without being tied to 
beanutils. this would probably allow a simple solution to you problem 
to be easily constructed.

i'd like to see beanutils support this kind of thing and i know how i'd 
like to see it supported (we've even been moving towards it) but my 
apache time seems to be taken up with talking rather than coding these 
days. the refactoring of digester would be easier and quicker than 
adding this to beanutils.

comments welcomed :)

- robert

On 12 Nov 2003, at 18:15, James Carman wrote:

I am writing a class that uses digester to read a configuration file.  
I want to use a SetNextRule, but my method is private.  So, what I 
would like to do is wrap my call to digester.parse() in a 
PrivilegedExceptionAction and have the AccessController run it, 
thereby giving the digester permissions to call private members.  This 
doesn't work, however.  This would be a great way to use Digester, but 
NOT break encapsulation.  Any thoughts?  Shouldn'tDigester support 
this?  This may be a limitation of the BeanUtils class, I'll run a 
test.  But, in the meantime, give it some thought.  I think that would 
be a great enhancement to digester (or BeanUtils as it very well may 
turn out).
 

image.tiffJames Carman
President
Carman Consulting, Inc.
1218 Bobwhite Ct.
Edgewood, KY 41018
[EMAIL PROTECTED]
IM: jwcarman
tel:
fax:
(513) 325-7977
(240) 218-7231
 

 

Powered by Plaxo
Want a signature like this?
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/codec/src/java/org/apache/commons/codec/language Soundex.java

2003-11-12 Thread ggregory

ggregory2003/11/12 11:02:57

  Modified:codec/src/java/org/apache/commons/codec/language
Soundex.java
  Log:
  Redo license header.
  
  Revision  ChangesPath
  1.13  +51 -38
jakarta-commons/codec/src/java/org/apache/commons/codec/language/Soundex.java
  
  Index: Soundex.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/codec/src/java/org/apache/commons/codec/language/Soundex.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Soundex.java  7 Nov 2003 01:20:19 -   1.12
  +++ Soundex.java  12 Nov 2003 19:02:57 -  1.13
  @@ -2,45 +2,58 @@
* 
* 
* The Apache Software License, Version 1.1
  - * 
  - * Copyright (c) 2001-2003 The Apache Software Foundation. All rights reserved.
  - * 
  + *
  + * Copyright (c) 2001-2003 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
  - * acknowledgement: This product includes software developed by the Apache
  - * Software Foundation (http://www.apache.org/). Alternately, this
  - * acknowledgement may appear in the software itself, if and wherever such
  - * third-party acknowledgements normally appear. 4. The names Apache, 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, Apache 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.
  + * 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 acknowledgement:  
  + *   This product includes software developed by the 
  + *Apache Software Foundation (http://www.apache.org/).
  + *Alternately, this acknowledgement may appear in the software itself,
  + *if and wherever such third-party acknowledgements normally appear.
  + *
  + * 4. The names Apache, 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,
  + *Apache 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

RE: [codec] Release mechanics?

2003-11-12 Thread Gary Gregory

The prepare releases page saya: Make sure that there is a complete Apache
Software License at the top of each source file.

Should I also include the license in the various package.html files? 

Strictly speaking I would say so, but I have not seen this done other places
like [lang].

Thanks,
Gary

 -Original Message-
 From: David Graham [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, November 11, 2003 16:39
 To: Jakarta Commons Developers List
 Subject: Re: [codec] Release mechanics?
 
 --- Gary Gregory [EMAIL PROTECTED] wrote:
  Tim,
 
  I have a [vote] request message prepared for posting... but, I notice
  that
  previous similar vote request messages include a pointer to a
  ~username
  URL with the content of the RC build.
 
  For example: The source for this release candidate has been tagged as
  PRIMITIVES_1_0_RC1 and is available for download at
  http://cvs.apache.org/~rwaldhoff/commons-primitives/RC1/.
 
  I do not have such a ~ cubby hole, should I request one? How shall I
  proceed?
 
 You do if you have an Apache email address.  Login to cvs.apache.org (it
 has several other names as well) and create a public_html directory under
 your home directory.  You can look at my setup (dgraham) as an example if
 you like.  I use this document for preparing releases:
 
 http://jakarta.apache.org/commons/releases/index.html
 
 David
 
 
  Thanks,
  Gary
 
   -Original Message-
   From: Tim O'Brien [mailto:[EMAIL PROTECTED]
   Sent: Tuesday, November 04, 2003 20:12
   To: Jakarta Commons Developers List
   Subject: RE: [codec] should we release a version 1.2 now?
  
   On Mon, 2003-11-03 at 13:27, Gary Gregory wrote:
Hello,
   
o I've Javadoc'd the Hex class and given it 100% unit test coverage
  (see
clover report from a local build). There is also a bug fix in there.
   
o The Base64 test code coverage is as close to 100% as it is going
  to
   get.
The only conditional branch not tested cannot be taken from staring
  at
   the
code.
   
o I've updated various files from 1.1.1-dev to 1.2-dev added
  some
   text
to the release notes.
   
The only missing piece that I can see is the need of better for the
   language
package. Tim, have you looked at this by any chance?
   
  
   Looked, yes.  Acted, no.  I think we're close enough to bring 1.2
   release to a vote.  Gary, if you feel comfortable with that propose
  the
   vote.
  
Thanks,
Gary
   
 -Original Message-
 From: Tim O'Brien [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, October 07, 2003 10:56
 To: Jakarta Commons Developers List
 Subject: Re: [codec] should we release a version 1.2 now?

 +1 for a 1.2

 Maybe this time we'll make a release.  :-)  (I'm notorious for
   dropping
 the ball lately)

 What's left -

 1. Let's make an attempt to increase coverage over the next few
  days -
 http://jakarta.apache.org/commons/codec/clover/index.html

 2. Build out Javadocs -
 http://jakarta.apache.org/commons/codec/apidocs/index.html

 On Mon, 6 Oct 2003, Michael Becke wrote:

  I think 1.2 sounds better as well.  URLCodec is also new in this
  release.
 
  Mike
 
  On Monday, October 6, 2003, at 03:05 PM, Gary Gregory wrote:
 
   A 1.1.1 release seems no longer appropriate since DigestUtils
  is a
   new
   feature; should we wrap up a 1.2 now?
  
   It feels like we had been planning a 1.1.1 for quite some time
  to
   capture
   some bug fixes.
  
   Gary
 
 
 
  
   -
  To unsubscribe, e-mail:
  [EMAIL PROTECTED]
  For additional commands, e-mail:
  [EMAIL PROTECTED]
 
 
 

 --
 --
 Tim O'Brien
 Evanston, IL
 (847) 863-7045
 [EMAIL PROTECTED]




  -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:
  [EMAIL PROTECTED]
   --
   -
   Tim O'Brien - [EMAIL PROTECTED] - (847) 863-7045
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 __
 Do you Yahoo!?
 Protect your identity with Yahoo! Mail AddressGuard
 http://antispam.yahoo.com/whatsnewfree
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Elect Simon Kitching As Jakarta Commons Committer

Simon Kitching has been actively contributing to Digester for a long  
while now. He's actively and knowledgeably answered questions from  
users for many, many month. Over the last couple of month's he's  
submitted a substantial quantity of patches both new code and also  
documentation. He's learnt the value of discussion and knows how to  
deal (in a very positive fashion) with differences of opinion.

here's my +1.

- robert

 
--
Vote:  Elect Simon Kitching As Jakarta Commons Committer
[ ] +1 Yes let him commit!
[ ] +0
[ ] -0
[ ] -1 I am against this (please include a reason).
 
--

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Commons Karma for Jean-Francois Arcand

Jean-Francois Arcand ([EMAIL PROTECTED]) is an established jakarta  
committer with a good knowledge of xml and xml-schema. He's submitted  
numerous patches over a period of years to help to provide Digester  
with schema support. He plans to improve and extend the range of  
support over the next few months.

I think that the time has come to allow Jean-Francois to accept  
responsibility for the product he's helped to create ;)

here's my +1.

- robert

 
--
Vote:  Elect Jean-Francois Arcand As Jakarta Commons Committer
[ ] +1 Yes let him commit!
[ ] +0
[ ] -0
[ ] -1 I am against this (please include a reason).
 
--

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [math] Numerical Derivative pattern q.

2003-11-12 Thread Mark R. Diggory



Matt Cliff wrote:
The numerical root solving methods are completely independant of the 
numerical derivative routines.  
   
This doesnt quite make sense to me.  The Solver implemenations are Root 
solver routines which address the question of which value for x exists  
between (min,max) such that f(x) = 0.  

On a programmatic level its even more abstract than that A solver simply 
is solving for UnivariateRealFunction.value(double d)  so the function 
you could be solving for could represent a Cubic or Polynomial or a 
derivative of that Cubic/Polynomial.

Now I think I'm grasping this better, in your case, you do not actually 
have an analytical solution for what we are identifying as the functions 
getFirstDerivative or getSecondDerivative.

The numerical derivative routines estimate the value of the limit of 
(f(x+h)-f(x))/h as h approaches 0.

  I dont understand why (or how) a Bisection Solver routine would address
the question of approximating the derivative of a function at a point.
No, this just me misinterpreting the problem. I went back and reviewed 
Numerical Derivations And understand I misinterpreted you.


  How would the BisectionSolver be related to an estimate for the 
Derivative?

Ignore that from algorithm standpoint, lets think more about how 
Numerical Derivation fits into or existing infrastructure.

  I was thinking along the lines of having an implementation of a 
numerical derivative solver that take a function and a value of h as a 
parameter and return a function.  something like

public class  DefaultForwardDerivative {
  private Function f = null;
  private double h = 0.0;
  public DefaultForwardDerivative( Function f, double h ) {
   this.f = f;
   this.h = h;
  }

  // this should also have some upper limit on the
  //   absolute value of the return function
  //   so we dont introduce singularities
  public double value( double x ) throws MathException {
double y0 = f.value( x );
double y1 = f.value( x + h);
return (( y1 - y0 ) / h);
  }
}
Yes, this fits in very well architecturally with the idea Brent is 
discussion about decorator functions. Is this an implementation of 
UnivariateRealFunction?


--

   A Factory could be placed in front to pull this or a backward (use -h 
value), or centered, or multi-point estimate for the derivative. The 
factory would hide the 'h' value with some default.

  The second (or higher) derivative could be obtained as follows


  DerivativeFactory factory = DeriviateFactory.getInstance();  

  Function f = new SomeUserFunction();
  Function g = factory.derivative( f );
  Function h = factory.deritivate( g );
Is this factory.derivative vs. factory.deritivate a typo or intentional? 
Are these both t he same method?

 
   In this example, f' = g, and g' = h, and f'' = h...



I agree with Brent that these should be Decorators or Functions that 
wrap another function. Much in the way your suggesting yourself. I think 
there should be a means of making the code thats going to be Numerically 
approximating this solution more transparent to the user. Take for 
instance our current Solver strategy. Maybe solvers should just be 
Functions in and of themselves. This means that a Solver would look 
more like this:

UnivariateRealSolver solver = 
UnivariateRealSolverFactory.newInstance().newSecantSolver(somefunction);
/* this factory instantiation pattern is a little verbose */

solver.setMin(...);
solver.setMax(...);
solver.setStartingPoint(...);
double d = solver.value(x); /*where x = 0 or any other value you want to 
solve for.*/

But, lets try not to let the Factory design pattern get in the way 
here. Lets look at your above example and rework it without factory 
pattern, just using constructors this would look like this (I changed 
the variables so I can use h again.

Function e = new SomeUserFunction();

Function f = new CenteredDerivative();
f.setFunction(e);
Function g = new CenteredDerivative();
g.setFunction(f);
double result = g.value(x);

then calling g.value(x) would use Centered approaches to Numerically 
estimate e'' = g.

So for:

(f(x+h)-f(x))/h

you would need to set a property of the CenteredDerivative that may be 
adjusted. I suspect this property is actually setting the starting h 
value? This could be done, as a property, or in the constructor, but I 
would approach the initial implementations very much as beans.

double h = ...;
Function e = new SomeUserFunction();
Function f = new CenteredDerivative();
f.setFunction(e);
f.setInterval(h);
Function g = new CenteredDerivative();
g.setFunction(f);
g.setInterval(h);
double result = g.value(x);

Then you'd use a factory to set this globally or transparently to 
the user.

DerviativeFactory factory = DerviativeFactory.newInstance();
factory.setInterval(0.5);
Function e = new

RE: [VOTE] Elect Simon Kitching As Jakarta Commons Committer


Vote:  Elect Simon Kitching As Jakarta Commons Committer
[X] +1 Yes let him commit!
[ ] +0
[ ] -0
[ ] -1 I am against this (please include a reason).
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE] Commons Karma for Jean-Francois Arcand

Vote:  Elect Jean-Francois Arcand As Jakarta Commons Committer
[X] +1 Yes let him commit!
[ ] +0
[ ] -0
[ ] -1 I am against this (please include a reason).


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/codec/src/test/org/apache/commons/codec/digest DigestUtilsTest.java

2003-11-12 Thread ggregory

ggregory2003/11/12 11:28:47

Modified:codec/src/test/org/apache/commons/codec/digest
DigestUtilsTest.java
Log:
Redo license header.

Revision ChangesPath
1.8 +50 -38
jakarta-commons/codec/src/test/org/apache/commons/codec/digest/DigestUtilsTest.java

Index: DigestUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons/codec/src/test/org/apache/commons/codec/digest/DigestUtilsTest.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- DigestUtilsTest.java 3 Nov 2003 04:08:26 - 1.7
+++ DigestUtilsTest.java 12 Nov 2003 19:28:47 - 1.8
@@ -2,46 +2,58 @@
*
*
* The Apache Software License, Version 1.1
- *
- * Copyright (c) 2001-2003 The Apache Software Foundation. All rights reserved.
- *
+ *
+ * Copyright (c) 2001-2003 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 acknowledgement: This product includes software
- * developed by the Apache Software Foundation (http://www.apache.org/).
- * Alternately, this acknowledgement may appear in the software itself, if and
- * wherever such third-party acknowledgements normally appear.
- * 4. The names Apache, 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, Apache
- * 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.
+ * 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 acknowledgement:
+ * This product includes software developed by the
+ *Apache Software Foundation (http://www.apache.org/).
+ *Alternately, this acknowledgement may appear in the software itself,
+ *if and wherever such third-party acknowledgements normally appear.
+ *
+ * 4. The names Apache, 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,
+ *Apache 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,

cvs commit: jakarta-commons/codec/src/test/org/apache/commons/codec/language SoundexTest.java MetaphoneTest.java DoubleMetaphoneTest.java

2003-11-12 Thread ggregory

ggregory2003/11/12 11:32:52

Modified:codec/src/test/org/apache/commons/codec/language
SoundexTest.java MetaphoneTest.java
DoubleMetaphoneTest.java
Log:
Redo license header.

Revision ChangesPath
1.8 +51 -38
jakarta-commons/codec/src/test/org/apache/commons/codec/language/SoundexTest.java

Index: SoundexTest.java
===
RCS file:
/home/cvs/jakarta-commons/codec/src/test/org/apache/commons/codec/language/SoundexTest.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- SoundexTest.java 7 Nov 2003 01:21:47 - 1.7
+++ SoundexTest.java 12 Nov 2003 19:32:52 - 1.8
@@ -2,45 +2,58 @@
*
*
* The Apache Software License, Version 1.1
- *
- * Copyright (c) 2001-2003 The Apache Software Foundation. All rights reserved.
- *
+ *
+ * Copyright (c) 2001-2003 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
- * acknowledgement: This product includes software developed by the Apache
- * Software Foundation (http://www.apache.org/). Alternately, this
- * acknowledgement may appear in the software itself, if and wherever such
- * third-party acknowledgements normally appear. 4. The names Apache, 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, Apache 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.
+ * 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 acknowledgement:
+ * This product includes software developed by the
+ *Apache Software Foundation (http://www.apache.org/).
+ *Alternately, this acknowledgement may appear in the software itself,
+ *if and wherever such third-party acknowledgements normally appear.
+ *
+ * 4. The names Apache, 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,
+ *Apache 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

Re: [VOTE] Elect Simon Kitching As Jakarta Commons Committer

2003-11-12 Thread Martin Cooper

 
 --
 Vote:  Elect Simon Kitching As Jakarta Commons Committer
 [X] +1 Yes let him commit!
 [ ] +0
 [ ] -0
 [ ] -1 I am against this (please include a reason).
 
 --

--
Martin Cooper


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Commons Karma for Jean-Francois Arcand

2003-11-12 Thread Martin Cooper

 
 --
 Vote:  Elect Jean-Francois Arcand As Jakarta Commons Committer
 [X] +1 Yes let him commit!
 [ ] +0
 [ ] -0
 [ ] -1 I am against this (please include a reason).
 
 --

--
Martin Cooper


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Elect Simon Kitching As Jakarta Commons Committer

2003-11-12 Thread __matthewHawthorne

+1

robert burrell donkin wrote:
Simon Kitching has been actively contributing to Digester for a long  
while now. He's actively and knowledgeably answered questions from  
users for many, many month. Over the last couple of month's he's  
submitted a substantial quantity of patches both new code and also  
documentation. He's learnt the value of discussion and knows how to  
deal (in a very positive fashion) with differences of opinion.

here's my +1.

- robert

 --
Vote:  Elect Simon Kitching As Jakarta Commons Committer
[ ] +1 Yes let him commit!
[ ] +0
[ ] -0
[ ] -1 I am against this (please include a reason).
 --


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Commons Karma for Jean-Francois Arcand

2003-11-12 Thread __matthewHawthorne

+1

robert burrell donkin wrote:
Jean-Francois Arcand ([EMAIL PROTECTED]) is an established jakarta  
committer with a good knowledge of xml and xml-schema. He's submitted  
numerous patches over a period of years to help to provide Digester  
with schema support. He plans to improve and extend the range of  
support over the next few months.

I think that the time has come to allow Jean-Francois to accept  
responsibility for the product he's helped to create ;)

here's my +1.

- robert

 --
Vote:  Elect Jean-Francois Arcand As Jakarta Commons Committer
[ ] +1 Yes let him commit!
[ ] +0
[ ] -0
[ ] -1 I am against this (please include a reason).
 --


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Elect Simon Kitching As Jakarta Commons Committer

2003-11-12 Thread Craig R. McClanahan

 Vote:  Elect Simon Kitching As Jakarta Commons Committer
 [X] +1 Yes let him commit!
 [ ] +0
 [ ] -0
 [ ] -1 I am against this (please include a reason).
  

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Commons Karma for Jean-Francois Arcand

2003-11-12 Thread Craig R. McClanahan

 Vote:  Elect Jean-Francois Arcand As Jakarta Commons Committer
 [X] +1 Yes let him commit!
 [ ] +0
 [ ] -0
 [ ] -1 I am against this (please include a reason).
  

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [math] re: move to Apache Commons

2003-11-12 Thread J.Pietschmann

Phil Steitz wrote:
Recent comments have suggested that Java may not be suitable for numerical
computation (a view that I do not share)
Well, I think this should be put into context. Let's examine some
approaches to numerical computation:
1. A cleanly designed library of commonly used, somewhat low level
 functionality, like [math]. While it is relatively easy to build
 solutions for complex problems, this approach suffers from lots
 of temporary object creation and data copying. This is hard to avoid
 in Java without giving up data encapsulation and providing ample
 opportunity to users for shooting themselves in the foot. See the
 constructor of CubicSplineFunction for an example.
2. Provide solutions to higher level problems. Inline the code for
 the lower level functionality, do memory allocation less dynamically
 and weight the usage of abstractions carefully against possible
 object proliferation. For example in a ray tracer, use the vector
 components explicitely instead of using vector objects.
 This is, in general, noticably faster than approach 1, and an increase
 of *two* orders of magnitude is possible, although not necessarily
 common.
 Profiled and well optimized Java code run on a HotSpot JVM can be on
 par with average C code with regards to performance.
3. Get a highly optimized C/C++/FORTRAN library (possibly including a
 compiler), which takes processor architecture, cache size and
 organization and whatnot into account. A performance improvement of
 another order of magnitude compared to approach 2 is not unheard of.
I tried an EMF simulator two years ago, and when built on a generic
Java library, very similar to RealMatrixImpl, a 1000x1000x1000 data
point simulation run all night. Switching to approach 2 brought it
down to roughly 5min, barely enough to fetch a coffee. The real good
stuff, using C and tricky algorithms specifically designed for EMF
simulations, is nearly interactive, in the 5..10s range.
Summary: whether Java programs can be used for tackling numerical
problems depends on the problem, the problem size, how you want
to solve it, and the tradeoffs you are willing to consider.
some design/refactoring decisions made some time
ago that moved things more in the framework direction in commons math.
Hm. There are reasons that there are usually a bunch of different
algorithms for solving seemingly the same problem. Which specific
algorithm should be used can heavily depend on the higher level
problem, and a good choice can be a really huge win. And yes,
unsuspecting users are regularly bitten by stock textbook solutions
which are either much too slow or fail unexpectedly.
J.Pietschmann

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [logging] Resolving Logj4 issue

 From a Geronimo perspective, since commons-logging already has a trace
 level, we could just trash any log4j code from Geronimo for now.

The Commons Logging log4j adapter does TRACE at DEBUG right now because
Log4J doesn't have a TRACE level.  Dain suggested that we add an extended
level for TRACE to Commons Logging.  Others have said that they would like
to see Log4J address it directly.  Whatever solution comes from the
discussion between the projects is probably fine.  The important things are
(a) improved collaboration, and (b) the solution.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24659] New: - [bewixt] null values shown as empty attributes

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=24659.
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=24659

[bewixt] null values shown as empty attributes

   Summary: [bewixt] null values shown as empty attributes
   Product: Commons
   Version: Nightly Builds
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Betwixt
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When a bean's property value is null, and setAttributesForPrimitives is true, it
is shown as an empty attribute.

This behavior doesn't seem to be correct, since a value of null is being
converted to an empty string.

I've looked through the API and the code, and I can't seem to find where the
problem is.

I've posted this question to commons-user twice, but haven't received a
response.  Even if you can't provide a fix, could you point me in the right
direction so I could perhaps patch it?  

Thanks for any help or information that you can provide.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Resolving Logj4 issue

On 12 Nov 2003, at 20:24, Noel J. Bergman wrote:

From a Geronimo perspective, since commons-logging already has a trace
level, we could just trash any log4j code from Geronimo for now.
The Commons Logging log4j adapter does TRACE at DEBUG right now because
Log4J doesn't have a TRACE level.  Dain suggested that we add an 
extended
level for TRACE to Commons Logging.  Others have said that they would 
like
to see Log4J address it directly.  Whatever solution comes from the
discussion between the projects is probably fine.  The important 
things are
(a) improved collaboration, and (b) the solution.
commons-logging is now relied upon by a lot of projects. this means 
that we have to be pretty conservative about changes. there are some 
subtle choices concerning classloading which are required for 
commons-logging to function correctly in servlet containers (such as 
tomcat) but make it difficult to solve some other common user issues.

so, i'd probably advise against using using commons-logging directly.

i'd say that the basic commons logging interface (Log) is pretty much 
optimal. the LogFactory interface is basically sound but the 
implementation is over-complicated due to needs to allow independent 
configurations for different context classloaders.

my personal recommendation would be that geronimo considers using the 
extensive research done and experience gained by the commons-logging 
team but uses a repackaged version with a modified LogFactory 
implementation. this implementation should probably be configurable (by 
JMX, say) rather than relying on the complex configuration mechanisms 
employed by the commons-logging implementation.

this would isolate the container logging from issues with loggers in 
contained application.

i would also recommend that a separate Log implementation be created 
that extends Log4JLogger maps trace to a log4j level.

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [digester] [PATCH] Adding Ant-like properties support

2003-11-12 Thread Simon Kitching

Hi Remy,

On Wed, 2003-11-12 at 23:01, Remy Maucherat wrote:
 Simon Kitching wrote:
  Hi Remy,
  
  I'm really keen to have this sort of feature in Digester.
  
  I've had this kind of functionality in my local application for some
  time now, but it's implemented in a rather different manner.
  
  Attached is my current implementation, for comparison.
  
  Here's the major differences:
  
  *
  Your initial patch only does substitution for SetPropertiesRule.
  What about CallParamRule, etc?
  
  The attached implementation automatically applies to all attributes, and
  therefore to all rules both built-in and custom. While somewhat less
  efficient than your current proposal, it isn't likely to be invoked very
  often (variable substitution is expected to be the exception, not the
  normal case). See later for a proposed optimisation to the current
  implementation.
 
 - it could be not very efficient (you reinstantiate all attribute 
 lists); JBoss does the exact same thing, and I don't know if it's 
 significant, so I chose a lower overhead method; I think I'll try it 
 though, since it is more generic and easier to implement

I agree there is an efficiency hit for the implementation I suggest. My
email proposed some improvements to the existing implementation that
should reduce this by at least 50% (depending on how many input elements
actually take advantage of variable substitution).

And if performance is a problem, we could design a custom class which
implements org.xml.sax.Attributes, and reuse the same instance all the
time. The data inside can be structured as Arrays of values; I'm pretty
sure it is possible to create a class that would not need any dynamic
allocation at all to copy the attributes data into it. Yes, the
copying is needed but that is no worse than the copying going on when
implementing it in SetPropertiesRule et. al.

 - it doesn't support scoping like Ant does (and is a feature Tomcat 
 would use)

Could you explain this, Remy? I don't see what you mean by scoping..

 - personally, I'm used to ${...}, like all Ant users, probably; I don't 
 see any reason to add support for customizing this (I don't like featurism)

Anyone else like/dislike the suggestions that:
(a) 
there should be some syntax available to suppress variable substitution,
so it is actually possible to pass the string ${ to a method when
variable substitution is enabled?
(b) 
the variable marker char should be customisable?
(c) 
multiple sources should be supported?

As I said in a previous email, I'm not sure at the moment that (c) can
be efficiently implemented. 

Cheers,

Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Elect Simon Kitching As Jakarta Commons Committer

2003-11-12 Thread Scott Sanders

--- 
---
Vote:  Elect Simon Kitching As Jakarta Commons Committer
[X] +1 Yes let him commit!
[ ] +0
[ ] -0
[ ] -1 I am against this (please include a reason).
--- 
---

Absolutely.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [codec] Release mechanics?

i think that only the source code needs to be licensed in this way. (i  
don't recall seeing licenses on package documentation before.)

BTW if you're thinking of doing full releases then you might find the  
following wiki page of interest.  
http://nagoya.apache.org/wiki/apachewiki.cgi?ReleaseManager

- robert

On 12 Nov 2003, at 19:06, Gary Gregory wrote:

The prepare releases page saya: Make sure that there is a complete  
Apache
Software License at the top of each source file.

Should I also include the license in the various package.html files?

Strictly speaking I would say so, but I have not seen this done other  
places
like [lang].

Thanks,
Gary
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 11, 2003 16:39
To: Jakarta Commons Developers List
Subject: Re: [codec] Release mechanics?
--- Gary Gregory [EMAIL PROTECTED] wrote:
Tim,

I have a [vote] request message prepared for posting... but, I notice
that
previous similar vote request messages include a pointer to a
~username
URL with the content of the RC build.
For example: The source for this release candidate has been tagged  
as
PRIMITIVES_1_0_RC1 and is available for download at
http://cvs.apache.org/~rwaldhoff/commons-primitives/RC1/.

I do not have such a ~ cubby hole, should I request one? How shall I
proceed?
You do if you have an Apache email address.  Login to cvs.apache.org  
(it
has several other names as well) and create a public_html directory  
under
your home directory.  You can look at my setup (dgraham) as an  
example if
you like.  I use this document for preparing releases:

http://jakarta.apache.org/commons/releases/index.html

David

Thanks,
Gary
-Original Message-
From: Tim O'Brien [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 04, 2003 20:12
To: Jakarta Commons Developers List
Subject: RE: [codec] should we release a version 1.2 now?
On Mon, 2003-11-03 at 13:27, Gary Gregory wrote:
Hello,

o I've Javadoc'd the Hex class and given it 100% unit test coverage
(see
clover report from a local build). There is also a bug fix in  
there.

o The Base64 test code coverage is as close to 100% as it is going
to
get.
The only conditional branch not tested cannot be taken from staring
at
the
code.

o I've updated various files from 1.1.1-dev to 1.2-dev added
some
text
to the release notes.

The only missing piece that I can see is the need of better for the
language
package. Tim, have you looked at this by any chance?

Looked, yes.  Acted, no.  I think we're close enough to bring 1.2
release to a vote.  Gary, if you feel comfortable with that propose
the
vote.

Thanks,
Gary
-Original Message-
From: Tim O'Brien [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 07, 2003 10:56
To: Jakarta Commons Developers List
Subject: Re: [codec] should we release a version 1.2 now?
+1 for a 1.2

Maybe this time we'll make a release.  :-)  (I'm notorious for
dropping
the ball lately)

What's left -

1. Let's make an attempt to increase coverage over the next few
days -
http://jakarta.apache.org/commons/codec/clover/index.html

2. Build out Javadocs -
http://jakarta.apache.org/commons/codec/apidocs/index.html
On Mon, 6 Oct 2003, Michael Becke wrote:

I think 1.2 sounds better as well.  URLCodec is also new in this
release.
Mike

On Monday, October 6, 2003, at 03:05 PM, Gary Gregory wrote:

A 1.1.1 release seems no longer appropriate since DigestUtils
is a
new
feature; should we wrap up a 1.2 now?

It feels like we had been planning a 1.1.1 for quite some time
to
capture
some bug fixes.
Gary




-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]



--
--
Tim O'Brien
Evanston, IL
(847) 863-7045
[EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
-
Tim O'Brien - [EMAIL PROTECTED] - (847) 863-7045
 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
-
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] Converting JSP taglib to Jelly taglib

2003-11-12 Thread Robert

If you have messy HTML that would probably be the case. However, Jelly 
scripts can easily generate HTML as well as anything else (csv files, 
XML, straight text, or no output at all). There is even a JellyServlet 
for doing such a thing. Oh yea and you can embed Velocity scipts (using 
a Jelly tag) in a jelly script as well.

I have used Jelly to dynamically generate a ton a test SQL statements 
into a regular text file to populate a database with dummy data.

On a related note, I am working on a JSP taglib that will allow 
embedding of Jelly scripts in a JSP page as well as executing an 
'external' jelly script, if you are interested. I have a definate need 
for it coming up soon so I'm going to write it regardless and then 
donate it, but if you want I will send it to you when I'm done.

Robert McIntosh

Ojares Rami EINT wrote:
So I quess it is fair to say that JSP tags (or Velocity) is better solution
when building dynamic web pages (messy html + whatever)?
Would you agree?
- rami


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 12, 2003 12:15 AM
To: Jakarta Commons Developers List
Subject: Re: [Jelly] Converting JSP taglib to Jelly taglib

A jelly script *must* be a well-formed XML document.
--
dIon Gillard, Multitask Consulting
Blog:  http://blogs.codehaus.org/people/dion/


Ojares Rami EINT [EMAIL PROTECTED] wrote on 12/11/2003 
12:07:55 AM:


Hi,

I am new to Jelly.
I was thinking about converting a JSP taglib to Jelly tags.
But I have some concerns.
One very handy thing about JSP parsing
is that jsp does not have to be a well formed XML document.
How about Jelly?
Could I use some jelly tags inside a html document
that is filled with javascript, ampersands and
unfinished tags?
- rami

-
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: math to apache commons was Re: [all] Separate email list for math development?

On 11 Nov 2003, at 11:31, Geir Magnusson Jr. wrote:

On Sunday, November 9, 2003, at 05:39 PM, Tim O'Brien wrote:

On Sun, 2003-11-09 at 14:24, robert burrell donkin wrote:
snip/
so - is there a positive alternative? i'd like to propose that
common-maths continues to be affiliated with jakarta-commons but
becomes managed by apache commons.
+1, I think that now is the right time to move commons math to
Apache Commons.
What does 'affiliated' mean?
i can't recall just now who coined it but here's what i meant by the 
term.

most users interactive with jakarta through the website and newsletter. 
for them, a product is part of jakarta if it's listed in the products 
section of the jakarta side bar (and - to a lesser extent - is 
categorized under jakarta in the newsletter). issues of management 
shouldn't really need to concern a user too much.

if they can click on a link to the product's home page from the jakarta 
sidebar and join the product's mailing list from the jakarta mailing 
list page then the product is part of jakarta (as least as far as they 
are concerned). of course, if a product is managed by another pmc, then 
the product website will be hosted under a separate virtual host and 
linked from the main project website. similarly the mailing list will 
not be @jakarta. but from a user's perspective, the product will still 
be part of jakarta.

affiliation was the term coined to express this kind of relationship.

of course, this only applies if product move to top level projects 
which offer multiple products. it seems to me that this is the only 
(positive) way that jakarta can be reduced in size until it again 
become manageable (but maybe this is a matter for the members...)

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/digester/src/test/org/apache/commons/digester/plugins TestConfigurablePluginAttributes.java

2003-11-12 Thread rdonkin

rdonkin 2003/11/12 15:20:29

  Added:   digester/src/test/org/apache/commons/digester/plugins
TestConfigurablePluginAttributes.java
  Log:
  Test for support for xml attribute specifying the plugin declaration clas. Submitted 
by Simon Kitching.
  
  Revision  ChangesPath
  1.1  
jakarta-commons/digester/src/test/org/apache/commons/digester/plugins/TestConfigurablePluginAttributes.java
  
  Index: TestConfigurablePluginAttributes.java
  ===
  /*
   * $Header: 
/home/cvs/jakarta-commons/digester/src/test/org/apache/commons/digester/plugins/TestConfigurablePluginAttributes.java,v
 1.1 2003/11/12 23:20:29 rdonkin Exp $
   * $Revision: 1.1 $
   * $Date: 2003/11/12 23:20:29 $
   *
   * 
   * 
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 2001-2003 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 acknowledgement:  
   *   This product includes software developed by the 
   *Apache Software Foundation (http://www.apache.org/).
   *Alternately, this acknowledgement may appear in the software itself,
   *if and wherever such third-party acknowledgements normally appear.
   *
   * 4. The names Apache, 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,
   *Apache nor may Apache appear in their names 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.digester.plugins;
  
  import java.util.List;
  import java.util.LinkedList;
  import java.util.Iterator;
  
  import junit.framework.Test;
  import junit.framework.TestCase;
  import junit.framework.TestSuite;
  
  import org.apache.commons.digester.*;
  import org.apache.commons.digester.plugins.*;
  
  /**
   * Test cases for functionality which sets what xml attributes specify
   * the plugin class or plugin declaration id.
   */
  
  public class TestConfigurablePluginAttributes extends TestCase {
  /** Standard constructor */
  public TestConfigurablePluginAttributes(String name) { 
  super(name);
  }
  
  /** Set up instance variables required by this test case. */
  public void setUp() {}
  
  /** Return the tests included in this test suite. */
  public static Test suite() {
  
  return (new TestSuite(TestConfigurablePluginAttributes.class));
  
  }
  
  /** Tear down instance variables required by this test case.*/
  public void tearDown() {}
  
  // --- Test cases
  
  public void testDefaultBehaviour() throws Exception {
  // tests that by default the attributes used are 
  // named plugin-class and plugin-id
  
  Digester digester = new Digester();

cvs commit: jakarta-commons/digester/src/test/org/apache/commons/digester/plugins test7.xml

2003-11-12 Thread rdonkin

rdonkin 2003/11/12 15:20:46

  Added:   digester/src/test/org/apache/commons/digester/plugins
test7.xml
  Log:
  Test for support for xml attribute specifying the plugin declaration clas. Submitted 
by Simon Kitching.
  
  Revision  ChangesPath
  1.1  
jakarta-commons/digester/src/test/org/apache/commons/digester/plugins/test7.xml
  
  Index: test7.xml
  ===
  root xmlns:plugin=http://jakarta.apache.org/digester/plugins;
plugin id=label class=org.apache.commons.digester.plugins.TextLabel/
plugin id=slider class=org.apache.commons.digester.plugins.Slider/
plugin id=label2 class=org.apache.commons.digester.plugins.TextLabel2/

widget plugin-id=label id=slider plugin:id=label2/
widget plugin-id=label id=slider plugin:id=label2/
gadget plugin-id=label id=slider plugin:id=label2/
gadget plugin-id=label id=slider plugin:id=label2/
  
widget 
  plugin-class=org.apache.commons.digester.plugins.TextLabel 
  class=org.apache.commons.digester.plugins.Slider 
  plugin:class=org.apache.commons.digester.plugins.TextLabel2/
  
widget 
  plugin-class=org.apache.commons.digester.plugins.TextLabel 
  class=org.apache.commons.digester.plugins.Slider 
  plugin:class=org.apache.commons.digester.plugins.TextLabel2/
  
gadget 
  plugin-class=org.apache.commons.digester.plugins.TextLabel 
  class=org.apache.commons.digester.plugins.Slider 
  plugin:class=org.apache.commons.digester.plugins.TextLabel2/
  
gadget 
  plugin-class=org.apache.commons.digester.plugins.TextLabel 
  class=org.apache.commons.digester.plugins.Slider 
  plugin:class=org.apache.commons.digester.plugins.TextLabel2/
  /root
  
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/digester/src/test/org/apache/commons/digester/plugins TestAll.java

2003-11-12 Thread rdonkin

rdonkin 2003/11/12 15:21:19

  Modified:digester/src/java/org/apache/commons/digester/plugins
PluginCreateRule.java
   digester/src/test/org/apache/commons/digester/plugins
TestAll.java
  Log:
  Added support for xml attribute specifying the plugin declaration class. Submitted 
by Simon Kitching.
  
  Revision  ChangesPath
  1.7   +163 -27   
jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/PluginCreateRule.java
  
  Index: PluginCreateRule.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/PluginCreateRule.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- PluginCreateRule.java 2 Nov 2003 23:26:59 -   1.6
  +++ PluginCreateRule.java 12 Nov 2003 23:21:18 -  1.7
  @@ -80,8 +80,31 @@
*/
   public class PluginCreateRule extends Rule implements InitializableRule {
   
  -private static final String PLUGIN_CLASS_ATTR = plugin-class;
  -private static final String PLUGIN_ID_ATTR = plugin-id;
  +// the xml attribute the user uses on an xml element to specify
  +// the plugin's class
  +public static final String GLOBAL_PLUGIN_CLASS_ATTR_NS = null;
  +public static final String GLOBAL_PLUGIN_CLASS_ATTR = plugin-class;
  +
  +// the xml attribute the user uses on an xml element to specify
  +// the plugin's class
  +public static final String GLOBAL_PLUGIN_ID_ATTR_NS = null;
  +public static final String GLOBAL_PLUGIN_ID_ATTR = plugin-id;
  +
  +// see setGlobalPluginClassAttribute
  +private static String globalPluginClassAttrNs_ = GLOBAL_PLUGIN_CLASS_ATTR_NS;
  +private static String globalPluginClassAttr_ = GLOBAL_PLUGIN_CLASS_ATTR;
  +
  +// see setGlobalPluginIdAttribute
  +private static String globalPluginIdAttrNs_ = GLOBAL_PLUGIN_ID_ATTR_NS;
  +private static String globalPluginIdAttr_ = GLOBAL_PLUGIN_ID_ATTR;
  +
  +// see setPluginClassAttribute
  +private String pluginClassAttrNs_ = globalPluginClassAttrNs_;
  +private String pluginClassAttr_ = globalPluginClassAttr_;
  +
  +// see setPluginIdAttribute
  +private String pluginIdAttrNs_ = globalPluginIdAttrNs_;
  +private String pluginIdAttr_ = globalPluginIdAttr_;
   
   /**
* In order to invoke the addRules method on the plugin class correctly,
  @@ -114,6 +137,76 @@
*/
   private PluginRules localRules_; 
   
  +// static methods ---
  +
  +/**
  + * Sets the xml attribute which the input xml uses to indicate to a 
  + * PluginCreateRule which class should be instantiated.
  + * p
  + * Example:
  + * pre
  + * PluginCreateRule.setGlobalPluginClassAttribute(null, class);
  + * /pre
  + * will allow this in the input xml:
  + * pre
  + *  [root]
  + *[some-plugin class=com.acme.widget] ..
  + * /pre
  + *
  + * Note that this changes the default for iall/i PluginCreateRule
  + * instances. To override just specific PluginCreateRule instances (which
  + * may be more friendly in container-based environments), see method
  + * setPluginClassAttribute.
  + *
  + * @param namespaceUri is the namespace uri that the specified attribute
  + * is in. If the attribute is in no namespace, then this should be null.
  + * Note that if a namespace is used, the attrName value should inot/i
  + * contain any kind of namespace-prefix. Note also that if you are using
  + * a non-namespace-aware parser, this parameter imust/i be null.
  + *
  + * @param attrName is the attribute whose value contains the name of the
  + * class to be instantiated.
  + */
  +public static void setGlobalPluginClassAttribute(
  +String namespaceUri, String attrName) {
  +globalPluginClassAttrNs_ = namespaceUri;
  +globalPluginClassAttr_ = attrName;
  +}
  +
  +/**
  + * Sets the xml attribute which the input xml uses to indicate to a 
  + * PluginCreateRule which plugin declaration is being referenced.
  + * p
  + * Example:
  + * pre
  + * PluginCreateRule.setGlobalPluginIdAttribute(null, id);
  + * /pre
  + * will allow this in the input xml:
  + * pre
  + *  [root]
  + *[some-plugin id=widget] ..
  + * /pre
  + *
  + * Note that this changes the default for iall/i PluginCreateRule
  + * instances. To override just specific PluginCreateRule instances (which
  + * may be more friendly in container-based environments), see method
  + * setPluginIdAttribute.
  + *
  + * @param namespaceUri is the namespace uri that the specified attribute
  + * is in. If the attribute is in no namespace, then

RE: [codec] Streamable Codec Framework

2003-11-12 Thread Brett Henderson

I made some changes to the code I supplied previously, it can
be found at the following URL.

http://www32.brinkster.com/bretthenderson/BHCodec-0.5.zip

The main differences relate to the codec interfaces and support
for data types other than byte, the encoding algorithms
are largely unchanged.

A quick summary of the framework is as follows:

Framework is based around consumers and producers, consumers
accept incoming data and producers produce outgoing data. A
consumer implements the Consumer interface and a producer
implements the Producer interface.

Specialisations of these interfaces are used for each type
of data to be converted.  For example there are currently
ByteConsumer, ByteProducer, CharConsumer and CharProducer
interfaces.

The engine package contains classes (and interfaces) that
are both consumers and producers (ie. accept incoming data
and produce result data).  For example there is a ByteEngine
interface that implements ByteConsumer and ByteConsumer
interfaces and is in turn implemented by the Base64Encode
concrete class.

Engines may consume one kind of data and produce another,
the CharByteEngine interface defines an engine that
consumes characters and produces bytes.  This is implemented
by the CharSetEncode class (untested).

The consumer package contains classes that consume data
and perform an action on the data that doesn't allow it to
be accessed via producer functionality.  For example, the
BufferByteConsumer class acts as a receiving buffer for
encoding results, the OutputStreamConsumer writes all data
to an OutputStream.

The producer package contains classes that produce data
for the framework but don't accept data via consumer
functionality.  For example, the OutputStreamProducer
is an OutputStream that produces all data passed to it.

The io package contains classes that fit into the java.io
functionality that are neither consumers or producers in
the framework sense.  For example, the CodecOutputStream
is a FilterOutputStream that uses an internal ByteEngine
to perform a transformation on the data passing through it.

JUnit tests exist for most classes in the framework.
All testing is performed using JUnit.  If there is no unit
test for a class, it can be considered untested.

The framework is now generic enough to handle data of any
type and allow classes to be defined which can accept
any kind of data and/or produce any kind of data.  All
data can be processed in a streamy fashion.  For example,
encoding engines implementing the ByteEngine interface
can be plugged into CodecOutputStream or CodecInputStream
and used for stream functionality without directly
supporting java.io streams.

Using the CharSetEncode and (currently non-existent)
CharSetDecode, it should be possible to encode character
data to base64 then write result to a Writer.  This
should go part way towards helping Konstantin with his
XML conversions.

Sorry about the brain dump but there is a fair bit
contained in the zip file and I thought some explanation
would be useful.

Any feedback on the above is highly welcome.  I don't
plan on making too many more changes unless it is
deemed useful.

Brett


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: math to apache commons was Re: [all] Separate email list for math development?

2003-11-12 Thread Rodney Waldhoff

I'd say that the discussed scope, at least some visions of it, make it
more appropriate for a top level project than apache-commons, but I'll
second Henri's advice to cut a 1.0 release from jakarta-commons and draft
up a scope/vision document, then make the choice based upon what
feels right at the point.

I don't think it stretches the jakarta-commons or jakarta-general scope
much (or at all, relative to other jakarta projects) to include a set of
basic, java-based mathematical utilities--there are certainly plenty of
server-side applications of that.

A set of basic, not-necessarily-java-based utilities would be more
appropriate in apache-commons.

A more-than-basic set of utilities, in or out of java, would be more
appropriate at the top level IMO.

How one defines basic here is obviously an important part of answering
this question.

On Wed, 12 Nov 2003, Danny Angus wrote:


 Robert wrote:
  IMHO we're now starting to forget the original
  charter.

 Gier replied:
  Starting???  :)  Please, we've been stretching the charter for *years*.

 Isn't that a major contributory factor in the, how can I put it.. concern
 expressed in some quarters about Jakarta?
 And if so is it not also something we should be addressing by being
 realistic about issues like this one?


  You're notion of sorting it out seems to be remove from Jakarta
  community.  That may be what the people involved want to do, which is
  fine by me, but if they want to stay, it behooves us on the PMC to try
  and see what we can do to help them out.

 I'd say that if there is not a _real_ justification for math being in
 Jakarta which is aligned with Jakarta's mission it is our duty to Jakarta
 to be realistic about math, and not simply to fudge an artificial
 accomodation, avoid tough the decisons, and provide ammunition for critics
 of Jakarta's organisation.

 I would then feel that I had a moral obligation to the math community to
 help them find an acceptable new home, and Apache commons seems like a
 perfectly reasonable suggestion.
 After all if the math mission really is divergent from our charter then
 leaving won't be a big wrench, on the other hand if it is aligned well with
 the charter that is enough justification for math staying. Surely?

 d.



- Rod http://radio.weblogs.com/0122027/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[math] FW: Jampack

hi Akhilesh

many thanks for the information.

i'm going to forward this to the development list so everyone can take 
a look. (here at apache, we like to conduct as much business as 
possible on the public lists so that the whole community has the chance 
to enter into the discussion.)

- robert

On 4 Nov 2003, at 21:55, Akhilesh Maewal wrote:

This is prompted by the statements on the site that you are looking for
contributions for math packages.
You can use Jampack for a number of good math routines written by a 
very
well known researcher, who says, as the following exchange shows, that
the library is entirely in the public domain.

--- G. W. Stewart [EMAIL PROTECTED] wrote:
It is entirely in the public domain.  However, it is
no longer
being supported.  You might want to consider Jama,
another
matrix package.
Best,
Pete Stewart
On Tue, 12 Nov 2002, akhilesh maewal wrote:

Date: Tue, 12 Nov 2002 11:05:20 -0800 (PST)
From: akhilesh maewal [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Jampack
Hello Preofessor Stewart

Just found your Java suite Jampack on the web.

I could not find any document in the distribution
that
defines the terms of the license. In other words,
what
limitations do you have on the use of the
software?
Can I distribute it in a commercial package? I am
at a
very preliminary stage, and have no definite plans
of
this type at this time, but would like to make
sure
that in case I do, I do not infringe upon your
rights.
Sincerely
Akhilesh Maewal
__
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [digester] repost : patch for plugins

hi simon

i've committed the patch. many thanks.

i've correct the brackets in a few cases where you've used

...
}
catch (WhatEverException wee) {
...
to

} catch (WhatEverException wee) {

i don't want to get religious but it's good to have a convention (it  
really helps new developers). digester source keeps the catch brackets  
and the else brackets on the same line.

- robert

On 11 Nov 2003, at 05:04, Simon Kitching wrote:

Hi,

I sent a patch to allow users of the plugins module to select the xml
attribute which specifies the plugin declaration or class.
This was sent 2003-11-03. Would someone please have a look and commit  
it
unless there are objections?

This patch *only* affects the plugins module. It's also the last patch  
I
have lined up for the plugins module.

http://marc.theaimsgroup.com/?l=jakarta-commons- 
devm=106784768220233w=2

Thanks,

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]

Re: [digester] repost : patch for plugins

hi simon

i've committed the patch. many thanks.

i've correct the brackets in a few cases where you've used

...
}
catch (WhatEverException wee) {
...
to

} catch (WhatEverException wee) {

i don't want to get religious but it's good to have a convention (it  
really helps new developers). digester source keeps the catch brackets  
and the else brackets on the same line.

- robert

On 11 Nov 2003, at 05:04, Simon Kitching wrote:

Hi,

I sent a patch to allow users of the plugins module to select the xml
attribute which specifies the plugin declaration or class.
This was sent 2003-11-03. Would someone please have a look and commit  
it
unless there are objections?

This patch *only* affects the plugins module. It's also the last patch  
I
have lined up for the plugins module.

http://marc.theaimsgroup.com/?l=jakarta-commons- 
devm=106784768220233w=2

Thanks,

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]

Re: [math] FW: Jampack

2003-11-12 Thread Mark R. Diggory

When it rains it pours! :-)

If there is a reason that we need some space outside of Jakarta Commons, 
its simply to sort out all the possible inclusions that could occur in 
the long run. Really, allot of what we're doing here is not building 
this functionality, as much as consolidating and organizing.

Its important to note that JAMA and JAMPACK are NIST projects. JAMA is 
in Coordination with MathWorks (AKA MATLAB) and is the proposed standard 
implementation Java Grande is working to get into the SDK.

http://www.javagrande.org/
http://math.nist.gov/javanumerics/jama/
ftp://math.nist.gov/pub/Jampack/Jampack/AboutJampack.html
They are highly involved with ACM and working to get Sun to integrate 
this Numerics stuff into the sdk. We should be coordinating with them as 
much as possible to provide a unified front of effort within JDC.

I'm tempted to contact the listed developers and see what the status is 
on this and their possible interest in using Apache...

-Mark

robert burrell donkin wrote:
hi Akhilesh

many thanks for the information.

i'm going to forward this to the development list so everyone can take a 
look. (here at apache, we like to conduct as much business as possible 
on the public lists so that the whole community has the chance to enter 
into the discussion.)

- robert

On 4 Nov 2003, at 21:55, Akhilesh Maewal wrote:

This is prompted by the statements on the site that you are looking for
contributions for math packages.
You can use Jampack for a number of good math routines written by a very
well known researcher, who says, as the following exchange shows, that
the library is entirely in the public domain.
--- G. W. Stewart [EMAIL PROTECTED] wrote:

It is entirely in the public domain.  However, it is
no longer
being supported.  You might want to consider Jama,
another
matrix package.
Best,
Pete Stewart
On Tue, 12 Nov 2002, akhilesh maewal wrote:

Date: Tue, 12 Nov 2002 11:05:20 -0800 (PST)
From: akhilesh maewal [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Jampack
Hello Preofessor Stewart

Just found your Java suite Jampack on the web.

I could not find any document in the distribution
that

defines the terms of the license. In other words,
what

limitations do you have on the use of the
software?

Can I distribute it in a commercial package? I am
at a

very preliminary stage, and have no definite plans
of

this type at this time, but would like to make
sure

that in case I do, I do not infringe upon your
rights.

Sincerely
Akhilesh Maewal
__
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies, Chunked-Post Threads

2003-11-12 Thread Roland Weber

Hello Sven,

1. Cookie Container:
Let every session use it's own HttpState object. That's where
HTTP Client stores it's cookies. The only problem is that it's
not serializable, so it won't work with persistent sessions.

2. Thread Safety:
HTTP Client is thread safe as long as you use a thread safe
connection manager.

3. Unlimited Requests:
Adjust the parameters of the MultiThreadedConnectionManager
to change the maximum number of simultaneous requests. Your
servlet container most likely has some load limitation policy, so
you don't have to allow much more connections than there are
threads to execute servlets.

(no clue about content length in POST requests)

regards,
  Roland






Sven Köhler [EMAIL PROTECTED]
12.11.2003 01:55
Please respond to Commons HttpClient Project
 
To: Commons HttpClient Project 
[EMAIL PROTECTED]
cc: 
Subject:Cookies, Chunked-Post  Threads


Hi,

i'm working on a so called ProxyServlet which uses the Information 
provided by the ServletContainer to deliver the Requests to another 
Web-Server.
At present, i'm using the HttpMethod-Objects (GetMethod, PutMethod, ...) 
and HttpClient.execute() to deliver the Requests to the other Web-Server.

I hope you can provide me with some sollutions to the following Problems:

- I like to maintain one Cookie-Container for each Session (Session = 
Session-Object offered by the Servlet-Container)
- I like my Servlet to be Thread-safe and be abled to deliver many 
(unlimited) requests at a time
- I tried to avoid the Content-Length Header in POST requests by using 
Chunked Transfer-Encoding, but the Apache-Server i'm using for testing 
seems to deny chunked POST-requests.

Well, how's cookie-management done in Commons-HttpClient? Does each 
HttpClient-Object maintain it's own Cookie-Container? 
HttpClient.execute() doesn't seem to be thread-safe.
I like chunked Transfer-Encoding since is more like a stream and not 
like that huge block of data that's usually used (content-length header 
etc.) Are chunked POST-Requests not allowed? Well, i'm setting the 
content-length header right now if it is provided to the servlet. So 
that's a big proble, but i'm just curious.

Thx
   Sven




-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]

Re: DO NOT REPLY [Bug 24309] - MultiThreadedHttpConnectionManager daemon Thread never GC'd

2003-11-12 Thread Ortwin Glück

Mike,

in the test case I would rather introduce a Thread.sleep AFTER the 
System.gc() call as well to give the GC time to run. GC happens 
asynchronously. The System.gc() call is not blocking!

Odi

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24309


--- Additional Comments From [EMAIL PROTECTED]  2003-11-12 00:27 ---
Any more thoughts on this one, or should I apply?
Mike



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve status line

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=24560.
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=24560

HttpClient loops endlessly while trying to retrieve status line





--- Additional Comments From [EMAIL PROTECTED]  2003-11-12 10:23 ---
Created an attachment (id=9064)
New patch, includes surplus response data check on first request (see mailing list)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve status line

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=24560.
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=24560

HttpClient loops endlessly while trying to retrieve status line





--- Additional Comments From [EMAIL PROTECTED]  2003-11-12 10:24 ---
Created an attachment (id=9065)
new version of TestBadPorts

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve status line

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=24560.
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=24560

HttpClient loops endlessly while trying to retrieve status line





--- Additional Comments From [EMAIL PROTECTED]  2003-11-12 10:24 ---
Created an attachment (id=9066)
New test: TestBadContentLength

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies, Chunked-Post Threads

2003-11-12 Thread Sven Köhler

HttpClient.executeMethod
   (HostConfiguration, HttpMethod, HttpState)
If you have used the same client from different
threads without specifying different states, that
might be a problem.
Well, i use this method now from different thread with different 
HttpStates. I'd like to use even one HttpState-Object from different 
threads! Is that possible. I'm doing that right now, but i'm not sure if 
 the HttpClient-APIs cares about that case.

If not, that would be very easy:

synchronized (state)
{
  //get cookie headers
}
//execute HTTP-request

synchronized (state)
{
  //put cookie header
}


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: DO NOT REPLY [Bug 24309] - MultiThreadedHttpConnectionManager daemon Thread never GC'd

2003-11-12 Thread Eric Johnson

Odi,

This is a curiosity, I agree.

I take this documentation from System.gc() at face value:
When control returns from the method call, the Java Virtual Machine 
*has* made a best effort to reclaim space from all discarded objects. 
(emphasis added) - In other words, it is blocking, although best 
effort is not exactly well defined  I've not really looked on the 
web, though, to see whether the actual implementation varies.

In my original patch, I found that the sleep was necessary in order to 
let the thread that was not being garbage collected actually finish 
processing; otherwise it would not be collected by the gc() call.  Since 
Mike's new approach no longer uses multiple threads, the sleep prior to 
the gc() call is unnecessary now.

-Eric.

Ortwin Glück wrote:

Mike,

in the test case I would rather introduce a Thread.sleep AFTER the 
System.gc() call as well to give the GC time to run. GC happens 
asynchronously. The System.gc() call is not blocking!

Odi

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24309


--- Additional Comments From [EMAIL PROTECTED]  2003-11-12 
00:27 ---
Any more thoughts on this one, or should I apply?

Mike



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

SSL-Connection to unstrusted host

2003-11-12 Thread Sven Khler

Well, the subject says it all:

I'd like to connect to a host with an untrusted SSL-certfictate. When 
trying to connect, i always get the following exception:

javax.net.ssl.SSLHandshakeException: 
sun.security.validator.ValidatorException:
No trusted certificate found
	at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
	at 
org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(HttpConnection.java:1351)
	at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
	at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124)
	at 
org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(HttpConnection.java:779)
	at 
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.flushRequestOutputStream(MultiThreadedHttpConnectionManager.java:1145)
	at 
org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2257)
	at 
org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBase.java:2629)
	at 
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1085)
	at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:674)
...

Is there any option to turn the check off?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies, Chunked-Post Threads

2003-11-12 Thread Roland Weber

Hello Sven,

unless you have taken special precautions, the state object
is used to store cookies. Using the same state from different
threads can mix up the cookies from different clients pretty
badly.
Once you have the cookie problem solved, there is no issue
with using the same state object. I dimly remember seeing
some synchronized statements in there. Anyway, except for
storing cookies, it is accessed read-only.

regards,
  Roland







Sven Köhler [EMAIL PROTECTED]
12.11.2003 15:02
Please respond to Commons HttpClient Project
 
To: Commons HttpClient Project 
[EMAIL PROTECTED]
cc: 
Subject:Re: Cookies, Chunked-Post  Threads


 HttpClient.executeMethod
(HostConfiguration, HttpMethod, HttpState)
 
 If you have used the same client from different
 threads without specifying different states, that
 might be a problem.

Well, i use this method now from different thread with different 
HttpStates. I'd like to use even one HttpState-Object from different 
threads! Is that possible. I'm doing that right now, but i'm not sure if 
  the HttpClient-APIs cares about that case.

If not, that would be very easy:

synchronized (state)
{
   //get cookie headers
}

//execute HTTP-request

synchronized (state)
{
   //put cookie header
}



-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]

Re: SSL-Connection to unstrusted host

2003-11-12 Thread Roland Weber

Hello Sven,

you will have to register your own secure socket factory.
In that factory, you can establish SSL connections without
verifying certificates. Alas, I don't remember whether such
code is included in the examples or has been posted to the
mailing list. But the topic itself pops up every few months,
so you're likely to find sample code somewhere.

See interface SecureProtocolSocketFactory and class
Protocol (method registerProtocol) to get started.

regards,
  Roland






Sven Köhler [EMAIL PROTECTED]
12.11.2003 15:10
Please respond to Commons HttpClient Project
 
To: Commons HttpClient Project 
[EMAIL PROTECTED]
cc: 
Subject:SSL-Connection to unstrusted host


Well, the subject says it all:

I'd like to connect to a host with an untrusted SSL-certfictate. When 
trying to connect, i always get the following exception:

javax.net.ssl.SSLHandshakeException: 
sun.security.validator.ValidatorException:
No trusted certificate found
 at 
com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
 at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
 at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
 at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
 at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
 at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)
 at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
 at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
 at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
 at 
com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
 at 
org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(HttpConnection.java:1351)
 at 
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
 at 
java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124)
 at 
org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(HttpConnection.java:779)
 at 
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.flushRequestOutputStream(MultiThreadedHttpConnectionManager.java:1145)
 at 
org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2257)
 at 
org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBase.java:2629)
 at 
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1085)
 at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:674)
...

Is there any option to turn the check off?


-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]

Re: Cookies, Chunked-Post Threads

2003-11-12 Thread Sven Köhler

unless you have taken special precautions, the state object
is used to store cookies. Using the same state from different
threads can mix up the cookies from different clients pretty
badly.
Once you have the cookie problem solved, there is no issue
with using the same state object. I dimly remember seeing
some synchronized statements in there. Anyway, except for
storing cookies, it is accessed read-only.
Well, it's a that odd application of the HttpState-Object since every 
browser makes multiple requests to a server in parrallel. So this would 
be a feature i would request.

Well, most methods of HttpState seem to be synchronized, but as i 
already mentioned, it's pretty easy to easy to solve any bad mix-up.

What i don't want is to serialize (meaning executing one after another) 
the HTTP-Requests. I want them to execute in parralel.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SSL-Connection to unstrusted host

2003-11-12 Thread Aaron Williams

I've also recently been getting this error and was hoping someone could
shed some light on it.

We're using the RC2 version of HttpClient and our JDK versions are all
1.4 or greater.  The client we are connecting to seems to have a
Verisign certificate.  Initially our client worked, but we later began
getting the SSLHandshakeException.  This occurred with no changes on the
client side.

We do have the lines

Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());
host.setHost(hostname, port, https);
client.setHostConfiguration(host);

Before we create PostMethod()

Here is the thrown exception

javax.net.ssl.SSLHandshakeException: Could not find the trusted
certificate 
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275) 
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) 
at com.sun.net.ssl.internal.ssl.ClientHandshaker.a(DashoA6275)  
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(DashoA6275)

at com.sun.net.ssl.internal.ssl.Handshaker.process_record(DashoA6275)   
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) 
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) 
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)   
at
org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(H
ttpConnection.java:1351)
at java.io.BufferedOutputStream.flushBuffer(Unknown Source) 
at java.io.BufferedOutputStream.flush(Unknown Source)   
at
org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(Ht
tpConnection.java:779)  
at
org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase
.java:2257) 
at
org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBa
se.java:2629)   
at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java
:1085)  
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:6
74) 
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:5
29)

Can anyone help with this?  Would using EasySSLProtocolSocketFactory
class fix this error?

Thanks,
Aaron
 

-Original Message-
From: Marcus Crafter [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 12, 2003 8:43 AM
To: Commons HttpClient Project
Subject: Re: SSL-Connection to unstrusted host


H Sven, Roland,

There's an example socket factory available on the website:

http://jakarta.apache.org/commons/httpclient/sslguide.html

Have a look for the EasySSLProtocolSocketFactory class.

Hope that helps.

Cheers,

Marcus

On Wed, 2003-11-12 at 15:34, Roland Weber wrote:
 Hello Sven,
 
 you will have to register your own secure socket factory.
 In that factory, you can establish SSL connections without verifying 
 certificates. Alas, I don't remember whether such code is included in 
 the examples or has been posted to the mailing list. But the topic 
 itself pops up every few months, so you're likely to find sample code 
 somewhere.
 
 See interface SecureProtocolSocketFactory and class
 Protocol (method registerProtocol) to get started.
 
 regards,
   Roland
 
 
 
 
 
 
 Sven Köhler [EMAIL PROTECTED]
 12.11.2003 15:10
 Please respond to Commons HttpClient Project
  
 To: Commons HttpClient Project 
 [EMAIL PROTECTED]
 cc: 
 Subject:SSL-Connection to unstrusted host
 
 
 Well, the subject says it all:
 
 I'd like to connect to a host with an untrusted SSL-certfictate. When
 trying to connect, i always get the following exception:
 
 javax.net.ssl.SSLHandshakeException:
 sun.security.validator.ValidatorException:
 No trusted certificate found
  at 
 com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
  at 
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
  at 
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
  at
com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
  at
com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
  at
com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)
  at 
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
  at 
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
  at 
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
  at 
 com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
  at 

org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(H
ttpConnection.java:1351)
  at 
 java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
  at 
 java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124)
  at 

org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(Ht
tpConnection.java:779)
  at 

org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpCon

DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve status line

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=24560.
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=24560

HttpClient loops endlessly while trying to retrieve status line





--- Additional Comments From [EMAIL PROTECTED]  2003-11-12 17:03 ---
Chritian,
I am a bit stressed out right now, but I'll try to take a closer look at your
patch tonight. There are things I would possible like to see done differently.
Feedback to follow. 

But I REALLY like your TestBadContentLength testcase. We all would greatly
appreciate if you could look at the possibility of replacing the current
SimpleHttpConnection based testing framework with something of based on your
approach.

Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: DO NOT REPLY [Bug 24309] - MultiThreadedHttpConnectionManage r daemon Thread never GC'd

2003-11-12 Thread Dennis Cook

I just a comment about GC.  Libraries that call for GCs are not very
application friendly.  When a library that is a small part of an application
explicitly invokes GCs, it can have a dramatic effect on the performance of
the whole application.  This must have been seen as a common problem,
because Java 1.4 offers the -XX:+DisableExplicitGC option to disable the
System.gc() and return control of GC back to the JVM where it belongs.  

Dennis Cook
BeVocal, Inc.
tel:  650-641-1424
fax: 650-210-9275


-Original Message-
From: Ortwin Glück [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 12:21 AM
To: Commons HttpClient Project
Subject: Re: DO NOT REPLY [Bug 24309] -
MultiThreadedHttpConnectionManager daemon Thread never GC'd


Mike,

in the test case I would rather introduce a Thread.sleep AFTER the 
System.gc() call as well to give the GC time to run. GC happens 
asynchronously. The System.gc() call is not blocking!

Odi

 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24309
 

 --- Additional Comments From [EMAIL PROTECTED]  2003-11-12 00:27
---
 Any more thoughts on this one, or should I apply?
 
 Mike
 


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

Problem with Basic Authentification and non ASCII characters

2003-11-12 Thread olaf . hahnl

Hi,

today an administrator reported a password related problem within one of
our applications to me. I tracked down the problem that the user had used
the german Umlaute äöü in his password.

Our application tried to log in to another web site using a get method from
HTTPClient 2.0 rc2 setting basic authentification, but authentification
failed because of the non ASCII characters.

We used the password ä-ö-ü for testing and it turned out that HTTPClient
translates this to ZGg6Py0/LT8=. Internet Explorer and Mozilla translates
this to ZGg65C32Lfw=. Using
org.apache.commons.httpclient.util.Base64.decode with the wrong string
results in ?-?-? where the second string results in the correct ä-ö-ü,
so encode and decode are not symetric.

Using the code below (I found some time ago on the internet) to translate
the password into the base64 version results in the correct string.

For me the question is, if a password with non ASCII characters is not
allowed at all (in the HTTPClient documentation I could not find a hint in
this direction or I have missed it), but even if not, browsers seem to
support it, so the used Base64-encoding class seems to be bugy and should
be fixed in 2.0, before it is completely replaced for 2.1.

Any thoughts or hints are welcome.

Regards,
Olaf





public class Base64
{
static String BaseTable[] = {
  A, B, C, D, E, F, G, H, I, J, K, L, M, N,
O, P,
  Q, R, S, T, U, V, W, X, Y, Z, a, b, c, d,
e, f,
  g, h, i, j, k, l, m, n, o, p, q, r, s, t,
u, v,
  w, x, y, z, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
+, /
  };

  public static String encode(String text) {
int n = text.length();
if (n  1)
  return text; // no bytes to encode!?!
StringBuffer output = new StringBuffer(n);

// read the entire file into the byte array
byte bytes[] = new byte[ (n)];
bytes = text.getBytes();

byte buf[] = new byte[4]; // array of base64 characters

int n3byt = n / 3; // how 3 bytes groups?
int nrest = n % 3; // the remaining bytes from the grouping
int k = n3byt * 3; // we are doing 3 bytes at a time
int linelength = 0; // current linelength
int i = 0; // index

// do the 3-bytes groups ...
while (i  k) {
  buf[0] = (byte) ( (bytes[i]  0xFC)  2);
  buf[1] = (byte) ( ( (bytes[i]  0x03)  4) |
   ( (bytes[i + 1]  0xF0)  4));
  buf[2] = (byte) ( ( (bytes[i + 1]  0x0F)  2) |
   ( (bytes[i + 2]  0xC0)  6));
  buf[3] = (byte) (bytes[i + 2]  0x3F);

  output.append(BaseTable[buf[0]]).append(BaseTable[buf[1]]).append(
  BaseTable[buf[2]]).append(BaseTable[buf[3]]);

  if ( (linelength += 4) = 76) {
output.append(\r\n);
linelength = 0;
  }
  i += 3;
}

// deals with with the padding ...
if (nrest == 2) {
  // 2 bytes left
  buf[0] = (byte) ( (bytes[k]  0xFC)  2);
  buf[1] = (byte) ( ( (bytes[k]  0x03)  4) |
   ( (bytes[k + 1]  0xF0)  4));
  buf[2] = (byte) ( (bytes[k + 1]  0x0F)  2);
}
else if (nrest == 1) {
  // 1 byte left
  buf[0] = (byte) ( (bytes[k]  0xFC)  2);
  buf[1] = (byte) ( (bytes[k]  0x03)  4);
}

if (nrest  0) {
  // send the padding
  if ( (linelength += 4) = 76)
output.append(\r\n);
  output.append(BaseTable[buf[0]]).append(BaseTable[buf[1]]);
  // Thanks to R. Claerman for the bug fix here!
  if (nrest == 2) {
output.append(BaseTable[buf[2]]);
  }
  else {
output.append(=);
  }
  output.append(=);
}
return output.toString();
  }
}


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

java.lang.NoClassDefFoundError: javax/crypto/NoSuchPaddingExcepti on

2003-11-12 Thread Khalid Ishaque

When I use JDK1.4 every thing works fine, but the second I switch to JDK
1.3.1, I get the java.lang.NoClassDefFoundError:
javax/crypto/NoSuchPaddingException error.  Any suggestions???
 
Thanks
 
--Khalid

Re: Problem with Basic Authentification and non ASCII characters

2003-11-12 Thread Eric Johnson

This would appear to be a character encoding issue.

In BasicScheme.authenticate, it currently does this:

return Basic  + HttpConstants.getAsciiString(
   Base64.encode(HttpConstants.getBytes(buffer.toString(;
I suspect it should be doing something like this:

return Basic  + HttpConstants.getAsciiString(
   Base64.encode(buffer.toString().getBytes(UTF-8) ) );
RFC 2617 appears to be mum on the issue.

Anyone else have a better clue?

-Eric.

P.S. I found this email which might be a useful place to start, but I 
couldn't figure out the answer from a quick read of it or its 
surrounding emails on the topic.

http://lists.w3.org/Archives/Public/ietf-http-wg/2003AprJun/0015.html

[EMAIL PROTECTED] wrote:

Hi,

today an administrator reported a password related problem within one of
our applications to me. I tracked down the problem that the user had used
the german Umlaute äöü in his password.
Our application tried to log in to another web site using a get method from
HTTPClient 2.0 rc2 setting basic authentification, but authentification
failed because of the non ASCII characters.
We used the password ä-ö-ü for testing and it turned out that HTTPClient
translates this to ZGg6Py0/LT8=. Internet Explorer and Mozilla translates
this to ZGg65C32Lfw=. Using
org.apache.commons.httpclient.util.Base64.decode with the wrong string
results in ?-?-? where the second string results in the correct ä-ö-ü,
so encode and decode are not symetric.
Using the code below (I found some time ago on the internet) to translate
the password into the base64 version results in the correct string.
For me the question is, if a password with non ASCII characters is not
allowed at all (in the HTTPClient documentation I could not find a hint in
this direction or I have missed it), but even if not, browsers seem to
support it, so the used Base64-encoding class seems to be bugy and should
be fixed in 2.0, before it is completely replaced for 2.1.
Any thoughts or hints are welcome.

Regards,
Olaf




public class Base64
{
static String BaseTable[] = {
 A, B, C, D, E, F, G, H, I, J, K, L, M, N,
O, P,
 Q, R, S, T, U, V, W, X, Y, Z, a, b, c, d,
e, f,
 g, h, i, j, k, l, m, n, o, p, q, r, s, t,
u, v,
 w, x, y, z, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
+, /
 };
 public static String encode(String text) {
   int n = text.length();
   if (n  1)
 return text; // no bytes to encode!?!
   StringBuffer output = new StringBuffer(n);
   // read the entire file into the byte array
   byte bytes[] = new byte[ (n)];
   bytes = text.getBytes();
   byte buf[] = new byte[4]; // array of base64 characters

   int n3byt = n / 3; // how 3 bytes groups?
   int nrest = n % 3; // the remaining bytes from the grouping
   int k = n3byt * 3; // we are doing 3 bytes at a time
   int linelength = 0; // current linelength
   int i = 0; // index
   // do the 3-bytes groups ...
   while (i  k) {
 buf[0] = (byte) ( (bytes[i]  0xFC)  2);
 buf[1] = (byte) ( ( (bytes[i]  0x03)  4) |
  ( (bytes[i + 1]  0xF0)  4));
 buf[2] = (byte) ( ( (bytes[i + 1]  0x0F)  2) |
  ( (bytes[i + 2]  0xC0)  6));
 buf[3] = (byte) (bytes[i + 2]  0x3F);
 output.append(BaseTable[buf[0]]).append(BaseTable[buf[1]]).append(
 BaseTable[buf[2]]).append(BaseTable[buf[3]]);
 if ( (linelength += 4) = 76) {
   output.append(\r\n);
   linelength = 0;
 }
 i += 3;
   }
   // deals with with the padding ...
   if (nrest == 2) {
 // 2 bytes left
 buf[0] = (byte) ( (bytes[k]  0xFC)  2);
 buf[1] = (byte) ( ( (bytes[k]  0x03)  4) |
  ( (bytes[k + 1]  0xF0)  4));
 buf[2] = (byte) ( (bytes[k + 1]  0x0F)  2);
   }
   else if (nrest == 1) {
 // 1 byte left
 buf[0] = (byte) ( (bytes[k]  0xFC)  2);
 buf[1] = (byte) ( (bytes[k]  0x03)  4);
   }
   if (nrest  0) {
 // send the padding
 if ( (linelength += 4) = 76)
   output.append(\r\n);
 output.append(BaseTable[buf[0]]).append(BaseTable[buf[1]]);
 // Thanks to R. Claerman for the bug fix here!
 if (nrest == 2) {
   output.append(BaseTable[buf[2]]);
 }
 else {
   output.append(=);
 }
 output.append(=);
   }
   return output.toString();
 }
}
-
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: Problem with Basic Authentification and non ASCII characters

2003-11-12 Thread Michael Becke

Hello Olaf,

Here's a quick patch that fixes the immediate problem.  From reading 
RFC 2616 and 2617 it seems to me that we should have been using 
ISO-8859-1 as the encoding instead of US-ASCII.  Please give this patch 
a try.

Mike



On Nov 12, 2003, at 3:32 PM, [EMAIL PROTECTED] wrote:

Hi,

today an administrator reported a password related problem within one 
of
our applications to me. I tracked down the problem that the user had 
used
the german Umlaute äöü in his password.

Our application tried to log in to another web site using a get method 
from
HTTPClient 2.0 rc2 setting basic authentification, but authentification
failed because of the non ASCII characters.

We used the password ä-ö-ü for testing and it turned out that 
HTTPClient
translates this to ZGg6Py0/LT8=. Internet Explorer and Mozilla 
translates
this to ZGg65C32Lfw=. Using
org.apache.commons.httpclient.util.Base64.decode with the wrong string
results in ?-?-? where the second string results in the correct 
ä-ö-ü,
so encode and decode are not symetric.

Using the code below (I found some time ago on the internet) to 
translate
the password into the base64 version results in the correct string.

For me the question is, if a password with non ASCII characters is not
allowed at all (in the HTTPClient documentation I could not find a 
hint in
this direction or I have missed it), but even if not, browsers seem to
support it, so the used Base64-encoding class seems to be bugy and 
should
be fixed in 2.0, before it is completely replaced for 2.1.

Any thoughts or hints are welcome.

Regards,
Olaf




public class Base64
{
static String BaseTable[] = {
  A, B, C, D, E, F, G, H, I, J, K, L, M, 
N,
O, P,
  Q, R, S, T, U, V, W, X, Y, Z, a, b, c, 
d,
e, f,
  g, h, i, j, k, l, m, n, o, p, q, r, s, 
t,
u, v,
  w, x, y, z, 0, 1, 2, 3, 4, 5, 6, 7, 8, 
9,
+, /
  };

  public static String encode(String text) {
int n = text.length();
if (n  1)
  return text; // no bytes to encode!?!
StringBuffer output = new StringBuffer(n);
// read the entire file into the byte array
byte bytes[] = new byte[ (n)];
bytes = text.getBytes();
byte buf[] = new byte[4]; // array of base64 characters

int n3byt = n / 3; // how 3 bytes groups?
int nrest = n % 3; // the remaining bytes from the grouping
int k = n3byt * 3; // we are doing 3 bytes at a time
int linelength = 0; // current linelength
int i = 0; // index
// do the 3-bytes groups ...
while (i  k) {
  buf[0] = (byte) ( (bytes[i]  0xFC)  2);
  buf[1] = (byte) ( ( (bytes[i]  0x03)  4) |
   ( (bytes[i + 1]  0xF0)  4));
  buf[2] = (byte) ( ( (bytes[i + 1]  0x0F)  2) |
   ( (bytes[i + 2]  0xC0)  6));
  buf[3] = (byte) (bytes[i + 2]  0x3F);
  
output.append(BaseTable[buf[0]]).append(BaseTable[buf[1]]).append(
  BaseTable[buf[2]]).append(BaseTable[buf[3]]);

  if ( (linelength += 4) = 76) {
output.append(\r\n);
linelength = 0;
  }
  i += 3;
}
// deals with with the padding ...
if (nrest == 2) {
  // 2 bytes left
  buf[0] = (byte) ( (bytes[k]  0xFC)  2);
  buf[1] = (byte) ( ( (bytes[k]  0x03)  4) |
   ( (bytes[k + 1]  0xF0)  4));
  buf[2] = (byte) ( (bytes[k + 1]  0x0F)  2);
}
else if (nrest == 1) {
  // 1 byte left
  buf[0] = (byte) ( (bytes[k]  0xFC)  2);
  buf[1] = (byte) ( (bytes[k]  0x03)  4);
}
if (nrest  0) {
  // send the padding
  if ( (linelength += 4) = 76)
output.append(\r\n);
  output.append(BaseTable[buf[0]]).append(BaseTable[buf[1]]);
  // Thanks to R. Claerman for the bug fix here!
  if (nrest == 2) {
output.append(BaseTable[buf[2]]);
  }
  else {
output.append(=);
  }
  output.append(=);
}
return output.toString();
  }
}
-
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: Problem with Basic Authentification and non ASCII characters

2003-11-12 Thread Michael Becke

As per usual the patch was stripped.  I will attach it to bugzilla.

Mike

On Nov 12, 2003, at 9:59 PM, Michael Becke wrote:

Hello Olaf,

Here's a quick patch that fixes the immediate problem.  From reading 
RFC 2616 and 2617 it seems to me that we should have been using 
ISO-8859-1 as the encoding instead of US-ASCII.  Please give this 
patch a try.

Mike



On Nov 12, 2003, at 3:32 PM, [EMAIL PROTECTED] wrote:

Hi,

today an administrator reported a password related problem within one 
of
our applications to me. I tracked down the problem that the user had 
used
the german Umlaute äöü in his password.

Our application tried to log in to another web site using a get 
method from
HTTPClient 2.0 rc2 setting basic authentification, but 
authentification
failed because of the non ASCII characters.

We used the password ä-ö-ü for testing and it turned out that 
HTTPClient
translates this to ZGg6Py0/LT8=. Internet Explorer and Mozilla 
translates
this to ZGg65C32Lfw=. Using
org.apache.commons.httpclient.util.Base64.decode with the wrong string
results in ?-?-? where the second string results in the correct 
ä-ö-ü,
so encode and decode are not symetric.

Using the code below (I found some time ago on the internet) to 
translate
the password into the base64 version results in the correct string.

For me the question is, if a password with non ASCII characters is not
allowed at all (in the HTTPClient documentation I could not find a 
hint in
this direction or I have missed it), but even if not, browsers seem to
support it, so the used Base64-encoding class seems to be bugy and 
should
be fixed in 2.0, before it is completely replaced for 2.1.

Any thoughts or hints are welcome.

Regards,
Olaf




public class Base64
{
static String BaseTable[] = {
  A, B, C, D, E, F, G, H, I, J, K, L, 
M, N,
O, P,
  Q, R, S, T, U, V, W, X, Y, Z, a, b, 
c, d,
e, f,
  g, h, i, j, k, l, m, n, o, p, q, r, 
s, t,
u, v,
  w, x, y, z, 0, 1, 2, 3, 4, 5, 6, 7, 
8, 9,
+, /
  };

  public static String encode(String text) {
int n = text.length();
if (n  1)
  return text; // no bytes to encode!?!
StringBuffer output = new StringBuffer(n);
// read the entire file into the byte array
byte bytes[] = new byte[ (n)];
bytes = text.getBytes();
byte buf[] = new byte[4]; // array of base64 characters

int n3byt = n / 3; // how 3 bytes groups?
int nrest = n % 3; // the remaining bytes from the grouping
int k = n3byt * 3; // we are doing 3 bytes at a time
int linelength = 0; // current linelength
int i = 0; // index
// do the 3-bytes groups ...
while (i  k) {
  buf[0] = (byte) ( (bytes[i]  0xFC)  2);
  buf[1] = (byte) ( ( (bytes[i]  0x03)  4) |
   ( (bytes[i + 1]  0xF0)  4));
  buf[2] = (byte) ( ( (bytes[i + 1]  0x0F)  2) |
   ( (bytes[i + 2]  0xC0)  6));
  buf[3] = (byte) (bytes[i + 2]  0x3F);
  
output.append(BaseTable[buf[0]]).append(BaseTable[buf[1]]).append(
  BaseTable[buf[2]]).append(BaseTable[buf[3]]);

  if ( (linelength += 4) = 76) {
output.append(\r\n);
linelength = 0;
  }
  i += 3;
}
// deals with with the padding ...
if (nrest == 2) {
  // 2 bytes left
  buf[0] = (byte) ( (bytes[k]  0xFC)  2);
  buf[1] = (byte) ( ( (bytes[k]  0x03)  4) |
   ( (bytes[k + 1]  0xF0)  4));
  buf[2] = (byte) ( (bytes[k + 1]  0x0F)  2);
}
else if (nrest == 1) {
  // 1 byte left
  buf[0] = (byte) ( (bytes[k]  0xFC)  2);
  buf[1] = (byte) ( (bytes[k]  0x03)  4);
}
if (nrest  0) {
  // send the padding
  if ( (linelength += 4) = 76)
output.append(\r\n);
  output.append(BaseTable[buf[0]]).append(BaseTable[buf[1]]);
  // Thanks to R. Claerman for the bug fix here!
  if (nrest == 2) {
output.append(BaseTable[buf[2]]);
  }
  else {
output.append(=);
  }
  output.append(=);
}
return output.toString();
  }
}
-
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 24671] New: - Basic Authentification fails with non-ASCII username/password characters

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=24671.
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=24671

Basic Authentification fails with non-ASCII username/password characters

   Summary: Basic Authentification fails with non-ASCII
username/password characters
   Product: Commons
   Version: Nightly Builds
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: HttpClient
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


http://marc.theaimsgroup.com/?t=10686695951r=1w=2

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24671] - Basic Authentification fails with non-ASCII username/password characters