date:20031105

On Wednesday, November 5, 2003, at 12:10 AM, Phil Steitz wrote:
I think that that javadoc for remove is incorrect when it says:
This implementation calls coderemove()/code on each collection. 
It stops when it finds the element to be removed.  The contract needs 
to be made more explicit here.  It might actually be better to push 
remove() into the Mutator, since one could argue that the current 
remove strategy (kill the first one found) is no less arbitrary than 
a default add strategy that just adds to the last collection.  Might 
be better to make this pluggable like add.
To quote the Collection API doc:
quote
Removes a single instance of the specified element from this  
collection, if it is present (optional operation).  More formally,  
removes an element e such that (o==null ?  e==null :  o.equals(e)), if 
this collection contains one or more such  elements.
/quote

I agree that this could be pluggable, but I think that providing a 
remove first found as a default is very reasonable in this case as it 
fits the idiomatic behavior people expect from extent collections.

+0 (non-binding) for putting this into the CollectionMutator but 
providing present behavior as default if no mutator set (rather than an 
exception as add/addAll do. This is internally inconsistent though so I 
would welcome better ideas.

The containsAll javadoc says This is O(n^2) at the moment, be careful 
using it..
It is not correct anymore. It was in the original version but the 
implementation has changed significantly already =)

I am curious about how much faster this can be done without an 
ordering.
Dropping ordering on what?

The last comment suggests another possibly useful method:
toList(), returning an aggregated collection consisting of all of the 
objects in the composite collections.
That works for me, though I would make it a Collection and return the 
actual type of whichever subclass. I suspect Stephen will suggest that 
it be toCollection(), toList(), and toSet() respectively in order to 
allow greater specificity of the return type, which I am also okay with.

Hmm, would be nice if Java let you override a method to return a 
subclass of the return type of the method being overridden. It would 
satisfy the static typing still.

-Brian

PS: I have attached changes discussed

/*
 * $Header: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/Closure.java,v
 1.7 2003/08/31 17:26:44 scolebourne Exp $
 * 
 *
 * 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 The Jakarta Project, Commons, and Apache Software
 *Foundation must not be used to endorse or promote products derived
 *from this software without prior written permission. For written
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called Apache
 *nor may Apache appear in their names without prior written
 *permission of the Apache 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

Re: [collections] [PATCH] CompositeCollection class for Commons-Collections

On Monday, November 3, 2003, at 07:48 PM, Stephen Colebourne wrote:

I've updated the class in line with commons standards/documentation 
etc. It
will probably end up in the decorators subpackage, as it decorates 
other
collections.

A few style questions about this...

You have changed the array traversal to use the form:

public int size() {
int size = 0;
for (int i = this.all.length - 1; i = 0 ; i--) {
size += this.all[i].size();
}
return size;
}
Do you really see a performance gain from not dereferencing 
this.all.length on each cycle? If so, cool stuff!

-Brian


PGP.sig
Description: This is a digitally signed message part

Re: [Math] common-math and bloated 3rd party libraries

On Wednesday, November 5, 2003, at 09:26 AM, __matthewHawthorne wrote:

I, for one, like the idea of commons projects depending on each other 
when necessary.  There is always a lot of controversy with regards to 
including another jar that I don't quite understand.  I agree that 
if there are only 1 or 2 references, it may be reasonable to include 
the dependencies as package private classes, or make more of an effort 
to avoid them in the first place.  But this avoidance of code reuse 
sometimes disturbs me.

Are you short on disk space or something?  To me, 850 kb isn't really 
that much.


Reuse where the price of reuse is lower than the price of a better 
design is fine, but here the better design cost is negligible. Don't 
add dependencies unless you really need them, please.

Why does a math module depend on a logging module for deployment? Have 
the unit tests log, not the math functions.

=)

-Brian


PGP.sig
Description: This is a digitally signed message part

RE: [Math] common-math and bloated 3rd party libraries

2003-11-05 Thread Eric Pugh

This backlash against multiple commons jars is happening in a lot of places.
However, I think it is a bit shortsighted.  If you are in a non server
environment, I understand the problem, but in a server environment with lots
of harddrive space, I don't.  Additionally, since in a server app you are
likely to need all thoses dependencies any way.  I think almost every app I
work on has commons-lang, commons-loggin, and commons-collections included.
And then depending on what else, commons-discovery and commons-beanutils
show up all the time!

By removing the dependency on commons-lang etc you also remove the ability
to leverage their code when something better comes out.  You end up copying
and pasting more and more out of all these projects in math.  And don't get
the benefit of the testing, bugfixing etc they go through..

Maybe a better approach is to try and figure out why things like
commons-collections are so big, and should they be shrunk down or partioned?

Eric

 -Original Message-
 From: Kasper Nielsen [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, November 05, 2003 2:55 PM
 To: [EMAIL PROTECTED]
 Subject: [Math] common-math and bloated 3rd party libraries


 Hi gang,

 I love commons-math, one problem though!

 lets take a look at the dependecies

 common-lang: 189 kb
 commons-beanutils: 116 kb
 commons-collections-SNAPSHOT.jar 463
 commons-discovery 70 kb
 commons-logging-1.0.3.jar 31 kb kb

 Thats 850 kb!!! of 3rd party libraries that are only used in
 a few places.
 So to calculate a simple mean I need to include around 6 jars
 (including
 commons-math)

 So lets get the list down a bit.

 * Commons-lang
 Getting rid of Commons-lang is pretty easy since it is only
 used in one
 place: MathException
 Solution : Let MathException extend Exception instead of
 NestableException. There aren't really anywhere we use the ability to
 nest Exceptions inside other Exceptions in commons-math.

 * Commons-collections
 Getting rid of commons-collections is also pretty easy
 Solution: Getting a copy of HashBag (and the Testcase) and put into
 math.util (no need to copy the interface)

 now we got rid of ~ 650 kb in around 2 minutes, 3 jars left,
 this is a
 fun game!!

 * Commons-Beanutils
 Okay the transformers are nice but come on how many people
 are going to
 use them?
 Solution: put them into a new small library:
 commons-math-transformers.jar

 ** Commons-Discovery
 KISS keep it simple stupid, who on earth is going to provide
 there own
 UnivariateRealSolverFactory??
 and for those few people that need it... I think they are
 smart enough
 to do figure it out themself.
 Solution: remove it (or do something like we do for commons-logging)

 ** Commons-logging
 Lastly commons-logging...
 I would think returning NaN is enough, but okay if people
 insist we can
 do something like (pseudo code)

 public class logutil
 static Method logMethod;
  static {
  try
  {
  Class clazz = Class.forName(commons.LogFactory);
  logMethod = clazz.getMethod(error);
  }
  catch (ClassNotFoundException e) {}
  }
  public static logError(String msg, Throwable t)
  {
  if (logMethod!=null)
  {
  logMethod.invoke(msg + t);
  }
  }
 }

 and whoops we have now gotten rid of all the libraries, and
 we have easy
 embeddable little commons math jar.

 regards
Kasper

 
 Kasper Nielsen
 kaspern at apache.org


 -
 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] common-math and bloated 3rd party libraries

Hehehe, thats a novel idea. Ok to be devils advocate...

Your coming at this from  one jar perspective. Which leads me to 
wonder why having math be one jar is important to you? Can you please 
elaborate on this?

And to the rest of the community I postulate: Is this a critical usage case?

The commons libraries are planned/designed to be used together. So we 
make great gains in removing replicated effort by using them when the 
proper situation provides itself. Key word here proper. Because in the 
long run, the circular dependency issues and usage of our math component 
also becomes critical to any group who doesn't wish to drag along a 
bunch of dependencies, and this may very well occur, even with another 
commons project using our library. So I'll go through and try to make 
some appropriate comments below.

Kasper Nielsen wrote:
Hi gang,

I love commons-math, one problem though!

lets take a look at the dependecies

common-lang: 189 kb
commons-beanutils: 116 kb
commons-collections-SNAPSHOT.jar 463
commons-discovery 70 kb
commons-logging-1.0.3.jar 31 kb kb
Thats 850 kb!!! of 3rd party libraries that are only used in a few places.
So to calculate a simple mean I need to include around 6 jars (including 
commons-math)

So lets get the list down a bit.

* Commons-lang
Getting rid of Commons-lang is pretty easy since it is only used in one 
place: MathException
Solution : Let MathException extend Exception instead of 
NestableException. There aren't really anywhere we use the ability to 
nest Exceptions inside other Exceptions in commons-math.

Really, I'm not so sure I really like NestableException now that I look 
at it. It just adds a whole bunch of complexity to the simple and 
integral idea that something throws an exception and you catch it. I'm 
not sure, but I think the idea of throwing the same exception object 
multiple times is just horrid. I wouldn't mind seeing it go away from 
our Exceptions. Others may think otherwise...


* Commons-collections
Getting rid of commons-collections is also pretty easy
Solution: Getting a copy of HashBag (and the Testcase) and put into 
math.util (no need to copy the interface)

Not so sure I'm into moving classes out of other commons projects and 
adding them to ours. HashBag is a fairly generic and useful class, 
chances are that if your using commons-math you'll probably also want to 
be using commons-collections.


now we got rid of ~ 650 kb in around 2 minutes, 3 jars left, this is a 
fun game!!

* Commons-Beanutils
Okay the transformers are nice but come on how many people are going to 
use them?
Solution: put them into a new small library: commons-math-transformers.jar

I'm thinking it would be just as easy to directly use the reflection api 
in our case.


** Commons-Discovery
KISS keep it simple stupid, who on earth is going to provide there own 
UnivariateRealSolverFactory??
and for those few people that need it... I think they are smart enough 
to do figure it out themself.
Solution: remove it (or do something like we do for commons-logging)

Its also used to discover new distribution factories under 
o.a.m.stat.distributions Its interesting, I guess I don't understand 
what discovery really adds, as a feature, on top of Java's own Service 
Provider discovery? Anyways, is a pretty small library, I'm less 
inclined to chuck it because of the bloat issue.



** Commons-logging
Lastly commons-logging...
I would think returning NaN is enough, but okay if people insist we can 
do something like (pseudo code)

public class logutil
   static Method logMethod;
static {
try
{
Class clazz = Class.forName(commons.LogFactory);
logMethod = clazz.getMethod(error);
}
catch (ClassNotFoundException e) {}
}
public static logError(String msg, Throwable t)
{
if (logMethod!=null)
{
logMethod.invoke(msg + t);
}
}
}
Logging is a damn good thing to do in a standardized way, commons 
logging really provides a solid transitional api between commons tools 
and other logging api's. Its tiny, I'm not sure I think it's a great 
idea to replace it with custom code.

The above code scares me because reflection always adds a layer of 
complexity to stack traces and this type of approach makes it harder to 
interpret the logging and errors.


and whoops we have now gotten rid of all the libraries, and we have easy 
embeddable little commons math jar.

regards
  Kasper

Kasper Nielsen
kaspern at apache.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Math] common-math and bloated 3rd party libraries



Brian McCallister wrote:

On Wednesday, November 5, 2003, at 09:26 AM, __matthewHawthorne wrote:

Why does a math module depend on a logging module for deployment? Have 
the unit tests log, not the math functions.

=)

 -Brian

Bright Idea...I hadn't really thought about that. :-)

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

RE: [Math] common-math and bloated 3rd party libraries


--- Eric Pugh [EMAIL PROTECTED] wrote:
 This backlash against multiple commons jars is happening in a lot of
 places.
 However, I think it is a bit shortsighted.  If you are in a non server
 environment, I understand the problem, but in a server environment with
 lots
 of harddrive space, I don't.  

Agreed, especially because Jakarta's mission is to create *server* side
libraries.

 Additionally, since in a server app you
 are
 likely to need all thoses dependencies any way.  I think almost every
 app I
 work on has commons-lang, commons-loggin, and commons-collections
 included.
 And then depending on what else, commons-discovery and commons-beanutils
 show up all the time!
 
 By removing the dependency on commons-lang etc you also remove the
 ability
 to leverage their code when something better comes out.  You end up
 copying
 and pasting more and more out of all these projects in math.  And don't
 get
 the benefit of the testing, bugfixing etc they go through..

In this case, it looks like commons-lang and commons-logging are only
needed because math doesn't use Java 1.4 as the base level.  Moving to
Java 1.4 has the advantage of providing exception chaining and logging in
the Java core and eliminates 2 jars.  Obviously, the disadvantage is that
1.3 users can't use commons-math.

The need to support 1.3 is diminishing over time.  Java 1.4 is available
and runs well on all the major platforms I can think of.

David

 
 Maybe a better approach is to try and figure out why things like
 commons-collections are so big, and should they be shrunk down or
 partioned?
 
 Eric
 
  -Original Message-
  From: Kasper Nielsen [mailto:[EMAIL PROTECTED]
  Sent: Wednesday, November 05, 2003 2:55 PM
  To: [EMAIL PROTECTED]
  Subject: [Math] common-math and bloated 3rd party libraries
 
 
  Hi gang,
 
  I love commons-math, one problem though!
 
  lets take a look at the dependecies
 
  common-lang: 189 kb
  commons-beanutils: 116 kb
  commons-collections-SNAPSHOT.jar 463
  commons-discovery 70 kb
  commons-logging-1.0.3.jar 31 kb kb
 
  Thats 850 kb!!! of 3rd party libraries that are only used in
  a few places.
  So to calculate a simple mean I need to include around 6 jars
  (including
  commons-math)
 
  So lets get the list down a bit.
 
  * Commons-lang
  Getting rid of Commons-lang is pretty easy since it is only
  used in one
  place: MathException
  Solution : Let MathException extend Exception instead of
  NestableException. There aren't really anywhere we use the ability to
  nest Exceptions inside other Exceptions in commons-math.
 
  * Commons-collections
  Getting rid of commons-collections is also pretty easy
  Solution: Getting a copy of HashBag (and the Testcase) and put into
  math.util (no need to copy the interface)
 
  now we got rid of ~ 650 kb in around 2 minutes, 3 jars left,
  this is a
  fun game!!
 
  * Commons-Beanutils
  Okay the transformers are nice but come on how many people
  are going to
  use them?
  Solution: put them into a new small library:
  commons-math-transformers.jar
 
  ** Commons-Discovery
  KISS keep it simple stupid, who on earth is going to provide
  there own
  UnivariateRealSolverFactory??
  and for those few people that need it... I think they are
  smart enough
  to do figure it out themself.
  Solution: remove it (or do something like we do for commons-logging)
 
  ** Commons-logging
  Lastly commons-logging...
  I would think returning NaN is enough, but okay if people
  insist we can
  do something like (pseudo code)
 
  public class logutil
  static Method logMethod;
   static {
   try
   {
   Class clazz = Class.forName(commons.LogFactory);
   logMethod = clazz.getMethod(error);
   }
   catch (ClassNotFoundException e) {}
   }
   public static logError(String msg, Throwable t)
   {
   if (logMethod!=null)
   {
   logMethod.invoke(msg + t);
   }
   }
  }
 
  and whoops we have now gotten rid of all the libraries, and
  we have easy
  embeddable little commons math jar.
 
  regards
 Kasper
 
  
  Kasper Nielsen
  kaspern at apache.org
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


__
Do you Yahoo!?
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]

Re: [Math] common-math and bloated 3rd party libraries



David Graham wrote:
In this case, it looks like commons-lang and commons-logging are only
needed because math doesn't use Java 1.4 as the base level.  Moving to
Java 1.4 has the advantage of providing exception chaining and logging in
the Java core and eliminates 2 jars.  Obviously, the disadvantage is that
1.3 users can't use commons-math.
The need to support 1.3 is diminishing over time.  Java 1.4 is available
and runs well on all the major platforms I can think of.
David
And really, in the long run, if your developing and your stuck back on 
1.3.1, you have alot greater issues to be focusing on then adding a new 
library to your tool. If your not focusing on making the transition off 
an older obsolete JVM , your not going to be able to run on current 
platforms. Specifically, why should we tailor our packages for your 
obsolete code?

-Mark

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

RE: [Math] common-math and bloated 3rd party libraries

2003-11-05 Thread Gary Gregory

 The need to support 1.3 is diminishing over time.  Java 1.4 is available
 and runs well on all the major platforms I can think of.

We should be careful with 1.3 vs. 1.4. From my POV, sadly, the majority of
our customers run on a version WebSphere that only supports 1.3, which means
that our product can't use 1.4. Very sad.

I take the following perspective: basement libraries like Commons should be
reasonably conservative (look at Ant's SDK reqs) while the products one
writes on top of them can be more aggressive. *I* make the decision to ask
our customers to use 1.4 vs 1.3. I should not be forced to do that.

Gary

 -Original Message-
 From: David Graham [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, November 05, 2003 06:54
 To: Jakarta Commons Developers List
 Subject: RE: [Math] common-math and bloated 3rd party libraries
 
 
 --- Eric Pugh [EMAIL PROTECTED] wrote:
  This backlash against multiple commons jars is happening in a lot of
  places.
  However, I think it is a bit shortsighted.  If you are in a non server
  environment, I understand the problem, but in a server environment with
  lots
  of harddrive space, I don't.
 
 Agreed, especially because Jakarta's mission is to create *server* side
 libraries.
 
  Additionally, since in a server app you
  are
  likely to need all thoses dependencies any way.  I think almost every
  app I
  work on has commons-lang, commons-loggin, and commons-collections
  included.
  And then depending on what else, commons-discovery and commons-beanutils
  show up all the time!
 
  By removing the dependency on commons-lang etc you also remove the
  ability
  to leverage their code when something better comes out.  You end up
  copying
  and pasting more and more out of all these projects in math.  And don't
  get
  the benefit of the testing, bugfixing etc they go through..
 
 In this case, it looks like commons-lang and commons-logging are only
 needed because math doesn't use Java 1.4 as the base level.  Moving to
 Java 1.4 has the advantage of providing exception chaining and logging in
 the Java core and eliminates 2 jars.  Obviously, the disadvantage is that
 1.3 users can't use commons-math.
 
 The need to support 1.3 is diminishing over time.  Java 1.4 is available
 and runs well on all the major platforms I can think of.
 
 David
 
 
  Maybe a better approach is to try and figure out why things like
  commons-collections are so big, and should they be shrunk down or
  partioned?
 
  Eric
 
   -Original Message-
   From: Kasper Nielsen [mailto:[EMAIL PROTECTED]
   Sent: Wednesday, November 05, 2003 2:55 PM
   To: [EMAIL PROTECTED]
   Subject: [Math] common-math and bloated 3rd party libraries
  
  
   Hi gang,
  
   I love commons-math, one problem though!
  
   lets take a look at the dependecies
  
   common-lang: 189 kb
   commons-beanutils: 116 kb
   commons-collections-SNAPSHOT.jar 463
   commons-discovery 70 kb
   commons-logging-1.0.3.jar 31 kb kb
  
   Thats 850 kb!!! of 3rd party libraries that are only used in
   a few places.
   So to calculate a simple mean I need to include around 6 jars
   (including
   commons-math)
  
   So lets get the list down a bit.
  
   * Commons-lang
   Getting rid of Commons-lang is pretty easy since it is only
   used in one
   place: MathException
   Solution : Let MathException extend Exception instead of
   NestableException. There aren't really anywhere we use the ability to
   nest Exceptions inside other Exceptions in commons-math.
  
   * Commons-collections
   Getting rid of commons-collections is also pretty easy
   Solution: Getting a copy of HashBag (and the Testcase) and put into
   math.util (no need to copy the interface)
  
   now we got rid of ~ 650 kb in around 2 minutes, 3 jars left,
   this is a
   fun game!!
  
   * Commons-Beanutils
   Okay the transformers are nice but come on how many people
   are going to
   use them?
   Solution: put them into a new small library:
   commons-math-transformers.jar
  
   ** Commons-Discovery
   KISS keep it simple stupid, who on earth is going to provide
   there own
   UnivariateRealSolverFactory??
   and for those few people that need it... I think they are
   smart enough
   to do figure it out themself.
   Solution: remove it (or do something like we do for commons-logging)
  
   ** Commons-logging
   Lastly commons-logging...
   I would think returning NaN is enough, but okay if people
   insist we can
   do something like (pseudo code)
  
   public class logutil
   static Method logMethod;
static {
try
{
Class clazz = Class.forName(commons.LogFactory);
logMethod = clazz.getMethod(error);
}
catch (ClassNotFoundException e) {}
}
public static logError(String msg, Throwable t)
{
if (logMethod!=null)
{
logMethod.invoke(msg + t);
}
}
   }
  
   and whoops we have now

RE: [Math] common-math and bloated 3rd party libraries

2003-11-05 Thread Gary Gregory

I also like the idea of clearly established dependencies.

It would be nice for example, if we could slice and dice [lang] and
[collections] such that they could depend on a core set of jars.

Gary

 -Original Message-
 From: __matthewHawthorne [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, November 05, 2003 06:27
 To: Jakarta Commons Developers List
 Subject: Re: [Math] common-math and bloated 3rd party libraries
 
 I, for one, like the idea of commons projects depending on each other
 when necessary.  There is always a lot of controversy with regards to
 including another jar that I don't quite understand.  I agree that if
 there are only 1 or 2 references, it may be reasonable to include the
 dependencies as package private classes, or make more of an effort to
 avoid them in the first place.  But this avoidance of code reuse
 sometimes disturbs me.
 
 Are you short on disk space or something?  To me, 850 kb isn't really
 that much.
 
 
 
 
 Kasper Nielsen wrote:
  Hi gang,
 
  I love commons-math, one problem though!
 
  lets take a look at the dependecies
 
  common-lang: 189 kb
  commons-beanutils: 116 kb
  commons-collections-SNAPSHOT.jar 463
  commons-discovery 70 kb
  commons-logging-1.0.3.jar 31 kb kb
 
  Thats 850 kb!!! of 3rd party libraries that are only used in a few
 places.
  So to calculate a simple mean I need to include around 6 jars (including
  commons-math)
 
  So lets get the list down a bit.
 
  * Commons-lang
  Getting rid of Commons-lang is pretty easy since it is only used in one
  place: MathException
  Solution : Let MathException extend Exception instead of
  NestableException. There aren't really anywhere we use the ability to
  nest Exceptions inside other Exceptions in commons-math.
 
  * Commons-collections
  Getting rid of commons-collections is also pretty easy
  Solution: Getting a copy of HashBag (and the Testcase) and put into
  math.util (no need to copy the interface)
 
  now we got rid of ~ 650 kb in around 2 minutes, 3 jars left, this is a
  fun game!!
 
  * Commons-Beanutils
  Okay the transformers are nice but come on how many people are going to
  use them?
  Solution: put them into a new small library: commons-math-
 transformers.jar
 
  ** Commons-Discovery
  KISS keep it simple stupid, who on earth is going to provide there own
  UnivariateRealSolverFactory??
  and for those few people that need it... I think they are smart enough
  to do figure it out themself.
  Solution: remove it (or do something like we do for commons-logging)
 
  ** Commons-logging
  Lastly commons-logging...
  I would think returning NaN is enough, but okay if people insist we can
  do something like (pseudo code)
 
  public class logutil
 static Method logMethod;
  static {
  try
  {
  Class clazz = Class.forName(commons.LogFactory);
  logMethod = clazz.getMethod(error);
  }
  catch (ClassNotFoundException e) {}
  }
  public static logError(String msg, Throwable t)
  {
  if (logMethod!=null)
  {
  logMethod.invoke(msg + t);
  }
  }
  }
 
  and whoops we have now gotten rid of all the libraries, and we have easy
  embeddable little commons math jar.
 
  regards
Kasper
 
  
  Kasper Nielsen
  kaspern at apache.org
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: [functor] possible contributions

2003-11-05 Thread Herve Quiroz

I had another look at the current implementation of And/Or last night.
As the implementation already uses a collection, why not providing a
constructor with a collection as a parameter:

public Or(Collection collection)
{
this.list.addAll(collection);
}

(Or adding predicate one by one just to make sure they are actually
predicates)

This way, no need for static method.

This is not the way I would have done it (that's why I misunderstood the
way it is coded so far) as I believe OR and AND are binary operations.
So the only constructor would be:

public Or(Predicate left, Predicate right);

And then a static method could be:

public static And and(Collection predicates)
{
Predicate predicate=null;
for (Iterator i=predicates.iterator(); i.hasNext(); )
{
if (predicate==null)
predicate=(Predicate)i.next();
else
predicate=new And(predicate, (Predicate)i.next());
}
if (predicate instanceof And)
return predicate;
return new And(predicate, new ConstantPredicate(true));
}

PROS:
- AND/OR are binary operators
- fields and/or methods could allow to retrieve left and right
  members of a And/Or predicate
- lightweight (no need to use a collection for only a binary
  operation)

CONS:
- heavyweight when more than two predicates (because of the many
  nested And objects)
- need a static method (although a constructor with a Collection as
  a parameter is still possible)

I don't know if this method is better than the current one anyway... So
for now I'll just patch the constructor of the current implementation
(as described at the start of this mail).

Herve

On Tue, Nov 04, 2003 at 10:49:48AM -0800, Rodney Waldhoff wrote:
 Currently the AND and OR functions are not implemented as pure binary
 operations, but rather operations on a collection (list) of values.
 
 Specifically, each maintains a list of predicates.  OR evaluates to true
 if at least one child evaulates to true (and hence evalutes to false when
 the list is empty).  AND evaluates to true if all of its children evaluate
 to true (and hence evaluates to true when the list is empty).
 
 You can already do new And(a,b,c) or new And(a).and(b).and(c) or new
 And(a,b).and(c), etc., each of which should get you to the more or less
 tha same predicate.
 
 A static factory constructor, such as:
 
  And.and(a) == new And(a)
 
 or
 
  And.and(a,b) == new And(a,b)
 
 which would allow:
 
  And.and(a).and(b).and(c)
 
 or something like that would probably be convienient.
 
 So would:
 
  And.and(Collection)
 
 or
 
  And.and(Iterator)
 
 - Rod http://radio.weblogs.com/0122027/

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

[Math] Commons Math Contributions

2003-11-05 Thread Matt Cliff

- Original Message -
From: Matt Cliff [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 05, 2003 7:08 AM
Subject: Commons Math Contributions

   I recently download the math commons subproject and would like to help
 out.

   This is my first open source contribution effort and am looking forward
 to extending to other projects.   I have a background in Mathematics (MS
 and thesis work in Stochastic Analysis) and for the past several years
 worked as a project lead for a Java Company.

   Basically,
(1) What is the best way to contribute?   (submit patches to this
 mailing list or through the bug tracking system?)   Also,  will the bug
 tracking a new Math component to the Commons project?

(2) What should I be working on?  (what do we need to do to get it to a
 1.0 release?)   I would be more comfortable doing some 'maintenance' type
 work intially,  downstream I can offer more substantitve math  (I had done
 a bunch of work with DASSL and DASPK and their applications to Stochastic
 differential equations).

(3) Will there be a link on the
 http://jakarta.apache.org/commons/index.html page to the Math Compont
page?

(4) I added a quick type-o patch for the tasks.xml doc to see if it is
 the proper format.  (this is a cvs diff output)

   looking forward to helping out.

 --
   Matt Cliff
   Cliff Consulting
   303.757.4912
   720.280.6324 (c)

   The label said install Windows 98 or better so I installed Linux.

Index: xdocs/tasks.xml
===
RCS file: /home/cvspublic/jakarta-commons/math/xdocs/tasks.xml,v
retrieving revision 1.2
diff -u -r1.2 tasks.xml
--- xdocs/tasks.xml 1 Nov 2003 16:35:03 -   1.2
+++ xdocs/tasks.xml 5 Nov 2003 14:59:26 -
@@ -21,7 +21,7 @@
   ddClover tests show gaps in test path coverage. Get all tests to 100% 
coverage.  Also improve test data and boundary conditions coverage./dd
   dtCode review./dt
   dd
-pCode review is a continuous rpocess that all Contributors and 
Developers should practice while working on the code base./p
+pCode review is a continuous process that all Contributors and 
Developers should practice while working on the code base./p
 ul
   liJavadoc generation is still throwing warnings.  Bring the Javadoc 
into compliance (i.e. reach zero warnings)./li
   liVerify that the code matches the documentation and identify obvious 
inefficiencies or numerical problems.  All feedback/suggestions for 
improvement/patches are welcome./li

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

Re: [Math] common-math and bloated 3rd party libraries



Gary Gregory wrote:

The need to support 1.3 is diminishing over time.  Java 1.4 is available
and runs well on all the major platforms I can think of.


We should be careful with 1.3 vs. 1.4. From my POV, sadly, the majority of
our customers run on a version WebSphere that only supports 1.3, which means
that our product can't use 1.4. Very sad.
Yes, my last comment about 1.3.1 was probably a little extreme.

I take the following perspective: basement libraries like Commons should be
reasonably conservative (look at Ant's SDK reqs) while the products one
writes on top of them can be more aggressive. *I* make the decision to ask
our customers to use 1.4 vs 1.3. I should not be forced to do that.
Gary
Unfortunately, this is the challenge as more and more functionally 
separate libraries get glopped into the j2sdk core without any release 
as separately downloadable components. Suns Logging should have been a 
logically separate component that one should be able to add onto 1.3.1



-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 05, 2003 06:54
To: Jakarta Commons Developers List
Subject: RE: [Math] common-math and bloated 3rd party libraries
--- Eric Pugh [EMAIL PROTECTED] wrote:

This backlash against multiple commons jars is happening in a lot of
places.
However, I think it is a bit shortsighted.  If you are in a non server
environment, I understand the problem, but in a server environment with
lots
of harddrive space, I don't.
Agreed, especially because Jakarta's mission is to create *server* side
libraries.

Additionally, since in a server app you
are
likely to need all thoses dependencies any way.  I think almost every
app I
work on has commons-lang, commons-loggin, and commons-collections
included.
And then depending on what else, commons-discovery and commons-beanutils
show up all the time!
By removing the dependency on commons-lang etc you also remove the
ability
to leverage their code when something better comes out.  You end up
copying
and pasting more and more out of all these projects in math.  And don't
get
the benefit of the testing, bugfixing etc they go through..
In this case, it looks like commons-lang and commons-logging are only
needed because math doesn't use Java 1.4 as the base level.  Moving to
Java 1.4 has the advantage of providing exception chaining and logging in
the Java core and eliminates 2 jars.  Obviously, the disadvantage is that
1.3 users can't use commons-math.
The need to support 1.3 is diminishing over time.  Java 1.4 is available
and runs well on all the major platforms I can think of.
David


Maybe a better approach is to try and figure out why things like
commons-collections are so big, and should they be shrunk down or
partioned?
Eric


-Original Message-
From: Kasper Nielsen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 05, 2003 2:55 PM
To: [EMAIL PROTECTED]
Subject: [Math] common-math and bloated 3rd party libraries
Hi gang,

I love commons-math, one problem though!

lets take a look at the dependecies

common-lang: 189 kb
commons-beanutils: 116 kb
commons-collections-SNAPSHOT.jar 463
commons-discovery 70 kb
commons-logging-1.0.3.jar 31 kb kb
Thats 850 kb!!! of 3rd party libraries that are only used in
a few places.
So to calculate a simple mean I need to include around 6 jars
(including
commons-math)
So lets get the list down a bit.

* Commons-lang
Getting rid of Commons-lang is pretty easy since it is only
used in one
place: MathException
Solution : Let MathException extend Exception instead of
NestableException. There aren't really anywhere we use the ability to
nest Exceptions inside other Exceptions in commons-math.
* Commons-collections
Getting rid of commons-collections is also pretty easy
Solution: Getting a copy of HashBag (and the Testcase) and put into
math.util (no need to copy the interface)
now we got rid of ~ 650 kb in around 2 minutes, 3 jars left,
this is a
fun game!!
* Commons-Beanutils
Okay the transformers are nice but come on how many people
are going to
use them?
Solution: put them into a new small library:
commons-math-transformers.jar
** Commons-Discovery
KISS keep it simple stupid, who on earth is going to provide
there own
UnivariateRealSolverFactory??
and for those few people that need it... I think they are
smart enough
to do figure it out themself.
Solution: remove it (or do something like we do for commons-logging)
** Commons-logging
Lastly commons-logging...
I would think returning NaN is enough, but okay if people
insist we can
do something like (pseudo code)
public class logutil
   static Method logMethod;
static {
try
{
Class clazz = Class.forName(commons.LogFactory);
logMethod = clazz.getMethod(error);
}
catch (ClassNotFoundException e) {}
}
public static logError(String msg, Throwable t)
{
if (logMethod!=null)
{
logMethod.invoke(msg + t);
}
}
}
and whoops

RE: [Math] Commons Math Contributions

2003-11-05 Thread Mainguy, Mike

I'm in the same boat, a good answer would be appreciated (I've gotten a wide
variety).

Another thing I'm wondering is should we add ourselves as an author when we
submit a patch or is that just if you're a commiter?

worse is better 

-Original Message-
From: Matt Cliff [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 05, 2003 11:46 AM
To: [EMAIL PROTECTED]
Subject: [Math] Commons Math Contributions



- Original Message -
From: Matt Cliff [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 05, 2003 7:08 AM
Subject: Commons Math Contributions


   I recently download the math commons subproject and would like to 
 help out.

   This is my first open source contribution effort and am looking forward
 to extending to other projects.   I have a background in Mathematics (MS
 and thesis work in Stochastic Analysis) and for the past several years 
 worked as a project lead for a Java Company.


   Basically,
(1) What is the best way to contribute?   (submit patches to this
 mailing list or through the bug tracking system?)   Also,  will the bug
 tracking a new Math component to the Commons project?

(2) What should I be working on?  (what do we need to do to get it to a
 1.0 release?)   I would be more comfortable doing some 'maintenance' type
 work intially,  downstream I can offer more substantitve math  (I had 
 done a bunch of work with DASSL and DASPK and their applications to 
 Stochastic differential equations).

(3) Will there be a link on the 
 http://jakarta.apache.org/commons/index.html page to the Math Compont
page?

(4) I added a quick type-o patch for the tasks.xml doc to see if it 
 is the proper format.  (this is a cvs diff output)


   looking forward to helping out.

 --
   Matt Cliff
   Cliff Consulting
   303.757.4912
   720.280.6324 (c)


   The label said install Windows 98 or better so I installed 
 Linux.


-
This message and its contents (to include attachments) are the property of Kmart 
Corporation (Kmart) and may contain confidential and proprietary information. You are 
hereby notified that any disclosure, copying, or distribution of this message, or the 
taking of any action based on information contained herein is strictly prohibited. 
Unauthorized use of information contained herein may subject you to civil and criminal 
prosecution and penalties. If you are not the intended recipient, you should delete 
this message immediately.


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

Re: Company Acknowledgements [was :Re: [HiveMind] 1.0 Beta]

On Tue, 4 Nov 2003, Robert Leland wrote:

 You've acknowledged that when you commit any code to Apache you give up
 ownership of that code.

That's not quite right.  When you commit any code to Apache (under the
Contributors License Agreement), you grant the ASF a non-exclusive right
to that code.  You retain your rights on your contributions, you're just
sharing some rights with the ASF as well.

 Also what is said on the Web site is governed by the same Apache
 license. In order to endorse
 any product or company on an Apache web site there needs to be written
 permission
 from the Apache Foundation. The fact that no other company is officially
 endorsed
 (Maven has some hidden acknowledgments in it's plug-in docs) says you
 are asking for a
  new precedent to be set. While you certainly could make suggestions in
 the negotiating terms,
  if that is what the Apache Foundation member, wants to do, is not your
 responsibility.
 It is your responsibility to bring this matter to the Apache Foundation
 as a good steward.

It's not clear to me exactly what Howard and or WebCT is asking for.

 Also plain committers like us are not Apache Foundation members.

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

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

RE: Company Acknowledgements [was :Re: [HiveMind] 1.0 Beta]

2003-11-05 Thread Noel J. Bergman

 Did I have the right to do [develop HiveMind on WebCT's time]?
 At the time, I was 100% certain I did ...

No one is suggesting that you didn't act in good faith, Howard.  What is
making a mountain out of a molehill is your apparent unwillingness to
involve the proper channels in the process.  A simple note from you that you
are discussing the situation with the Jakarta PMC and/or ASF Board would
curtail the dicussion here.

 WebCT and I disagree on this issue and it is, to my mind, debatable
 (everything in HiveMind can be traced back to specific ideas already
 present in Tapestry even before my joining WebCT).

They paid for your time to develop at least some of the code.  The ideas may
not be theirs, but the copyright is another matter.  Fortunately, as you
say, they appear inclined to settle any question by assigning the copyright
to the ASF.

 Fortunately, nobody wants to debate it. Everyone involved wants the
 code to stay at the ASF, with an ASF copyright, under the ASL.

If they are willing to do that, great.  But if they want something in
return, you are not able to legally represent the ASF, so you've be asked to
involve those who can for guidance about what is acceptable.

 So, what would you propose? Strip HiveMind out of the sandbox CVS?
 Track down any backup mirrors and erase them?  Kidnap its users
 and brain wash them?

No.  Once again, this situation will hopefully resolve itself
satisfactorily.  But you still have an obligation under the CLA, and you
still are not a legal ASF representative.  When it comes down to it,
whatever you agree with WebCT will still need to be accepted by the
Foundation.

The only thing that had been requested was that you inform the Foundation of
the situation, as per paragraph 4 of the CLA:

  You agree to notify the Foundation of any facts or
   circumstances of which you become aware that would
   make Your representations in this Agreement
   inaccurate in any respect.

In this case, WebCT called paragraph 3 into question, although they are
willing to negotiate to resolve the problem.

--- Noel


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

Re: [Math] Commons Math Contributions

Mike and Matt,

To try to answer your questions as best as possible. First and foremost, 
become familiar with the goals and guiding principles we initially set 
out to maintain the math project here.

http://jakarta.apache.org/commons/math/proposal.html
http://jakarta.apache.org/commons/math/developers.html
http://jakarta.apache.org/commons/math/tasks.html
Mainguy, Mike wrote:
I'm in the same boat, a good answer would be appreciated (I've gotten a wide
variety).
Another thing I'm wondering is should we add ourselves as an author when we
submit a patch or is that just if you're a commiter?
Yes, you may provide a patch to project.xml with yourself as a 
contributor when you make a submission via the bug track. However, to 
avoid bloat of the contributors list, I'd recommend only doing it if you 
strongly feel you need this acknowledgment.


worse is better 

-Original Message-
From: Matt Cliff [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 05, 2003 11:46 AM
To: [EMAIL PROTECTED]
Subject: [Math] Commons Math Contributions


 I recently download the math commons subproject and would like to 
help out.

 This is my first open source contribution effort and am looking forward
to extending to other projects.   I have a background in Mathematics (MS
and thesis work in Stochastic Analysis) and for the past several years 
worked as a project lead for a Java Company.

 Basically,
  (1) What is the best way to contribute?   (submit patches to this
mailing list or through the bug tracking system?)   Also,  will the bug
tracking a new Math component to the Commons project?
Please use bugzilla to provide your patches for the math project

http://nagoya.apache.org/bugzilla/

This is going to change slightly in the future as Math will become a 
full fledged component in commons as opposed to the current posting to 
the sandbox. I think I will put together a xdoc that covers all this 
detail further.

If this is all too confusing initially, please just post it to the list 
until the changes in bugzilla occur and I publish this document.


  (2) What should I be working on?  (what do we need to do to get it to a
1.0 release?)   
I think that our effort for 1.0 is fairly complete. Now we are just 
trying to figure out the release process, stabilize the move out off the 
sandbox etc.

I would be more comfortable doing some 'maintenance' type
work intially,  downstream I can offer more substantitve math  (I had 
done a bunch of work with DASSL and DASPK and their applications to 
Stochastic differential equations).

This is great, I think we need to explore more concerning DiffEq and 
Stochastic processes. I think first we need to stabilize 1.0 get it out 
and move forward with new additions and designs. Hang out on the list, 
postulate ideas, your niche will become clearer over time.

  (3) Will there be a link on the 
http://jakarta.apache.org/commons/index.html page to the Math Compont
page?

There will be a link to the Math project on the commons front page, we 
are trying to catchup and get everything ironed out with this. (I just 
moved the cvs tree out of the sandbox last weekend.

  (4) I added a quick type-o patch for the tasks.xml doc to see if it 
is the proper format.  (this is a cvs diff output)

Matt, thanks for the patch I'll apply it.


 The label said install Windows 98 or better so I installed 
Linux.

:-) snicker

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

[commons] Bugzilla and components

How do we go about the process of getting math added to the commons 
components list in bugzilla?

-Mark

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

Commons Math Contributions

2003-11-05 Thread Matt Cliff

  I recently download the math commons subproject and would like to help 
out.

  This is my first open source contribution effort and am looking forward 
to extending to other projects.   I have a background in Mathematics (MS 
and thesis work in Stochastic Analysis) and for the past several years 
worked as a project lead for a Java Company.


  Basically, 
   (1) What is the best way to contribute?   (submit patches to this 
mailing list or through the bug tracking system?)   Also,  will the bug 
tracking a new Math component to the Commons project?

   (2) What should I be working on?  (what do we need to do to get it to a 
1.0 release?)   I would be more comfortable doing some 'maintenance' type 
work intially,  downstream I can offer more substantitve math  (I had done 
a bunch of work with DASSL and DASPK and their applications to Stochastic 
differential equations).

   (3) Will there be a link on the 
http://jakarta.apache.org/commons/index.html page to the Math Compont page?

   (4) I added a quick type-o patch for the tasks.xml doc to see if it is 
the proper format.  (this is a cvs diff output)


  looking forward to helping out.

-- 
  Matt Cliff
  Cliff Consulting
  303.757.4912
  720.280.6324 (c)


  The label said install Windows 98 or better so I installed Linux.
Index: xdocs/tasks.xml
===
RCS file: /home/cvspublic/jakarta-commons/math/xdocs/tasks.xml,v
retrieving revision 1.2
diff -u -r1.2 tasks.xml
--- xdocs/tasks.xml 1 Nov 2003 16:35:03 -   1.2
+++ xdocs/tasks.xml 5 Nov 2003 14:59:26 -
@@ -21,7 +21,7 @@
   ddClover tests show gaps in test path coverage. Get all tests to 100% 
coverage.  Also improve test data and boundary conditions coverage./dd
   dtCode review./dt
   dd
-pCode review is a continuous rpocess that all Contributors and 
Developers should practice while working on the code base./p
+pCode review is a continuous process that all Contributors and 
Developers should practice while working on the code base./p
 ul
   liJavadoc generation is still throwing warnings.  Bring the Javadoc 
into compliance (i.e. reach zero warnings)./li
   liVerify that the code matches the documentation and identify obvious 
inefficiencies or numerical problems.  All feedback/suggestions for 
improvement/patches are welcome./li
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [Math] common-math and bloated 3rd party libraries

2003-11-05 Thread Todd V. Jonker


On Wed, 5 Nov 2003 06:54:14 -0800 (PST), David Graham
[EMAIL PROTECTED] said:
 Agreed, especially because Jakarta's mission is to create *server* 
 side libraries.
[...]
 The need to support 1.3 is diminishing over time.  Java 1.4 is
 available and runs well on all the major platforms I can think of.

While I tend to be in the go with 1.4 camp, this is MUCH easier tent to
pitch in NON-server environments.  Commercial J2EE containers tend to be
dinosaurs with respect to JDK versions, and commercial users of said
containers tend to be dinosaurs too.  So I typically see sites that are a
couple versions behind in upgrading their container, so their developers
are stuck back in 1.3-land.

I also want to gripe mildly about the server-side mission, since it feels
myopic to me.  The lines between client and server blur more every day. 
With JNLP it is easy and beneficial to shove increasing functionality to
the client side, which means downloading jars to the desktop.

Cheers,
.T.

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

[Math] Commons Math Contributions

2003-11-05 Thread Matt Cliff

  I recently download the math commons subproject and would like to help 
out.

  This is my first open source contribution effort and am looking forward 
to extending to other projects.   I have a background in Mathematics (MS 
and thesis work in Stochastic Analysis) and for the past several years 
worked as a project lead for a Java Company.


  Basically, 
   (1) What is the best way to contribute?   (submit patches to this 
mailing list or through the bug tracking system?)   Also,  will the bug 
tracking a new Math component to the Commons project?

   (2) What should I be working on?  (what do we need to do to get it to a 
1.0 release?)   I would be more comfortable doing some 'maintenance' type 
work intially,  downstream I can offer more substantitve math  (I had done 
a bunch of work with DASSL and DASPK and their applications to Stochastic 
differential equations).

   (3) Will there be a link on the 
http://jakarta.apache.org/commons/index.html page to the Math Compont page?

   (4) I added a quick type-o patch for the tasks.xml doc to see if it is 
the proper format.  (this is a cvs diff output)


  looking forward to helping out.

-- 
  Matt Cliff
  Cliff Consulting
  303.757.4912
  720.280.6324 (c)


  The label said install Windows 98 or better so I installed Linux.
Index: xdocs/tasks.xml
===
RCS file: /home/cvspublic/jakarta-commons/math/xdocs/tasks.xml,v
retrieving revision 1.2
diff -u -r1.2 tasks.xml
--- xdocs/tasks.xml 1 Nov 2003 16:35:03 -   1.2
+++ xdocs/tasks.xml 5 Nov 2003 14:59:26 -
@@ -21,7 +21,7 @@
   ddClover tests show gaps in test path coverage. Get all tests to 100% 
coverage.  Also improve test data and boundary conditions coverage./dd
   dtCode review./dt
   dd
-pCode review is a continuous rpocess that all Contributors and 
Developers should practice while working on the code base./p
+pCode review is a continuous process that all Contributors and 
Developers should practice while working on the code base./p
 ul
   liJavadoc generation is still throwing warnings.  Bring the Javadoc 
into compliance (i.e. reach zero warnings)./li
   liVerify that the code matches the documentation and identify obvious 
inefficiencies or numerical problems.  All feedback/suggestions for 
improvement/patches are welcome./li
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [commons] Bugzilla and components

2003-11-05 Thread Stefan Bodewig

On Wed, 05 Nov 2003, Mark R. Diggory [EMAIL PROTECTED]
wrote:

 How do we go about the process of getting math added to the commons
 components list in bugzilla?

Done.

In general there are a bunch of people on this list who have karma to
do so, so just ask - but don't do so burried deep in a discussion
thread, please 8-)

Stefan

-- 
http://stefanbodewig.blogger.de/

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

[results][math] Votes for J. Pietchmann to get karma for math project

J. Pietchmann (for karmic rights in math project)
+1 = 6
+0 = 0
-0 = 0
-1 = 0
Pietchmann, you need to complete this and send it back to the pmc.

Karma request form:

To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: CVS karma request
userid:   ...

Requested karma:  project[/subproject] ...
Reason:   [a few lines explaining why someone needs karma]
[Vote: link to mail archive for PMC bookkeeping]

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

[results][math] Votes for Brent Warden and Al Chou as commiters

Brent Warden (for new committer)
+1 = 6
+0 = 0
-0 = 0
-1 = 0
Al Chou (for new committer)
+1 = 6
+0 = 0
-0 = 0
-1 = 0
I'm still not fully versed on the process of setting up the accounts 
etc. I remember that I had to complete some info concerning my account 
name and personal info. Al and Brent you need to complete the following 
form and send it to [EMAIL PROTECTED]

To: [EMAIL PROTECTED]
Subject: Apache account request
Full name:...
Preferred userid: ... [please provide acceptable alternates!]
Forwarding email address: ...
Requested karma:  project[/subproject] ...

[Vote: link to mail archive for PMC bookkeeping]

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

Re: [commons] Bugzilla and components

Thanks :-)

Stefan Bodewig wrote:

On Wed, 05 Nov 2003, Mark R. Diggory [EMAIL PROTECTED]
wrote:

How do we go about the process of getting math added to the commons
components list in bugzilla?


Done.

In general there are a bunch of people on this list who have karma to
do so, so just ask - but don't do so burried deep in a discussion
thread, please 8-)
Stefan

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

Re: [collections] [PATCH] CompositeCollection class for Commons-Collections

2003-11-05 Thread Phil Steitz

Brian McCallister wrote:
On Wednesday, November 5, 2003, at 12:10 AM, Phil Steitz wrote:

I think that that javadoc for remove is incorrect when it says:
This implementation calls coderemove()/code on each collection. 
It stops when it finds the element to be removed.  The contract needs 
to be made more explicit here.  It might actually be better to push 
remove() into the Mutator, since one could argue that the current 
remove strategy (kill the first one found) is no less arbitrary than 
a default add strategy that just adds to the last collection.  Might 
be better to make this pluggable like add.


To quote the Collection API doc:
quote
Removes a single instance of the specified element from this  
collection, if it is present (optional operation).  More formally,  
removes an element e such that (o==null ?  e==null :  o.equals(e)), if 
this collection contains one or more such  elements.
/quote

I agree that this could be pluggable, but I think that providing a 
remove first found as a default is very reasonable in this case as it 
fits the idiomatic behavior people expect from extent collections.
Note the similarity to the API doc for add:
Ensures that this collection contains the specified element (optional 
operation). Returns true if this collection changed as a result of the 
call. (Returns false if this collection does not permit duplicates and 
already contains the specified element.)

My point is that kill first in a composite collection is no more 
natural than add last.  I would be OK with both being defaulted but 
modifiable via Mutator.  Since the collection could mean either the 
aggregate or *each* of the summands in each case, I see both add and 
remove as ambiguous (hence the need for strategies).  This is a small point.

+0 (non-binding) for putting this into the CollectionMutator but 
providing present behavior as default if no mutator set (rather than an 
exception as add/addAll do. This is internally inconsistent though so I 
would welcome better ideas.

The containsAll javadoc says This is O(n^2) at the moment, be careful 
using it..


It is not correct anymore. It was in the original version but the 
implementation has changed significantly already =)

I am curious about how much faster this can be done without an ordering.


Dropping ordering on what?
What I meant was that without assuming an ordering on the aggregate (so 
binary search would be possible), is there a faster way to do the *all 
methods. I assume that if there is a clever way to do this, that is what 
the JDK methods do.


The last comment suggests another possibly useful method:
toList(), returning an aggregated collection consisting of all of the 
objects in the composite collections.


That works for me, though I would make it a Collection and return the 
actual type of whichever subclass. I suspect Stephen will suggest that 
it be toCollection(), toList(), and toSet() respectively in order to 
allow greater specificity of the return type, which I am also okay with.
What do you mean by whichever subclass?  The aggregated collections 
could be of multiple different types. That makes an interesting problem. 
 I suppose that toCollection() could return an instance of the one 
common type if the summands are homogeneous (all the same type), 
otherwise default to a (Array?)List or (Hash?)Set.  I agree that toSet() 
would also be natural. Need to think about these things some more.  It 
might be better to just have the API take the aggregation target as an 
actual parameter -- i.e. toCollection(collection), effectively punting 
the issue of return types.

Anyone have any objections to committing this to the decorators subpackage?

Phil

Hmm, would be nice if Java let you override a method to return a 
subclass of the return type of the method being overridden. It would 
satisfy the static typing still.

-Brian

PS: I have attached changes discussed




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

Re: [functor] possible contributions

2003-11-05 Thread Herve Quiroz

On Tue, Nov 04, 2003 at 09:06:37AM -0800, Rodney Waldhoff wrote:
  There are some others but I need to classify them and decide which ones
  are generic enough to be part of commons-functor...
 
  Obviously, I will provide everything with complete Javadoc support and
  test cases whenever it is relevant.
 
 
 Great.  Feel free to submit patches to the dev list.

I have already refactored DoWhileProcedure and WhileDoProcedure. The
problem I have now is for unit tests. I plan to test it using a loop
that increments a counter (probably an Integer). So I could assert
values and predicates reagarding the counter at beginning and at the end
of the loop.

To do this, I need a procedure such as IntegerIncrementProcedure that
increments an internal counter at run(). So I ask you: should I code
this class as a internal class restricted to testing purposes or should
I provide this class as a public one to the commons-functor package ? In
the later case, where should I put it (in which package) ? maybe
org.apache.commons.functor.core.number ? But this could instead be the
scope of a commons-math subpackage...

What do you think of it ?

Herve

PS: While reading my mail looking for typos, I realized that such a
procedure would not be quite useful (IntegerIncrementProcedure).
Instead, what about some IntegerIncrementUnaryProcedure that increments
the parameter o at run(Object o) ? The former Procedure could then be
built using a BoundProcedure...

PPS: Maybe things are going to be a litlle more complex than I thought
with this math/functor issue... I should probably code what I need as an
internal class (or an example at least) for now before you decide what
to do with this math/functor stuff.

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

Re: [functor] possible contributions

I would just do it as an internal class for the time being.

On Wed, 5 Nov 2003, Herve Quiroz wrote:

 On Tue, Nov 04, 2003 at 09:06:37AM -0800, Rodney Waldhoff wrote:
   There are some others but I need to classify them and decide which ones
   are generic enough to be part of commons-functor...
  
   Obviously, I will provide everything with complete Javadoc support and
   test cases whenever it is relevant.
  
 
  Great.  Feel free to submit patches to the dev list.

 I have already refactored DoWhileProcedure and WhileDoProcedure. The
 problem I have now is for unit tests. I plan to test it using a loop
 that increments a counter (probably an Integer). So I could assert
 values and predicates reagarding the counter at beginning and at the end
 of the loop.

 To do this, I need a procedure such as IntegerIncrementProcedure that
 increments an internal counter at run(). So I ask you: should I code
 this class as a internal class restricted to testing purposes or should
 I provide this class as a public one to the commons-functor package ? In
 the later case, where should I put it (in which package) ? maybe
 org.apache.commons.functor.core.number ? But this could instead be the
 scope of a commons-math subpackage...

 What do you think of it ?

 Herve

 PS: While reading my mail looking for typos, I realized that such a
 procedure would not be quite useful (IntegerIncrementProcedure).
 Instead, what about some IntegerIncrementUnaryProcedure that increments
 the parameter o at run(Object o) ? The former Procedure could then be
 built using a BoundProcedure...

 PPS: Maybe things are going to be a litlle more complex than I thought
 with this math/functor issue... I should probably code what I need as an
 internal class (or an example at least) for now before you decide what
 to do with this math/functor stuff.

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



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

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

Re: [collections] [PATCH] CompositeCollection class for Commons-Collections

On Wednesday, November 5, 2003, at 11:31 AM, Phil Steitz wrote:
Note the similarity to the API doc for add:
Ensures that this collection contains the specified element (optional 
operation). Returns true if this collection changed as a result of the 
call. (Returns false if this collection does not permit duplicates and 
already contains the specified element.)

My point is that kill first in a composite collection is no more 
natural than add last.  I would be OK with both being defaulted 
but modifiable via Mutator.  Since the collection could mean either 
the aggregate or *each* of the summands in each case, I see both add 
and remove as ambiguous (hence the need for strategies).  This is a 
small point.

Point made.

What I meant was that without assuming an ordering on the aggregate 
(so binary search would be possible), is there a faster way to do the 
*all methods. I assume that if there is a clever way to do this, 
that is what the JDK methods do.
Thinking about it. Without

What do you mean by whichever subclass?  The aggregated collections 
could be of multiple different types. That makes an interesting 
problem.  I suppose that toCollection() could return an instance of 
the one common type if the summands are homogeneous (all the same 
type), otherwise default to a (Array?)List or (Hash?)Set.  I agree 
that toSet() would also be natural. Need to think about these things 
some more.  It might be better to just have the API take the 
aggregation target as an actual parameter -- i.e. 
toCollection(collection), effectively punting the issue of return 
types.

CompositeCollection returns a Collection
CompositeList returns a List (it requires summands (good word) to be 
List)
CompositeSet returns a Set (it requires summands to be Set)

Anyone have any objections to committing this to the decorators 
subpackage?

If so, I have attached a version which puts remove() into 
CollectionMutator

/*
 * $Header: 
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/Closure.java,v
 1.7 2003/08/31 17:26:44 scolebourne Exp $
 * 
 *
 * 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 The Jakarta Project, Commons, and Apache Software
 *Foundation must not be used to endorse or promote products derived
 *from this software without prior written permission. For written
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called Apache
 *nor may Apache appear in their names without prior written
 *permission of the Apache 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.collections;

import java.lang.reflect.Array;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collection;
import java.util.Collections;
import java.util.Iterator;

import

RE: [Math] common-math and bloated 3rd party libraries

2003-11-05 Thread Danny Angus






FWIW the math proposal actually says:


  Emphasis on small, easily integrated components rather than large
 libraries with complex dependencies   



;-)


As far as Todds comments go:

 While I tend to be in the go with 1.4 ...

I'm firmly in the stick with 1.3 camp.
Until there is either progress which is *really* blocked by lack of access
to 1.4+
and or the demand for 1.3 compatibility is insignificant I don't think it
is wise for any Jakarta sub-project, or part of commons, to ignore the fact
that the Jakarta mission to produce server software, and many many people
are stuck with 1.3 until they can justify significant investment involved
in upgrading to newer container version. Don't forget that the cost of
change isn't all in the software there's a big old load of testing to do as
well.


 I also want to gripe mildly about the server-side mission, since it feels
 myopic to me.  The lines between client and server blur more every day.
 With JNLP it is easy and beneficial to shove increasing functionality to
 the client side, which means downloading jars to the desktop.

But the lines are blurred and blurring @jakarta as well, there's plenty of
software here which is as applicable in clients as it is in servers, but to
extend the scope of the project to anything java at all would be silly,
theres already enough going on as it is. If you want to develop desktop
software @apache, make a proposal to the incubator.

d.



***
The information in this e-mail is confidential and for use by the addressee(s) only. 
If you are not the intended recipient (or responsible for delivery of the message to 
the intended recipient) please notify us immediately on 0141 306 2050 and delete the 
message from your computer. You may not copy or forward it or use or disclose its 
contents to any other person. As Internet communications are capable of data 
corruption Student Loans Company Limited does not accept any  responsibility for 
changes made to this message after it was sent. For this reason it may be 
inappropriate to rely on advice or opinions contained in an e-mail without obtaining 
written confirmation of it. Neither Student Loans Company Limited or the sender 
accepts any liability or responsibility for viruses as it is your responsibility to 
scan attachments (if any). Opinions and views expressed in this e-mail are those of 
the sender and may not reflect the opinions and views of The Student Loans Company 
Limited.

This footnote also confirms that this email message has been swept for the presence of 
computer viruses.

**


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

RE: [collections] [PATCH] CompositeCollection class for Commons-Collections

2003-11-05 Thread Arun Thomas

 The last comment suggests another possibly useful method: toList(), 
 returning an aggregated collection consisting of all of the objects 
 in the composite collections.

In this case, will there be a clever way to return an aggregation of this sort that 
isn't simply a new object with copies of all elements of the contained objects?  If 
that's the case, then is seems more reasonable to leave the creation of this type of 
object to the user - create a new object passing in the composite collection in the 
constructor, or use addAll(Collection c).   

If there's a clever way to handle provide the implementation of List/Set/Collection 
using the contained collections as a base, that might be interesting, but 
otherwise  

Cheers, 
-AMT 

-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 05, 2003 8:31 AM
To: Jakarta Commons Developers List
Subject: Re: [collections] [PATCH] CompositeCollection class for Commons-Collections


Brian McCallister wrote:
 
 On Wednesday, November 5, 2003, at 12:10 AM, Phil Steitz wrote:
 
 I think that that javadoc for remove is incorrect when it says: This 
 implementation calls coderemove()/code on each collection. It 
 stops when it finds the element to be removed.  The contract needs to 
 be made more explicit here.  It might actually be better to push
 remove() into the Mutator, since one could argue that the current
 remove strategy (kill the first one found) is no less arbitrary than 
 a default add strategy that just adds to the last collection.  Might 
 be better to make this pluggable like add.
 
 
 To quote the Collection API doc:
 quote
 Removes a single instance of the specified element from this
 collection, if it is present (optional operation).  More formally,  
 removes an element e such that (o==null ?  e==null :  o.equals(e)), if 
 this collection contains one or more such  elements.
 /quote
 
 I agree that this could be pluggable, but I think that providing a
 remove first found as a default is very reasonable in this case as it 
 fits the idiomatic behavior people expect from extent collections.

Note the similarity to the API doc for add:
Ensures that this collection contains the specified element (optional 
operation). Returns true if this collection changed as a result of the 
call. (Returns false if this collection does not permit duplicates and 
already contains the specified element.)

My point is that kill first in a composite collection is no more 
natural than add last.  I would be OK with both being defaulted but 
modifiable via Mutator.  Since the collection could mean either the 
aggregate or *each* of the summands in each case, I see both add and 
remove as ambiguous (hence the need for strategies).  This is a small point.

 
 +0 (non-binding) for putting this into the CollectionMutator but
 providing present behavior as default if no mutator set (rather than 
 an
 exception as add/addAll do. This is internally inconsistent though so I 
 would welcome better ideas.
 

 The containsAll javadoc says This is O(n^2) at the moment, be 
 careful
 using it..
 
 
 It is not correct anymore. It was in the original version but the
 implementation has changed significantly already =)
 
 I am curious about how much faster this can be done without an 
 ordering.
 
 
 Dropping ordering on what?

What I meant was that without assuming an ordering on the aggregate (so 
binary search would be possible), is there a faster way to do the *all 
methods. I assume that if there is a clever way to do this, that is what 
the JDK methods do.

 
 The last comment suggests another possibly useful method: toList(), 
 returning an aggregated collection consisting of all of the objects 
 in the composite collections.
 
 
 That works for me, though I would make it a Collection and return the
 actual type of whichever subclass. I suspect Stephen will suggest that 
 it be toCollection(), toList(), and toSet() respectively in order to 
 allow greater specificity of the return type, which I am also okay with.

What do you mean by whichever subclass?  The aggregated collections 
could be of multiple different types. That makes an interesting problem. 
  I suppose that toCollection() could return an instance of the one 
common type if the summands are homogeneous (all the same type), 
otherwise default to a (Array?)List or (Hash?)Set.  I agree that toSet() 
would also be natural. Need to think about these things some more.  It 
might be better to just have the API take the aggregation target as an 
actual parameter -- i.e. toCollection(collection), effectively punting 
the issue of return types.

Anyone have any objections to committing this to the decorators subpackage?

Phil

 
 Hmm, would be nice if Java let you override a method to return a
 subclass of the return type of the method being overridden. It would 
 satisfy the static typing still.
 
 -Brian
 
 PS: I have attached changes discussed

Adding DbUtils to Bugzilla

Can some karma gifted person add DbUtils to the Commons 

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

Re: Adding DbUtils to Bugzilla


--- David Graham [EMAIL PROTECTED] wrote:
 Can some karma gifted person add DbUtils to the Commons.

Weird, Yahoo truncated my message.  DbUtils is already in the Commons.  We
just need it added to bugzilla.

David

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

Dealing with unreleased pool objects

2003-11-05 Thread Charles Hudak

I've been reviewing the source code as I've been contemplating having my
existing pool implementations delegate to the commons pool implementations.

One issue that I have, however, is that the current pool implementations do
not appear to deal with 'abandoned' pool objects. We all agree that clients
of the pools should always release objects that they have acquired from the
pool but my experience shows that the mistake of not doing this is all too
common. Whether blatently forgetting to release the objects or not properly
using a try/finally construct to make sure that objects are released even if
an exception is thrown, I have found this problem throughout our
application.

This is particularly troublesome when using DB pools in an application
container like Weblogic. The older version of WL that we are running (5.1)
does not deal with abandoned connection objects. They are never reclaimed by
the pool so in the case of this common programming bug, the pool either
grows unchecked or grows to its limit and then starts throwing exceptions
because no more connections are available.

It looks like the GenericObjectPool imlementation doesn't actually store
references to the 'used' objects which would theoretically deal with
abandoned objects. Unfortunately, it keeps a count of the number of objects
that are 'active' so if an object is abandoned, the active count will
continue to grow, which would cause problems if you put a cap on the number
of active objects.

I would suggest holding the 'active' objects in an 'active' list and having
the cleaner thread evict abandoned objects in this list if they are past
some expiration time. This is what I have done in my own pool
implementations and I find that it eliminates alot of hard to find bugs,
although it doesn't fix the poor client code that caused the problem.

Does anyone else see a need for this kind of behavior? I'm pretty sure that
the newer implementations of the tomcat DB pooling have this feature and
they will even provide back traces in the log to track which client code is
misbehaving.

Thanks

Charles Hudak
Software Engineering Manager
Arrowhead General Insurance/YouZoom, Inc.


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

Re: [primitives] Proposed interface changes

Some comments inline.  I'll use the voting syntax, in an effort to be
concise, not formal.

On Sat, 18 Oct 2003, Stephen Colebourne wrote:

 I would like to propose the following changes for the primitives code as we
 establish it:

 New interface Collectable (better names?). Superinterface of XxxCollection
 and XxxMap
 - size()
 - clear()
 - isEmpty()
 There are so many times that I've needed a shared interface between
 Collection and Map

+0, I've never had that need, but it sounds reasonable to me.

 - clone()
 Fix a JDK error

I'm +1 to making the implementations cloneable, -1 to requiring this at the
interface level (e.g., I'm opposed to IntCollection extends Cloneable).
Among other problems, this will be difficult to enforce at the adapter
level.

 - isModifiable()
 This would be nice to know

I'm +0 to a Modifiable interface, but -1 to an isModifiable method.  It
would be impossible to reliably implement isModifiable at the adapter
level.

Also, I'm not sure that Modifiable is the proper resolution.  Some types
may allow set or remove but not add, etc. (SingletonIterator is one
such example in the object case).  Is such a collection modifiable?

 - optimize()
 For example, implemented as a trimToSize

+1

 New interface PCollection (or PrimitiveCollection):
 - toCollection()
 It should be really easy to get a JDK collection from a [primitives] one.

TypeCollectionCollection.wrap(mytypecollection) does this already.
I'd be OK with adding a convenience method somewhere, though I'm not sure
PrimitiveCollection is the right place for it.  (Perhaps
PrimitiveCollections.toCollection(TypeCollection): Collection?)

 New methods on IntCollection (et al):
 - addAll(int[])
 - removeAll(int[])
 - containsAll(int[])
 Primitive handling is often done with arrays at present, so provide good
 integration

-0, I'd prefer simply providing an array-to-primitive collection
(or list) adapter, which would then support all these methods and more.

 - toArray(int[], int)
 Offers a way to get the primitives into a specific index in an existing
 array.

This is functionally similar to addAll(int,IntCollection)?  Then as
above, I'd prefer the wrapper approach, or at least the signature
addAll(int,int[])

 New interface PList (or PrimitiveList):
 - toList()
 It should be really easy to get a JDK collection from a [primitives] one.

As above (for PCollection.toCollection).

 - removeRange(int, int)
 Although possible via subList(), this is quicker and more obvious

-0, I'm not sure that's quicker, and the sublist as range operation
stuff is pretty well established, but we could do worse.

 New methods on IntList (et al):
 - first()
 - last()
 Because list.get(list.size() - 1) is a pain

+1

 - indexOf(int, int)
 - lastIndexOf(int, int)
 Completes the set of index methods as per String

+1 As long as a reasonable implementation can be made within the adapters.

 - addAll(int, int[])
 Primitive handling is often done with arrays at present, so provide good
 integration

I'm not sure I understand the relationship between this and
toArray(int[],int) as above.  Do you mean for toArray(int[],int) to return
a new array with the elements of the collection inserted?  That sounds
useful I guess, but I'd stick it in some convenience method and not the
core interface.  Again I think an adapter between a primitive array and a
primitive collection might be most helpful here.


 IMO, these represent a balanced extension to the JDK collection design to
 fit well in the primitives problem space. Opinions welcome.

 Stephen



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

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

RE: Dealing with unreleased pool objects

2003-11-05 Thread Shapira, Yoav


Howdy,
Tomcat 4.x uses DBCP 2.0 and that version of DBCP supports reaping and
logging of abandoned connections.  DBCP 2.1 marks all these methods as
deprecated for reasons that are unknown to me, but I bet you could find
out by searching this list's archives.  Hopefully DBCP 2.2 and later
will provide alternative implementations of the abandoned connection
functionality, as I agree these are useful.

Yoav Shapira
Millennium ChemInformatics


-Original Message-
From: Charles Hudak [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 05, 2003 1:55 PM
To: '[EMAIL PROTECTED]'
Subject: Dealing with unreleased pool objects

I've been reviewing the source code as I've been contemplating having
my
existing pool implementations delegate to the commons pool
implementations.

One issue that I have, however, is that the current pool
implementations do
not appear to deal with 'abandoned' pool objects. We all agree that
clients
of the pools should always release objects that they have acquired from
the
pool but my experience shows that the mistake of not doing this is all
too
common. Whether blatently forgetting to release the objects or not
properly
using a try/finally construct to make sure that objects are released
even
if
an exception is thrown, I have found this problem throughout our
application.

This is particularly troublesome when using DB pools in an application
container like Weblogic. The older version of WL that we are running
(5.1)
does not deal with abandoned connection objects. They are never
reclaimed
by
the pool so in the case of this common programming bug, the pool either
grows unchecked or grows to its limit and then starts throwing
exceptions
because no more connections are available.

It looks like the GenericObjectPool imlementation doesn't actually
store
references to the 'used' objects which would theoretically deal with
abandoned objects. Unfortunately, it keeps a count of the number of
objects
that are 'active' so if an object is abandoned, the active count will
continue to grow, which would cause problems if you put a cap on the
number
of active objects.

I would suggest holding the 'active' objects in an 'active' list and
having
the cleaner thread evict abandoned objects in this list if they are
past
some expiration time. This is what I have done in my own pool
implementations and I find that it eliminates alot of hard to find
bugs,
although it doesn't fix the poor client code that caused the problem.

Does anyone else see a need for this kind of behavior? I'm pretty sure
that
the newer implementations of the tomcat DB pooling have this feature
and
they will even provide back traces in the log to track which client
code is
misbehaving.

Thanks

Charles Hudak
Software Engineering Manager
Arrowhead General Insurance/YouZoom, Inc.


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




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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

Re: [configuration] thread-safe?

2003-11-05 Thread Oliver Heger

Eric,

I haven't thought about the details of accessing properties in a 
singleton yet.

In the first line I was interested in the advantages such an approach 
would have for initialization of the configuration framework. On its 
creation the singleton instance could locate the configuration 
description file by some criteria (to be defined, e.g. by the searching 
the class path), set up a ConfigurationFactory and then load all 
specified configuration sources. This would be a great help for developers.

I had a look at the code you pointed out, but because I don't know 
anything about Avalon and Turbine I don't fully understand what's going 
on there. But I think the configure() method of 
DefaultConfigurationService performs some tasks that would have to be 
done by our singleton, too. Am I right?

To come back to thread safety once more: In my opionion it is important 
that the configuration classes guarantee to be thread-safe in read only 
accesses. Well, I am quite sure that this is already the case, but it 
would be certainly a good idea to make a corresponding note somewhere in 
the documentation.

Oli

Eric Pugh wrote:

Good reply Oliver.  Are you thinking of some sort of SingletonConfiguration
object that just has a single static Configuration object..  So, whether you
call it as SingletonCongifuration.getString(test.value) or create an
object singletonConfiguration.getString() you get the same thing?
Something to look at is an Avalon wrapper I tossed out in Fulcrum[1].  This
provides a singleton in terms of the Container being responsible for
returning just one instance of the object, verus loading multiple.  It seems
to me that as long as we are talking readonly, then it doesn't matter how
many threads read, correct?  And, if you want to write, just toss a
sychronize keyword?
Eric

[1]
http://jakarta.apache.org/turbine/fulcrum/fulcrum-configuration/index.html
 



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

Re: Dealing with unreleased pool objects

2003-11-05 Thread Dirk Verbeeck

Tomcat uses BasicDataSource in the DBCP component
(http://jakarta.apache.org/commons/dbcp/) as its default datasource implementation.
Like you said it has support for abandoned connections.
See
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/AbandonedObjectPool.java?rev=HEAD
for the abandoned pool implementation. (extending the GenericObjectPool)

For now it's in the DBCP package but we can always make it more generic and move
it to the Pool package (that is one of the reasons why it is already
deprecated)

Improvements are always welcome ;-)

Regards
Dirk
Charles Hudak wrote:

I've been reviewing the source code as I've been contemplating having my
existing pool implementations delegate to the commons pool implementations.
One issue that I have, however, is that the current pool implementations do
not appear to deal with 'abandoned' pool objects. We all agree that clients
of the pools should always release objects that they have acquired from the
pool but my experience shows that the mistake of not doing this is all too
common. Whether blatently forgetting to release the objects or not properly
using a try/finally construct to make sure that objects are released even if
an exception is thrown, I have found this problem throughout our
application.
This is particularly troublesome when using DB pools in an application
container like Weblogic. The older version of WL that we are running (5.1)
does not deal with abandoned connection objects. They are never reclaimed by
the pool so in the case of this common programming bug, the pool either
grows unchecked or grows to its limit and then starts throwing exceptions
because no more connections are available.
It looks like the GenericObjectPool imlementation doesn't actually store
references to the 'used' objects which would theoretically deal with
abandoned objects. Unfortunately, it keeps a count of the number of objects
that are 'active' so if an object is abandoned, the active count will
continue to grow, which would cause problems if you put a cap on the number
of active objects.
I would suggest holding the 'active' objects in an 'active' list and having
the cleaner thread evict abandoned objects in this list if they are past
some expiration time. This is what I have done in my own pool
implementations and I find that it eliminates alot of hard to find bugs,
although it doesn't fix the poor client code that caused the problem.
Does anyone else see a need for this kind of behavior? I'm pretty sure that
the newer implementations of the tomcat DB pooling have this feature and
they will even provide back traces in the log to track which client code is
misbehaving.
Thanks

Charles Hudak
Software Engineering Manager
Arrowhead General Insurance/YouZoom, Inc.

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

Re: [Math] common-math and bloated 3rd party libraries

I'm trying organize this thread a little bit more than was accomplished 
in the discussion.

1.) Argument exists concerning the dependency requirements of Commons 
Math. To in fact be modular and easily integrated some discrepancy 
arises concerning interdependency with other commons components. The 
main question is; Are all these dependencies really required?

a.) logging: It sounds like a good idea to make logging a 
runtime/compile time dependency on only the test cases and not the main 
library. Is this logical to everyone? I really like the idea and as 
logging is really used minimally in only about 4 classes, this should 
be easy to work around.

b.) Some discussion arises concerning some of the higher level 
interfaces and their dependencies on commons such as Discovery. We 
should review and grade if this Discovery pattern will really of true 
value in the places we've applied it (As opposed to just providing 
simple method of instantiation on these object directly...)

c.) j2sdk1.3.1 vs. j2sdk1.4.1: we are a project in a group dedicated to 
providing tools that can operate in Java Servlet/EBJ environments. Many 
vendors are still operating on 1.3.1. We have concerns as to our stuff 
working there. Thus we need to make sure we use only mechanisms 
supported on 1.3.1 for the time being (and then operate on a longer 
timescale to determine how facilitate usage of 1.4.1 in the future). I 
think currently the big area is Exception handling capabilities and 
our primary solution was to use o.a.l.e.NestedException.

2.) Server vs Application schools, I tend to think this is a Red 
Herring, this arises primarily by some great comments Eric made

Eric Pugh wrote:
This backlash against multiple commons jars is happening in a lot of places.
However, I think it is a bit shortsighted.  If you are in a non server
environment, I understand the problem, but in a server environment with lots
of harddrive space, I don't.  Additionally, since in a server app you are
likely to need all thoses dependencies any way.  I think almost every app I
work on has commons-lang, commons-loggin, and commons-collections included.
And then depending on what else, commons-discovery and commons-beanutils
show up all the time!
a.) Even in a non-server environment, space isn't an issue, I think the 
real issue your seeing here is usage of arcane methods of setting up 
classpaths being approached by users of java programs as applications. 
All too often you come across the use of external scripting languages to 
manage execution of a java application. In the commons we have several 
efforts to alleviate this matter (CLI, Daemon,  Hivemind). Outside of 
commons theres Classworlds, Ant etc that provide solid means of building 
up classpathing more dynamically. There are smarter ways to buildup your 
classpath and initial environment than a batch script. In which case 
whether a class is in /lib/a.jar or /lib/b.jar become less of an issue.

b.) The places where space becomes an issue are things like Applets. 
(Yikes). And really when it boils down to it, There are enough solid 
tools out there for optimizing applets, you should optimize the hell out 
of whatever your building to produce the lightest applet you possibly 
can at development time, this is very independent of the actually 
packaging of the dependencies  at development time. I don't think it 
something that the math project should limit ourselves by striving to 
provide.

I think thats about it for now.

Cheers,

--
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: [Math] common-math and bloated 3rd party libraries

2003-11-05 Thread Charles Hudak

Mark wrote:
 Eric Pugh wrote:
 This backlash against multiple commons jars is happening in a lot of
places.
 However, I think it is a bit shortsighted.  If you are in a non server
 environment, I understand the problem, but in a server environment with
lots
 of harddrive space, I don't.  Additionally, since in a server app you are
 likely to need all thoses dependencies any way.  I think almost every app
I
 work on has commons-lang, commons-loggin, and commons-collections
included.
 And then depending on what else, commons-discovery and commons-beanutils
 show up all the time!

I think that this comment is a little shortsighted. We are still using
weblogic 5.1 and constantly have problems with the multitude of third party
libraries that we are using. WL 5.1 does not seem to find libraries in the
WEB-INF/lib directory, as it should, so these have to be set using the
classpath. Unfortunately, on Windows NT, the commandline has a size
limitation. Every so often, after adding another library, we are unable to
start the server due to a the command is too long error. This is a PITA
and we have been working around it for several years.

Having to add 3 or 4 extra commons jars just because I want to use ONE of
the libraries is lame. I'm all for code reuse but it seems as if the commons
developers have created alot of unnecessary dependancies between the
projects (maybe as a show of solidarity, who knows). This also creates
versioning problems. If I want to update one library, I may have to update
several of it's dependant libraries, ad nauseum. I already deal with this
hassle with the rapidly changing XML libraries and the fact that some idiot
library developers insist on including dated versions of the dom and sax
api's in their jars.
/rant

People need to realize that there are lots of legacy users out there who
aren't limited by only 'harddrive space'.

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

cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestHttpConnection.java

2003-11-05 Thread olegk

olegk   2003/11/05 12:45:34

  Modified:httpclient/src/java/org/apache/commons/httpclient
HttpConnection.java HttpMethodBase.java
   httpclient/src/test/org/apache/commons/httpclient
TestHttpConnection.java
  Log:
  Changelog:
  - Socket input stream now wrapped with a wrapper class that re-throws certain type 
of generic IO exceptions as HttpClient specific exceptions. In particular 
java.io.InterruptedIOExceptions are re-thrown as IOTimeoutException
  - java.io.InterruptedIOExceptions in HttpConnection#open() re-thrown as 
ConnectTimeoutException
  - HttpConnection#write(byte[], int, int) changed to throw IllegalArgumentException 
in case of invalid input. Used to throw HttpRecoverableException.
  - 'Used' connection logic improved.
  
  Contributed by Oleg Kalnichevski
  Reviewed by Michael Becke
  
  Revision  ChangesPath
  1.79  +105 -84   
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java
  
  Index: HttpConnection.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java,v
  retrieving revision 1.78
  retrieving revision 1.79
  diff -u -r1.78 -r1.79
  --- HttpConnection.java   1 Nov 2003 21:17:25 -   1.78
  +++ HttpConnection.java   5 Nov 2003 20:45:34 -   1.79
  @@ -495,7 +495,7 @@
   socket.setSoTimeout(this.params.getSoTimeout());
   }
   }
  -} catch (InterruptedIOException e) {
  +} catch (IOTimeoutException e) {
   // aha - the connection is NOT stale - continue on!
   } catch (IOException e) {
   // oops - the connection is stale, the read or soTimeout failed.
  @@ -659,12 +659,12 @@
   public void open() throws IOException {
   LOG.trace(enter HttpConnection.open());
   
  +final String host = (proxyHostName == null) ? hostName : proxyHostName;
  +final int port = (proxyHostName == null) ? portNumber : proxyPortNumber;
   assertNotOpen();
   try {
   if (null == socket) {
   
  -final String host = (null == proxyHostName) ? hostName : 
proxyHostName;
  -final int port = (null == proxyHostName) ? portNumber : 
proxyPortNumber;
   
   usingSecureSocket = isSecure()  !isProxied();
   
  @@ -718,35 +718,32 @@
   if (rcvBufSize = 0) {
   socket.setReceiveBufferSize(rcvBufSize);
   }
  -inputStream = new PushbackInputStream(socket.getInputStream());
  +inputStream = new PushbackInputStream(
  +new WrappedInputStream(socket.getInputStream()));
   outputStream = new BufferedOutputStream(
   new WrappedOutputStream(socket.getOutputStream()),
   socket.getSendBufferSize()
   );
   isOpen = true;
   used = false;
  +} catch (InterruptedIOException e) {
  +closeSocketAndStreams();
  +throw new ConnectTimeoutException(Open connection interrupted, e);
   } catch (IOException e) {
   // Connection wasn't opened properly
   // so close everything out
   closeSocketAndStreams();
   throw e;
   } catch (TimeoutController.TimeoutException e) {
  -if (LOG.isWarnEnabled()) {
  -StringBuffer buffer = new StringBuffer();
  -buffer.append(The host ); 
  -buffer.append(hostName); 
  -buffer.append(:); 
  -buffer.append(portNumber); 
  -buffer.append( (or proxy ); 
  -buffer.append(proxyHostName); 
  -buffer.append(:); 
  -buffer.append(proxyPortNumber); 
  -buffer.append() did not accept the connection within timeout of 
); 
  -buffer.append(this.params.getConnectionTimeout()); 
  -buffer.append( milliseconds); 
  -LOG.warn(buffer.toString()); 
  -}
  -throw new ConnectionTimeoutException();
  +StringBuffer buffer = new StringBuffer();
  +buffer.append(The host ); 
  +buffer.append(host); 
  +buffer.append(:); 
  +buffer.append(port); 
  +buffer.append( did not accept the connection within timeout of ); 
  +buffer.append(this.params.getConnectionTimeout()); 
  +buffer.append( milliseconds); 
  +throw new ConnectTimeoutException(buffer.toString());
   }
   }
   
  @@ -893,7 +890,7 @@
   } else {
   LOG.debug(Input data not available);
   }
  -} catch

RE: [Math] common-math and bloated 3rd party libraries


--- Charles Hudak [EMAIL PROTECTED] wrote:
 Mark wrote:
  Eric Pugh wrote:
  This backlash against multiple commons jars is happening in a lot of
 places.
  However, I think it is a bit shortsighted.  If you are in a non
 server
  environment, I understand the problem, but in a server environment
 with
 lots
  of harddrive space, I don't.  Additionally, since in a server app you
 are
  likely to need all thoses dependencies any way.  I think almost every
 app
 I
  work on has commons-lang, commons-loggin, and commons-collections
 included.
  And then depending on what else, commons-discovery and
 commons-beanutils
  show up all the time!
 
 I think that this comment is a little shortsighted. We are still using
 weblogic 5.1 and constantly have problems with the multitude of third
 party
 libraries that we are using. WL 5.1 does not seem to find libraries in
 the
 WEB-INF/lib directory, as it should, so these have to be set using the
 classpath. Unfortunately, on Windows NT, the commandline has a size
 limitation. Every so often, after adding another library, we are unable
 to
 start the server due to a the command is too long error. This is a
 PITA
 and we have been working around it for several years.
 
 Having to add 3 or 4 extra commons jars just because I want to use ONE
 of
 the libraries is lame. 

I agree that packages should limit dependencies and I sympathize with your
problems.  However, you're using a broken container on a lame desktop OS. 
Trying to work around issues like this is *way* out of scope for commons
packages.

David

 I'm all for code reuse but it seems as if the
 commons
 developers have created alot of unnecessary dependancies between the
 projects (maybe as a show of solidarity, who knows). This also creates
 versioning problems. If I want to update one library, I may have to
 update
 several of it's dependant libraries, ad nauseum. I already deal with
 this
 hassle with the rapidly changing XML libraries and the fact that some
 idiot
 library developers insist on including dated versions of the dom and sax
 api's in their jars.
 /rant
 
 People need to realize that there are lots of legacy users out there who
 aren't limited by only 'harddrive space'.
 
 -
 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]

[OT] Re: [Math] common-math and bloated 3rd party libraries

2003-11-05 Thread Tomasz Pik

Sorry for a little offtopic post.

Charles Hudak wrote:

I think that this comment is a little shortsighted. We are still using
weblogic 5.1 and constantly have problems with the multitude of third party
libraries that we are using. WL 5.1 does not seem to find libraries in the
WEB-INF/lib directory, as it should, so these have to be set using the
classpath. Unfortunately, on Windows NT, the commandline has a size
limitation. Every so often, after adding another library, we are unable to
start the server due to a the command is too long error. This is a PITA
and we have been working around it for several years.
Check if your library names contains dots. We've found that something
like this-is-a-library-2.1.jar won't work on some versions of WebLogic.
After renaming to this-is-a-library-2_1.jar it works.
Regards,
Tomek


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

Re: [Math] common-math and bloated 3rd party libraries



Charles Hudak wrote:
Mark wrote:

Eric Pugh wrote:
This backlash against multiple commons jars is happening in a lot of
places.

However, I think it is a bit shortsighted.  If you are in a non server
environment, I understand the problem, but in a server environment with
lots

of harddrive space, I don't.  Additionally, since in a server app you are
likely to need all thoses dependencies any way.  I think almost every app
I

work on has commons-lang, commons-loggin, and commons-collections
included.

And then depending on what else, commons-discovery and commons-beanutils
show up all the time!


I think that this comment is a little shortsighted. 
Maybe we all need new glasses ;-)

We are still using
 and constantly have problems with the multitude of third party
libraries that we are using. WL 5.1 does not seem to find libraries in the
WEB-INF/lib directory, as it should, so these have to be set using the
classpath. Unfortunately, on Windows NT, the commandline has a size
limitation. Every so often, after adding another library, we are unable to
start the server due to a the command is too long error. This is a PITA
and we have been working around it for several years.
Having to add 3 or 4 extra commons jars just because I want to use ONE of
the libraries is lame. I'm all for code reuse but it seems as if the commons
developers have created alot of unnecessary dependancies between the
projects (maybe as a show of solidarity, who knows). This also creates
versioning problems. If I want to update one library, I may have to update
several of it's dependant libraries, ad nauseum. I already deal with this
hassle with the rapidly changing XML libraries and the fact that some idiot
library developers insist on including dated versions of the dom and sax
api's in their jars.
/rant
People need to realize that there are lots of legacy users out there who
aren't limited by only 'harddrive space'.
Hmm, not to be critical, but 5.1 is almost at the end of its product 
lifecycle. Weblogic has had several releases since 5.1 that solve many 
of these issues do they not? I say this mostly to identify that there 
is a limitation as to how far back in terms of versioning we, as a new 
tool, should consider supporting. I would have attempted to deal with 
an issue like this with BEA, not neccessarily with the java community at 
large because they create too many jars (I'm saying this lightly).

Not to nip a subject in the butt. But this has moved way off the issue 
associated with how dependent the different commons projects (and 
specifically related to math dependencies). I hope we can draw it back 
into this subject.

-Mark

--
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: [Math] common-math and bloated 3rd party libraries

2003-11-05 Thread Phil Steitz

David Graham wrote:
--- Charles Hudak [EMAIL PROTECTED] wrote:

Mark wrote:

Eric Pugh wrote:
This backlash against multiple commons jars is happening in a lot of

places.

However, I think it is a bit shortsighted.  If you are in a non

server

environment, I understand the problem, but in a server environment

with
lots
of harddrive space, I don't.  Additionally, since in a server app you

are

likely to need all thoses dependencies any way.  I think almost every

app
I
work on has commons-lang, commons-loggin, and commons-collections

included.

And then depending on what else, commons-discovery and

commons-beanutils

show up all the time!

I think that this comment is a little shortsighted. We are still using
weblogic 5.1 and constantly have problems with the multitude of third
party
libraries that we are using. WL 5.1 does not seem to find libraries in
the
WEB-INF/lib directory, as it should, so these have to be set using the
classpath. Unfortunately, on Windows NT, the commandline has a size
limitation. Every so often, after adding another library, we are unable
to
start the server due to a the command is too long error. This is a
PITA
and we have been working around it for several years.
Having to add 3 or 4 extra commons jars just because I want to use ONE
of
the libraries is lame. 


I agree that packages should limit dependencies and I sympathize with your
problems.  However, you're using a broken container on a lame desktop OS. 
Trying to work around issues like this is *way* out of scope for commons
packages.
I agree with your assessment of that platform; but your comment raises 
an interesting question: to what extent should commons component design 
decisions be influenced by characteristics of the user base.  My opinion 
is lots.  Lame and broken as it may be, WebLogic 5 on NT has a large 
installed base = lots of potential commons users.  Similarly, WebSphere 
3 (JDK - sic - 1.2.2) and WebSphere 4 (JDK 1.3.1) are huge. Most of 
these folks have do not have the luxury of choosing their deployment 
targets and they often have limited control over their deployment 
environments. I think that it is very reasonable to try to make things 
as easy as possible for them.

I also agree with Danny's observation above that for commons-math in 
particular, the commitment in the proposal was to keep dependencies to a 
minimum.

Phil

David


I'm all for code reuse but it seems as if the
commons
developers have created alot of unnecessary dependancies between the
projects (maybe as a show of solidarity, who knows). This also creates
versioning problems. If I want to update one library, I may have to
update
several of it's dependant libraries, ad nauseum. I already deal with
this
hassle with the rapidly changing XML libraries and the fact that some
idiot
library developers insist on including dated versions of the dom and sax
api's in their jars.
/rant
People need to realize that there are lots of legacy users out there who
aren't limited by only 'harddrive space'.
-
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]

[OT] Re: [Math] common-math and bloated 3rd party libraries


--- Phil Steitz [EMAIL PROTECTED] wrote:
 David Graham wrote:
  --- Charles Hudak [EMAIL PROTECTED] wrote:
  
 Mark wrote:
 
 Eric Pugh wrote:
 This backlash against multiple commons jars is happening in a lot of
 
 places.
 
 However, I think it is a bit shortsighted.  If you are in a non
 
 server
 
 environment, I understand the problem, but in a server environment
 
 with
 lots
 
 of harddrive space, I don't.  Additionally, since in a server app
 you
 
 are
 
 likely to need all thoses dependencies any way.  I think almost
 every
 
 app
 I
 
 work on has commons-lang, commons-loggin, and commons-collections
 
 included.
 
 And then depending on what else, commons-discovery and
 
 commons-beanutils
 
 show up all the time!
 
 I think that this comment is a little shortsighted. We are still using
 weblogic 5.1 and constantly have problems with the multitude of third
 party
 libraries that we are using. WL 5.1 does not seem to find libraries in
 the
 WEB-INF/lib directory, as it should, so these have to be set using the
 classpath. Unfortunately, on Windows NT, the commandline has a size
 limitation. Every so often, after adding another library, we are
 unable
 to
 start the server due to a the command is too long error. This is a
 PITA
 and we have been working around it for several years.
 
 Having to add 3 or 4 extra commons jars just because I want to use ONE
 of
 the libraries is lame. 
  
  
  I agree that packages should limit dependencies and I sympathize with
 your
  problems.  However, you're using a broken container on a lame desktop
 OS. 
  Trying to work around issues like this is *way* out of scope for
 commons
  packages.
 
 I agree with your assessment of that platform; but your comment raises 
 an interesting question: to what extent should commons component design 
 decisions be influenced by characteristics of the user base.  My opinion
 
 is lots.  

Struts has a perfect example of why this is a bad idea.  At one point we
changed our META-INF/Manifest.mf file from the standard format to a format
that WebLogic 5 would accept.  Sometime later, another bug was filed
because Tomcat didn't like our new Manifest.mf file format because it
wasn't in the standard format.

Straying from standard practices to accomodate broken products in your
user base is a quick way to generate a lot of bug reports.  IMO, the
Windows line length limitation and WebLogic's broken jar lookup are
absolutely not reasons to change Jakarta Commons components.

David

 Lame and broken as it may be, WebLogic 5 on NT has a large
 
 installed base = lots of potential commons users.  Similarly, WebSphere
 
 3 (JDK - sic - 1.2.2) and WebSphere 4 (JDK 1.3.1) are huge. Most of 
 these folks have do not have the luxury of choosing their deployment 
 targets and they often have limited control over their deployment 
 environments. I think that it is very reasonable to try to make things 
 as easy as possible for them.
 
 I also agree with Danny's observation above that for commons-math in 
 particular, the commitment in the proposal was to keep dependencies to a
 
 minimum.
 
 Phil
 
  
  David
  
  
 I'm all for code reuse but it seems as if the
 commons
 developers have created alot of unnecessary dependancies between the
 projects (maybe as a show of solidarity, who knows). This also creates
 versioning problems. If I want to update one library, I may have to
 update
 several of it's dependant libraries, ad nauseum. I already deal with
 this
 hassle with the rapidly changing XML libraries and the fact that some
 idiot
 library developers insist on including dated versions of the dom and
 sax
 api's in their jars.
 /rant
 
 People need to realize that there are lots of legacy users out there
 who
 aren't limited by only 'harddrive space'.
 
 -
 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]
 


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

Re: [Math] common-math and bloated 3rd party libraries



Phil Steitz wrote:
I agree with your assessment of that platform; but your comment raises 
an interesting question: to what extent should commons component design 
decisions be influenced by characteristics of the user base.  My opinion 
is lots.  Lame and broken as it may be, WebLogic 5 on NT has a large 
installed base = lots of potential commons users.  Similarly, WebSphere 
3 (JDK - sic - 1.2.2) and WebSphere 4 (JDK 1.3.1) are huge. Most of 
these folks have do not have the luxury of choosing their deployment 
targets and they often have limited control over their deployment 
environments. I think that it is very reasonable to try to make things 
as easy as possible for them.

I also agree with Danny's observation above that for commons-math in 
particular, the commitment in the proposal was to keep dependencies to a 
minimum.

Phil

Certainly not arguing about decisions influenced by characteristics of 
the user base. We definitly want this. And I think expecially in the 
consideration of JVM versions and capabilities, But, you know, wow what 
a murky and subjective domain when you get into web-platforms.

And to be a bit more philisophical, Literally, by maintaining for an 
older platform, you promote continued usage of that platform, which 
contributes to more issues you need to balance out across versions of 
platforms. Eventually there needs to be a line drawn

I really hope we don't think the command line limitations of the Windows 
platform should be an issue in deciding how many jars we're going to 
make the math project dependent on. lol 8-)

-M.

p.s. Yes, I'm the one eating my words by dragging this subject on even 
further now after I said to get back to the matter of dependencies in 
math specifically ;-)

--
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: [collections] [PATCH] CompositeCollection class for Commons-Collections

2003-11-05 Thread Arun Thomas

The toCollection(), toList(), etc. stuff would be no different (other than the 
collection overhead) from toArray().  What would get copied are object references.

I understood the proposed methods would work in this way.  I guess my questions is why 
it would be particularly useful to add these extra methods (toCollection, toList, 
toSet) as opposed to simply passing the composite collection to the addAll() method of 
the Collection/List/Set?  

In general, if a particular behaviour is expected of the resulting 
collection/list/set, the particular method used will be something to the effect of: 
toCollection(Collection c), or toList(List l) where a object with the expected 
characteristics can be passed in for filling.  But in this case, all it can do is call 
addAll on the supplied collection (or iterate and add each element individually I 
suppose).  

So, I'm not quite sure why this would be a useful/good thing?  

Also, I think that the behaviour you propose for nested collections is actually quite 
different from what composite collection provides.  The composite allows a set of 
collections to be treated as a collection (at least, so I understood from previous 
mails with code), which doesn't really consider the contents of those individual 
collections.  

I do think that many of those behaviours could be useful, but I'm not sure that 
overloading is the way to go about it.  Since a CompositeCollection IS A Collection, a 
user of the overloaded methods may not necessarily know whether the collection at hand 
is a Collection or a CompositeCollection, and could find unexpected behaviour when 
calling the overloaded methods.   

Have I understood your proposals correctly?

Cheers, 
-AMT

-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 05, 2003 10:42 AM
To: Jakarta Commons Developers List
Subject: Re: [collections] [PATCH] CompositeCollection class for Commons-Collections


Arun Thomas wrote:
  The last comment suggests another possibly useful method:   toList(), 
  returning an aggregated collection consisting of all of   the objects in the 
  composite collections.   In this case, will there be a clever way to 
  return an aggregation of   this sort that isn't simply a new object with copies 
  of all elements   of the contained objects?  If that's the case, then is seems 
  more   reasonable to leave the creation of this type of object to the user -   
  create a new object passing in the composite collection in the   constructor, or 
  use addAll(Collection c). If there's a clever way to handle provide the 
  implementation of   List/Set/Collection using the contained collections as a 
  base, that   might be interesting, but otherwise

That's essentially what the CompositeCollection class does -- decorates 
the aggregated collections with a Collection interface.

The toCollection(), toList(), etc. stuff would be no different (other 
than the collection overhead) from toArray().  What would get copied are 
object references.

Thinking a little more, I suppose that the semantics of both toArray() 
and toCollection() could be extended to fully flatten what could 
effectively become a tree of collections.  Since CompositeCollection is 
a Collection, composites could themselves be aggregated (as in Brian's 
use case above).  In this case, extensions of toArray() or 
toCollection() returning all of the objects nested in the collections 
might make sense. Of course this applies to ordinary collections as 
well.  Could be that if these methods are useful, they all (including 
CompositeCollection.toCollection()) belong in CollectionUtils, so 
instead of CompositeCollection.toCollection(), we just overload 
CollectionUtils.union(CompositeCollection) (maybe also intersection) 
and, if the tree traversal stuff is useful, we add something like 
CollectionUtils.traverse(Collection) that unwinds nested collections, 
returning a flattened list of objects that are not collections 
(carefully avoiding getting stuck in cycles) and maybe also 
CollectionUtils.rank(Collection) that returns the integer length of the 
longest branch in the tree. Individual objects also have ranks -- 
CollectionUtils.rank(Collection, Object) = level where Object is first 
encountered in breadth-first search.  OK, I will shut up now, starting 
to sound too much like a logician...Is any of this useful?

Phil
 
  Cheers, -AMT
 
  -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED]Sent: 
  Wednesday, November 05, 2003 8:31 AM To: Jakarta Commons   Developers List 
  Subject: Re: [collections] [PATCH]   CompositeCollection class for 
  Commons-Collections   Brian McCallister wrote: On Wednesday, November 
  5, 2003, at 12:10 AM, Phil Steitz wrote:   I think that that javadoc for 
  remove is incorrect when it says:   This implementation calls 
  coderemove()/code on each   collection. It stops when it finds the element 
  to be removed.   The

Re: [collections] [PATCH] CompositeCollection class for Commons-Collections

2003-11-05 Thread Phil Steitz

Arun Thomas wrote:
 The toCollection(), toList(), etc. stuff would be no different
 (other than the collection overhead) from toArray().  What would get
 copied are object references.

 I understood the proposed methods would work in this way.  I guess my
 questions is why it would be particularly useful to add these extra
 methods (toCollection, toList, toSet) as opposed to simply passing
 the composite collection to the addAll() method of the
 Collection/List/Set?
Now I understand and agree (though it will be interesting to test this).

 In general, if a particular behaviour is expected of the resulting
 collection/list/set, the particular method used will be something to
 the effect of: toCollection(Collection c), or toList(List l) where a
 object with the expected characteristics can be passed in for
 filling.  But in this case, all it can do is call addAll on the
 supplied collection (or iterate and add each element individually I
 suppose).

 So, I'm not quite sure why this would be a useful/good thing?

 Also, I think that the behaviour you propose for nested collections
 is actually quite different from what composite collection provides.
 The composite allows a set of collections to be treated as a
 collection (at least, so I understood from previous mails with code),
 which doesn't really consider the contents of those individual
 collections.

 I do think that many of those behaviours could be useful, but I'm not
 sure that overloading is the way to go about it.  Since a
 CompositeCollection IS A Collection, a user of the overloaded methods
 may not necessarily know whether the collection at hand is a
 Collection or a CompositeCollection, and could find unexpected
 behaviour when calling the overloaded methods.

Yes. I agree. Overloading would not be a good idea, for the reason that
you gave.
 Have I understood your proposals correctly?

 Cheers, -AMT

 -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED]
  Sent: Wednesday, November 05, 2003 10:42 AM To: Jakarta Commons
 Developers List Subject: Re: [collections] [PATCH]
 CompositeCollection class for Commons-Collections


 Arun Thomas wrote:
 The last comment suggests another possibly useful method:  
 toList(), returning an aggregated collection consisting of all
 of   the objects in the composite collections.   In
 this case, will there be a clever way to return an aggregation
 of   this sort that isn't simply a new object with copies of
 all elements   of the contained objects?  If that's the case,
 then is seems more   reasonable to leave the creation of this
 type of object to the user -   create a new object passing in
 the composite collection in the   constructor, or use
 addAll(Collection c). If there's a clever way to handle
 provide the implementation of   List/Set/Collection using the
 contained collections as a base, that   might be interesting,
 but otherwise

 That's essentially what the CompositeCollection class does --
 decorates the aggregated collections with a Collection interface.

 The toCollection(), toList(), etc. stuff would be no different (other
  than the collection overhead) from toArray().  What would get copied
 are object references.

 Thinking a little more, I suppose that the semantics of both
 toArray() and toCollection() could be extended to fully flatten what
 could effectively become a tree of collections.  Since
 CompositeCollection is a Collection, composites could themselves be
 aggregated (as in Brian's use case above).  In this case, extensions
 of toArray() or toCollection() returning all of the objects nested in
 the collections might make sense. Of course this applies to ordinary
 collections as well.  Could be that if these methods are useful, they
 all (including CompositeCollection.toCollection()) belong in
 CollectionUtils, so instead of CompositeCollection.toCollection(), we
 just overload CollectionUtils.union(CompositeCollection) (maybe also
 intersection) and, if the tree traversal stuff is useful, we add
 something like CollectionUtils.traverse(Collection) that unwinds
 nested collections, returning a flattened list of objects that are
 not collections (carefully avoiding getting stuck in cycles) and
 maybe also CollectionUtils.rank(Collection) that returns the integer
 length of the longest branch in the tree. Individual objects also
 have ranks -- CollectionUtils.rank(Collection, Object) = level where
 Object is first encountered in breadth-first search.  OK, I will shut
 up now, starting to sound too much like a logician...Is any of this
 useful?

 Phil

 Cheers, -AMT

 -Original Message- From: Phil Steitz
 [mailto:[EMAIL PROTECTED]Sent: Wednesday, November 05, 2003
 8:31 AM To: Jakarta Commons   Developers List Subject: Re:
 [collections] [PATCH]   CompositeCollection class for
 Commons-Collections   Brian McCallister wrote: On
 Wednesday, November 5, 2003, at 12:10 AM, Phil Steitz wrote:  
I think that that javadoc for remove is

[math] logging and exception handling in distributions

There's been a Convergence Exception used in ContinuedFraction and 
special.Gamma for some time now.

I was able to remove the logging references from the util.Transformer 
implementations by creating a TransformerException and wrapping 
exceptions and passing them out to the application. This allows the 
implementor using the transformer to manage what to do with such 
exceptions. Ideally this also leaves room for the implementor of a 
Custom Transformer to do what they want without disturbing the 
statistical process upstream. I think this make allot more logical sense 
now.

The other places that logging is used is in the cummulativeProbability 
calculation of the various Distributions in o.a.c.m.stat.distribution. I 
could just remove these logging entries, but I concerned that this 
creates a loss of information, is anyone else concerned with this? 
Otherwise, I'd like to loose them.

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

request sandbox karma

2003-11-05 Thread Brett Porter

Hi,

I was wondering if someone could grant me sandbox karma so I can make some
contributions to commons-naming. My apache CVS username is brett.

Thanks in advance,
Brett

Re: [primitives] Object/JDK integration - was Proposed interface changes

2003-11-05 Thread Stephen Colebourne

As people may or may not be aware, the sandbox contains an implementation of
primitive collections that works differently from [primitives].

* [primitives] (commons-proper) - IntCollection is a top-level interface in
its own right. A wrapper is needed to integrate with JDK Collection.
* primitives-sandbox - IntCollection extends Collection in the JDK.

These are two entirely different approaches to the problem space. Here are
the reasons why I prefer the sandbox approach:
- Integration - an IntCollection IS a JDK Collection, no extra wrappers
needed
- Number of classes - Because it is a JDK Collection, no wrappers or
adaptors are needed
- Possible to implement multiple collections in one class, ie. a class could
implement both IntCollection and ShortCollection.
Main downside:
- Methods are named differently from JDK Collection in places because of
return type issues
  * intInterator()
  * toIntArray()
  * removeInt()
  * getInt(index)

The benefits of the commons-proper approach appear to be:
- Simpler API for IntCollection et al, no confusion with Object world
- Methods are named exactly as per the JDK collection (except remove)
- Simpler implementation for each class, as it focuses on one task
- Theory of relatively low interaction between primitive collections and
object ones?
Main downside:
- Object and JDK integration - keeps Object and primitive worlds separate,
which goes against the [primitives] charter in my mind.


This thread allows for one final debate as to the best approach for
primitives design. We may decide its now too late for commons-proper as it
has a release, or we may not.

If we decide to stay with the [primitives] commons-proper architecture, I
hereby commit to remove the commons-sandbox code from the CVS to non ASF (or
rename it if people express a desire to keep it).


Finally, this thread started when I proposed a toCollection() method for
IntCollection et al, and a toList() method for IntList. If we keep the
commons-proper design we should examine these methods as to whether they are
not the bare minimum for Object/JDK integration.

Stephen


From: Rodney Waldhoff [EMAIL PROTECTED]
  New interface PCollection (or PrimitiveCollection):
  - toCollection()
  It should be really easy to get a JDK collection from a [primitives]
one.

 TypeCollectionCollection.wrap(mytypecollection) does this already.
 I'd be OK with adding a convenience method somewhere, though I'm not sure
 PrimitiveCollection is the right place for it.  (Perhaps
 PrimitiveCollections.toCollection(TypeCollection): Collection?)



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

cvs commit: jakarta-commons/primitives/xdocs index.xml

2003-11-05 Thread rwaldhoff

rwaldhoff2003/11/05 16:55:23

  Modified:primitives/xdocs index.xml
  Log:
  add link to 1.0 release
  
  Revision  ChangesPath
  1.6   +4 -4  jakarta-commons/primitives/xdocs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-commons/primitives/xdocs/index.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- index.xml 29 Oct 2003 22:00:29 -  1.5
  +++ index.xml 6 Nov 2003 00:55:23 -   1.6
  @@ -20,12 +20,12 @@
   
   section name=Status
   p
  -Commons Primitives has not yet had a formal release.
  +The most recent stable release is version 1.0, released 5 November 2003.  
  +a href=http://jakarta.apache.org/site/binindex.cgi#commons-primitives;Binary/a 
and
  +a 
href=http://jakarta.apache.org/site/sourceindex.cgi#commons-primitives;source/a 
distributions are available.
  +/pp
   Daily builds and tarballs are available from
   a 
href=http://cvs.apache.org/builds/jakarta-commons/nightly/commons-primitives/;http://cvs.apache.org/builds/jakarta-commons/nightly/commons-primitives//a.
  -/pp
  -The current codebase is stable and a href=./cloverwell-tested/a
  -nevertheless.  A 1.0 release is expected real soon now.
   /p
   /section
   
  
  
  

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

Re: [collections] [PATCH] CompositeCollection class for Commons-Collections

2003-11-05 Thread Stephen Colebourne

From: Phil Steitz [EMAIL PROTECTED]
 Anyone have any objections to committing this to the decorators
subpackage?

 Phil
+1. The test needs work as its not a collections-testframework test.

Stephen



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

cvs commit: jakarta-commons/primitives project.xml build.xml

2003-11-05 Thread rwaldhoff

rwaldhoff2003/11/05 17:06:58

  Modified:primitives project.xml build.xml
  Log:
  update version number to 2.0-dev
  
  Revision  ChangesPath
  1.10  +1 -1  jakarta-commons/primitives/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-commons/primitives/project.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- project.xml   5 Nov 2003 23:21:47 -   1.9
  +++ project.xml   6 Nov 2003 01:06:58 -   1.10
  @@ -3,7 +3,7 @@
 extend../xdocs/maven/project-base.xml/extend
 idcommons-primitives/id
 nameCommons Primitives/name
  -  currentVersion1.0/currentVersion
  +  currentVersion2.0-dev/currentVersion
 inceptionYear2002/inceptionYear
   
 packageorg.apache.commons.collections.primitives/package
  
  
  
  1.8   +2 -2  jakarta-commons/primitives/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-commons/primitives/build.xml,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- build.xml 5 Nov 2003 23:21:47 -   1.7
  +++ build.xml 6 Nov 2003 01:06:58 -   1.8
  @@ -43,7 +43,7 @@
 property name=component.title value=Primitive type utilities/
   
 !-- The current version number of this component --
  -  property name=component.version   value=1.0/
  +  property name=component.version   value=2.0-dev/
   
 !-- The final name of the component --
 property name=final.name  
value=commons-${component.name}-${component.version}/
  
  
  

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

cvs commit: jakarta-commons/xdocs components.xml

2003-11-05 Thread rwaldhoff

rwaldhoff2003/11/05 17:07:09

  Modified:docs components.html
   xdocscomponents.xml
  Log:
  update for primitives 1.0 release
  
  Revision  ChangesPath
  1.128 +14 -9 jakarta-commons/docs/components.html
  
  Index: components.html
  ===
  RCS file: /home/cvs/jakarta-commons/docs/components.html,v
  retrieving revision 1.127
  retrieving revision 1.128
  diff -u -r1.127 -r1.128
  --- components.html   4 Nov 2003 22:49:54 -   1.127
  +++ components.html   6 Nov 2003 01:07:09 -   1.128
  @@ -486,15 +486,6 @@
   /dd
   !-- /Net --
   
  -!-- Primitives --
  -dtbbiga 
href=http://jakarta.apache.org/commons/primitives/;Primitives/a/big/b/dt
  -dd
  - Commons-Primitives provides smaller, faster and easier to work with types 
supporting Java primitive types.
  - Currently Primitives is primarily focused on collections of primitives.
  - br /
  - Primitives has not yet had a formal release.
  -/dd
  -
   !-- Pool --
   dtbbiga 
href=http://jakarta.apache.org/commons/pool/;Pool/a/big/b/dt
   dd
  @@ -511,6 +502,20 @@
/ul
   /dd
   !-- /Pool --
  +
  +!-- Primitives --
  +dtbbiga 
href=http://jakarta.apache.org/commons/primitives/;Primitives/a/big/b/dt
  +dd
  + Commons-Primitives provides smaller, faster and easier to work with types 
supporting Java primitive types.
  + Currently Primitives is primarily focused on collections of primitives.
  + br /
  + Releases: 
  +   (a 
href=http://jakarta.apache.org/site/binindex.cgi#commons-primitives;binary/a, 
  +   a 
href=http://jakarta.apache.org/site/sourceindex.cgi#commons-primitives;source/a)
  + ul
  +   liRelease 1.0 - 5 November 2003/li
  + /ul
  +/dd
   
  !-- validator --
   dtbbiga href=./validator/Validator/a/big/b/dt
  
  
  
  1.105 +14 -9 jakarta-commons/xdocs/components.xml
  
  Index: components.xml
  ===
  RCS file: /home/cvs/jakarta-commons/xdocs/components.xml,v
  retrieving revision 1.104
  retrieving revision 1.105
  diff -u -r1.104 -r1.105
  --- components.xml2 Nov 2003 19:26:56 -   1.104
  +++ components.xml6 Nov 2003 01:07:09 -   1.105
  @@ -269,15 +269,6 @@
   /dd
   !-- /Net --
   
  -!-- Primitives --
  -dtbbiga 
href=http://jakarta.apache.org/commons/primitives/;Primitives/a/big/b/dt
  -dd
  - Commons-Primitives provides smaller, faster and easier to work with types 
supporting Java primitive types.
  - Currently Primitives is primarily focused on collections of primitives.
  - br/
  - Primitives has not yet had a formal release.
  -/dd
  -
   !-- Pool --
   dtbbiga 
href=http://jakarta.apache.org/commons/pool/;Pool/a/big/b/dt
   dd
  @@ -294,6 +285,20 @@
/ul
   /dd
   !-- /Pool --
  +
  +!-- Primitives --
  +dtbbiga 
href=http://jakarta.apache.org/commons/primitives/;Primitives/a/big/b/dt
  +dd
  + Commons-Primitives provides smaller, faster and easier to work with types 
supporting Java primitive types.
  + Currently Primitives is primarily focused on collections of primitives.
  + br /
  + Releases: 
  +   (a 
href=http://jakarta.apache.org/site/binindex.cgi#commons-primitives;binary/a, 
  +   a 
href=http://jakarta.apache.org/site/sourceindex.cgi#commons-primitives;source/a)
  + ul
  +   liRelease 1.0 - 5 November 2003/li
  + /ul
  +/dd
   
  !-- validator --
   dtbbiga href=./validator/Validator/a/big/b/dt
  
  
  

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

Re: [collections] [PATCH] CompositeCollection class for Commons-Collections

2003-11-05 Thread Gareth Andrew

Stephen,

Have you any tests to prove there is actually a performance gain?  
Surely either (or both) the java compiler or the JVM should be 
responsible for optimizations such as this.

Gareth.

Stephen Colebourne wrote:

From: Brian McCallister [EMAIL PROTECTED]
On Monday, November 3, 2003, at 07:48 PM, Stephen Colebourne wrote:
 

I've updated the class in line with commons standards/documentation
etc. It
will probably end up in the decorators subpackage, as it decorates
other
collections.
 

A few style questions about this...

You have changed the array traversal to use the form:

public int size() {
int size = 0;
for (int i = this.all.length - 1; i = 0 ; i--) {
size += this.all[i].size();
}
return size;
}
   

 

Do you really see a performance gain from not dereferencing
this.all.length on each cycle? If so, cool stuff!
   

Yes, you gain from not having to check the variable all and its length. You
also gain from the comparision to 0 (i=0) which is quicker than a non-zero
comparison (i   n). Some methods required to keep the order, so I have been
selective.
Stephen



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

[Chain] ContextToRequestCommand

2003-11-05 Thread Jeff Caddel

Any feedback on this Command implementation?

The idea is that as a chain of commands is executing objects get 
aggregated into a map.  The context holds a reference to the map.  At 
the tail end of the execution chain, this command places the objects 
from the map into the request as request attributes so that front end 
components (Tiles, JSP's etc) can display them.

Is this:
A) A terrible idea violating abstractions of the Chain of Responsibility 
pattern? 
B) A good idea demonstrating good use of the pattern?
C) Something else?

public class ContextToRequestCommand implements Command {
   String key = contextToRequest;
   public boolean execute(Context context) throws Exception {
   HttpServletRequest request = 
(HttpServletRequest)context.get(request);
   Map map = (Map)context.get(key);
   if (map == null) {
   return false;
   }

   Iterator pairs = map.entrySet().iterator();
   while (pairs.hasNext()) {
   Map.Entry pair = (Map.Entry)pairs.next();
   request.setAttribute((String)pair.getKey(), pair.getValue());
   }
   return false;
   }
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [hivemind] what exactly is the issue here?

2003-11-05 Thread Noel J. Bergman

Rodney Waldhoff wrote:
 On Wed, 5 Nov 2003, Noel J. Bergman wrote:
  We're not the ones whom Howard needs to discuss this with.

 Yes and no.  I'm on the Jakarta PMC, you're an ASF member, we're
 both jakarta commons committers, so I belive and as I understand
 it, we are among the ones Howard needs to discuss this with.

In your capacity as a Jakarta PMC member, yes.  And there are other PMC
members here, such as Craig, Danny, and Howard, himself, IIRC.

I don't care if he talks with me about this situation or not; the Board are
our elected Officers, with the experience to resolve such matters, or bring
them to the membership if they felt the need.  However, Howard has an
obligation to notify the Foundation when an IP issue arises.  Even though
there is reason to believe that this situation will work out fine, and even
if the PMC and Board would delegate to him the ability to work out the plan
within some guidelines, keeping them out of the loop is not his decision to
make.  I am honestly not sure what he's thinking in terms of why he has not
brought the issue to the PMC and/or Board.  Some of his messages seem to
imply that he feels that if he did, there would be drastic action.

--- Noel


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

[ANN] Jakarta Commons Primitives 1.0 Released

The Jakarta Commons Team is pleased to announce the first release of
Jakarta Commons Primitives.

Primitives provides a collection of types and
utilities optimized for working with Java primitives (boolean, byte, char,
double, float, int, long, short). Generally, the Commons-Primitives
classes are faster, smaller and easier to work with than their purely
Object based alternatives.

DOWNLOADS (source and binaries -- from mirror):

* Binary:
http://jakarta.apache.org/site/binindex.cgi#commons-primitives

* Source:
http://jakarta.apache.org/site/sourceindex.cgi#commons-primitives

For more information on Jakarta Commons Primitives, see the web site at
http://jakarta.apache.org/commons/primitives.

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

Re: Cookie test case failures with Tomcat 4.1.29

2003-11-05 Thread Roland Weber

Hello Eric,

From RFC 2965, HTTP State Management, Section 3:

   value   = token | quoted-string
[...]
   cookie  =   NAME = VALUE *(; set-cookie-av)
   VALUE   =   value

That is part of the BNF grammar for the set-cookie2 header.
All the examples in section 4 use quoted values, but due to
the token choice, quotes are required only if the value contains
special characters, as defined by RFC 2616 (HTTP 1.1),
section 2.2. As long as there are no special characters in the
value, the test cases should be right.

hope this helps,
  Roland






Eric Johnson [EMAIL PROTECTED]
04.11.2003 17:10
Please respond to Commons HttpClient Project
 
To: HttpClient [EMAIL PROTECTED]
cc: 
Subject:Cookie test case failures with Tomcat 4.1.29


It would seem that the latest Tomcat (4.1.29) has engaged in a subtle 
change in behavior with respect to cookies.  When I ran it this morning, 
nine of the cookie related test cases failed.  Last week, I was running 
with Tomcat 4.1.27, and everything worked fine.

Since I had it readily available, I fell back to Tomcat 4.1.18 (I 
deleted 4.1.27, unfortunately, and Apache is no longer hosting it) and 
ran the tests again, and got all of the tests to pass with no errors.

Upon inspection, the failures would seem to be due to the test servlet 
returning:

ttsimplecookie=value/tt

instead of:

ttsimplecookie=value/tt

Which is right - our test cases, or the new behavior?

-Eric.


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

[Https proxy] Impossible to connect

Hi, I'm using HttpClient 2.0 rc2.
I've got a pbm when trying to connect to a HTTPS
server (with a client certificate), using a proxy.

I saw the bug #7643 was resolved, but it seems it
doesn't work with a client certificate.

Can anybody help me ?
Thanks.

Here are the logs :
2003/11/05 10:45:06:312 CET [DEBUG] HttpMethodDirector
- -Execute loop try 1
2003/11/05 10:45:06:421 CET [DEBUG] HttpMethodDirector
- -Preemptively sending default basic credentials
2003/11/05 10:45:06:453 CET [DEBUG] HttpMethodDirector
- -Default basic proxy credentials applied
2003-11-05 10:45:06,453[main]|INFO
|(StrictSSLProtocolSocketFactory.java:createSocket():131)|Création
d'une socket
2003-11-05 10:45:06,515[main]|INFO
|(StrictSSLProtocolSocketFactory.java:verifyHostname():166)|Pas
de vérification du serveur
2003/11/05 10:45:06:531 CET [DEBUG] wire - - POST
https://abc.sam.fr:8180/toto HTTP/1.1[\r][\n]
2003/11/05 10:45:06:531 CET [DEBUG] HttpMethodBase -
-Adding Host request header
2003/11/05 10:45:06:875 CET [DEBUG] HttpMethodBase -
-Default charset used: ISO-8859-1
2003/11/05 10:45:06:890 CET [DEBUG] wire - -
application/x-www-form-urlencoded: [\r][\n]
2003/11/05 10:45:06:890 CET [DEBUG] wire - -
User-Agent: Jakarta Commons-HttpClient[\r][\n]
2003/11/05 10:45:06:890 CET [DEBUG] wire - - Host:
abc.sam.fr:8180[\r][\n]
2003/11/05 10:45:06:906 CET [DEBUG] wire - -
Proxy-Connection: Keep-Alive[\r][\n]
2003/11/05 10:45:06:906 CET [DEBUG] wire - -
Content-Length: 774[\r][\n]
2003/11/05 10:45:06:906 CET [DEBUG] wire - -
Content-Type:
application/x-www-form-urlencoded[\r][\n]
%% No cached client session
*** ClientHello, v3.1
RandomCookie:  GMT: 1051182498 bytes = { [...]}
Session ID:  {}
Cipher Suites:  { [...]}
Compression Methods:  { 0 }
***
[write] MD5 and SHA1 hashes:  len = 59
: [...]
main, WRITE:  SSL v3.1 Handshake, length = 59
[write] MD5 and SHA1 hashes:  len = 77
: [...]
length = 16310

and after 2 or 3 min :
main, SEND SSL v3.1 ALERT:  fatal, description =
close_notify
main, WRITE:  SSL v3.1 Alert, length = 2
2003/11/05 10:50:08:140 CET [DEBUG] HttpConnection -
-Releasing connection back to connection manager.

The Exception :
javax.net.ssl.SSLException: error while writing to
socket
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.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)

___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

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

RE: [Https proxy] Impossible to connect

Thanks for your answer,

Indeed, I tried a development version of HttpClient,
since HttpClient v2.0 rc2 didn't work as I expected.

Here are the logs with 2.0 rc2 :
2003/11/05 11:16:05:140 CET [DEBUG] HttpConnection -
-HttpConnection.setSoTimeout(0)
2003/11/05 11:16:05:187 CET [DEBUG] HttpMethodBase -
-Preemptively sending default basic credentials
2003/11/05 11:16:05:515 CET [DEBUG] HttpMethodBase -
-Default basic proxy credentials applied
2003/11/05 11:16:05:515 CET [DEBUG] HttpMethodBase -
-Execute loop try 1
2003/11/05 11:16:05:531 CET [DEBUG] wire - - POST
https://abc.sam.fr:8180/toto HTTP/1.1[\r][\n]
2003/11/05 11:16:05:531 CET [DEBUG] HttpMethodBase -
-Adding Host request header
2003/11/05 11:16:05:546 CET [DEBUG] HttpMethodBase -
-Default charset used: ISO-8859-1
2003/11/05 11:16:05:578 CET [DEBUG] wire - -
application/x-www-form-urlencoded: [\r][\n]
2003/11/05 11:16:05:593 CET [DEBUG] wire - -
Proxy-Authorization: Basic c2JuOnNibjI=[\r][\n]
2003/11/05 11:16:05:593 CET [DEBUG] wire - -
User-Agent: Jakarta
Commons-HttpClient/2.0rc2[\r][\n]
2003/11/05 11:16:05:593 CET [DEBUG] wire - - Host:
abc.sam.fr:8180[\r][\n]
2003/11/05 11:16:05:593 CET [DEBUG] wire - -
Proxy-Connection: Keep-Alive[\r][\n]
2003/11/05 11:16:05:593 CET [DEBUG] wire - -
Content-Length: 774[\r][\n]
2003/11/05 11:16:05:593 CET [DEBUG] wire - -
Content-Type:
application/x-www-form-urlencoded[\r][\n]
%% No cached client session
*** ClientHello, v3.1
RandomCookie:  GMT: 1051184357 bytes = { [...] }
Session ID:  {}
Cipher Suites:  { [...] }
Compression Methods:  { 0 }
***
[write] MD5 and SHA1 hashes:  len = 59
: [...]...
main, WRITE:  SSL v3.1 Handshake, length = 59
[write] MD5 and SHA1 hashes:  len = 77
: [...]
main, WRITE:  SSL v2, contentType = 22, translated
length = 16310

and... 2 mins later :
main, SEND SSL v3.1 ALERT:  fatal, description =
close_notify
main, WRITE:  SSL v3.1 Alert, length = 2

and the exception :
javax.net.ssl.SSLException: error while writing to
socket
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)

Note : it only happens if I use a client certificate.
= It's urgent : What can I do ?
Thanks.




 --- Kalnichevski, Oleg
[EMAIL PROTECTED] a écrit : 
Samuel, 
 According to the log you are using the development
 version of HttpClient (currently as designated 2.1).
 I would strongly recommend using the 2.0 branch
 until CVS HEAD stabilizes somewhat. Currently
 authentication logic in CVS HEAD is completely
 broken by one of my recent patches. I am busy
 working on a fix, but it may take a while, as the
 fix is most likely to require changes in the API.
 
 Oleg
 
 -Original Message-
 From: Samuel BONNANFANT [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, November 05, 2003 10:54
 To: [EMAIL PROTECTED]
 Subject: [Https  proxy] Impossible to connect
 
 
 Hi, I'm using HttpClient 2.0 rc2.
 I've got a pbm when trying to connect to a HTTPS
 server (with a client certificate), using a proxy.
 
 I saw the bug #7643 was resolved, but it seems it
 doesn't work with a client certificate.
 
 Can anybody help me ?
 Thanks.
 
 Here are the logs :
 2003/11/05 10:45:06:312 CET [DEBUG]
 HttpMethodDirector
 - -Execute loop try 1
 2003/11/05 10:45:06:421 CET [DEBUG]
 HttpMethodDirector
 - -Preemptively sending default basic credentials
 2003/11/05 10:45:06:453 CET [DEBUG]
 HttpMethodDirector
 - -Default basic proxy credentials applied
 2003-11-05 10:45:06,453[main]|INFO

|(StrictSSLProtocolSocketFactory.java:createSocket():131)|Création
 d'une socket
 2003-11-05 10:45:06,515[main]|INFO

|(StrictSSLProtocolSocketFactory.java:verifyHostname():166)|Pas
 de vérification du serveur
 2003/11/05 10:45:06:531 CET [DEBUG] wire - - POST
 https://abc.sam.fr:8180/toto HTTP/1.1[\r][\n]
 2003/11/05 10:45:06:531 CET [DEBUG] HttpMethodBase -
 -Adding Host request header
 2003/11/05 10:45:06:875 CET [DEBUG] HttpMethodBase -
 -Default charset used: ISO-8859-1
 2003/11/05 10:45:06:890 CET [DEBUG] wire - -
 application/x-www-form-urlencoded: [\r][\n]
 2003/11/05 10:45:06:890 CET [DEBUG] wire - -
 User-Agent: Jakarta Commons-HttpClient[\r][\n]
 2003/11/05 10:45:06:890 CET [DEBUG] wire - -
 Host:
 abc.sam.fr:8180[\r][\n]
 2003/11/05 10:45:06:906 CET [DEBUG] wire - -
 Proxy-Connection: Keep-Alive[\r][\n]
 2003/11/05 10:45:06:906 CET [DEBUG] wire - -
 Content-Length: 774[\r][\n]
 2003/11/05 10:45:06:906 CET [DEBUG] wire - -
 Content-Type:
 application/x-www-form-urlencoded[\r][\n]
 %% No cached client session
 *** ClientHello, v3.1
 RandomCookie:  GMT: 1051182498 bytes = { [...]}
 Session ID:  {}
 Cipher Suites:  { [...]}
 Compression Methods:  { 0 }
 ***
 [write] MD5 and SHA1 hashes:  len = 59
 : [...]
 main, WRITE:  SSL v3.1 Handshake, length = 59
 [write] MD5 and SHA1 hashes:  len = 77
 : [...]
 length = 16310
 
 and after 2 or 3 min :
 main, SEND SSL v3.1 ALERT:  fatal, description =
 close_notify
 main, WRITE:  SSL v3.1 Alert, length = 2

Re: [Https proxy] Impossible to connect

2003-11-05 Thread Ortwin Glück

isn't that just a timeout?

Samuel BONNANFANT wrote:
and... 2 mins later :
main, SEND SSL v3.1 ALERT:  fatal, description =
close_notify
main, WRITE:  SSL v3.1 Alert, length = 2
and the exception :
javax.net.ssl.SSLException: error while writing to
socket


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

Re: [Https proxy] Impossible to connect

It is a timeout, yes.
But if I don't use the proxy, I don't get the timeout.

 --- Ortwin_Glück [EMAIL PROTECTED] a écrit : 
isn't that just a timeout?
 
 Samuel BONNANFANT wrote:
  and... 2 mins later :
  main, SEND SSL v3.1 ALERT:  fatal, description =
  close_notify
  main, WRITE:  SSL v3.1 Alert, length = 2
  
  and the exception :
  javax.net.ssl.SSLException: error while writing to
  socket
 
 

-
 To unsubscribe, e-mail:

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

___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

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

RE: [Https proxy] Impossible to connect

2003-11-05 Thread Kalnichevski, Oleg

OK. That clears things up quite a bit. What proxy are you using? Is it HTTP/1.1 or 
HTTP/1.0 compliant proxy? If it doubt use HTTP/1.0

Oleg

-Original Message-
From: Samuel BONNANFANT [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 05, 2003 11:37
To: Commons HttpClient Project
Subject: Re: [Https  proxy] Impossible to connect


It is a timeout, yes.
But if I don't use the proxy, I don't get the timeout.

 --- Ortwin_Glück [EMAIL PROTECTED] a écrit : 
isn't that just a timeout?
 
 Samuel BONNANFANT wrote:
  and... 2 mins later :
  main, SEND SSL v3.1 ALERT:  fatal, description =
  close_notify
  main, WRITE:  SSL v3.1 Alert, length = 2
  
  and the exception :
  javax.net.ssl.SSLException: error while writing to
  socket
 
 

-
 To unsubscribe, e-mail:

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

___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

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


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

Re: [Https proxy] Impossible to connect

2003-11-05 Thread Ortwin Glück

Proxies usually close connections after a certain idle time to free up 
their resources because they can not tell if a connection is just idle 
or if the client died. You should catch this situation and reopen the 
connection in your code.

I guess HttpClient would actually even be able to handle this properly 
if the underlying SSL implementation throwed an IOException instead of 
an unchecked exception.

Odi

Samuel BONNANFANT wrote:

It is a timeout, yes.
But if I don't use the proxy, I don't get the timeout.


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

RE: PATCH: HttpConnection cleanup

2003-11-05 Thread Kalnichevski, Oleg

 I think close and flush should still throw recoverable exceptions, when 
 the connection has been used.  This will allow methods to be retried in 
 the event of an error on close/flush.  Other than that it looks good.

Mike,
So be it. I'll leave alone close/flush of the wrapper stream.

If there are no other complaints/comment/suggestions, I'll commit the patch tonight 
(around 20:00 GMT)

Oleg

On Nov 4, 2003, at 12:06 PM, Kalnichevski, Oleg wrote:

 Folks, any feedback to this one so far?

 Oleg

 -Original Message-
 From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
 Sent: Sunday, November 02, 2003 17:07
 To: Jakarata Commons HttpClient mailing list
 Subject: PATCH: HttpConnection cleanup


 Folks,

 This patch has been prompted by the questions/concerns raised by Fabio
 linea at libero.it. Let's face it, HttpConnection has got a bit messy
 with all the numerous changes made recently. In particular the 
 exception
 handling especially with regards to handling recoverable exceptions and
 timeouts got muddy. This patch attempts to address the problem

 changelog:

 - Socket input stream now wrapped with a wrapper class that re-throws
 certain type of generic IO exceptions as HttpClient specific 
 exceptions.
 In particular java.io.InterruptedIOExceptions are re-thrown as
 IOTimeoutException
 - java.io.InterruptedIOExceptions in HttpConnection#open() re-thrown as
 ConnectTimeoutException
 - HttpConnection#write(byte[], int, int) used to throw
 HttpRecoverableException in case of getting absolutely messed up
 parameters. changed to throw IllegalArgumentException instead
 - HttpConnection#write(byte[], int, int) does not do any exception
 handling anymore, since this is clearly a prerogative of the
 WrappedOutputStream
 - 'used' flag in HttpConnection was set to true only upon the 
 connection
 release. Why? Was there any reason for this kind of behavior? That 
 doest
 not seem right to me. Changed to set 'used' flag upon first successful
 write operation. Mike, please have a close look. Let me know if you
 disagree with the change. It can well be that I missed something
 important.
 - close() and flush() in WrappedOutputStream no longer throw
 HttpRecoverableExceptions. I believe this kind of exceptions are too
 severe to be automatically recovered from

 Let me know what you think

 Oleg

 -
 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: [Https proxy] Impossible to connect

I'm using a free proxy : CCProxy 6.0 on win2k.

I don't know if it is HTTP/1.1 or HTTP/1.0 compliant,
and I don't know if I can choose.

Do you know other reliable proxy ?

 --- Kalnichevski, Oleg
[EMAIL PROTECTED] a écrit :  OK.
That clears things up quite a bit. What proxy
 are you using? Is it HTTP/1.1 or HTTP/1.0 compliant
 proxy? If it doubt use HTTP/1.0
 
 Oleg
 
 -Original Message-
 From: Samuel BONNANFANT [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, November 05, 2003 11:37
 To: Commons HttpClient Project
 Subject: Re: [Https  proxy] Impossible to connect
 
 
 It is a timeout, yes.
 But if I don't use the proxy, I don't get the
 timeout.
 
  --- Ortwin_Glück [EMAIL PROTECTED] a écrit :
 
 isn't that just a timeout?
  
  Samuel BONNANFANT wrote:
   and... 2 mins later :
   main, SEND SSL v3.1 ALERT:  fatal, description =
   close_notify
   main, WRITE:  SSL v3.1 Alert, length = 2
   
   and the exception :
   javax.net.ssl.SSLException: error while writing
 to
   socket
  
  
 

-
  To unsubscribe, e-mail:
 

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

___
 Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et
 en français !
 Yahoo! Mail : http://fr.mail.yahoo.com
 

-
 To unsubscribe, e-mail:

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

-
 To unsubscribe, e-mail:

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

___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

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

RE: [Https proxy] Impossible to connect

Oleg,

I tried the following :
1) using classical SSLSocket with the proxy : that's
what I do if I don't want to use client certificate.
In this case, it works.

2) using SSLSocket from SecureProtocolSocketFactory
without proxy (connect directly to the server). In
this case, it works, too.

3) But if I try SSLSocket from
SecureProtocolSocketFactory with proxy, it doesn't
work.

 --- Kalnichevski, Oleg
[EMAIL PROTECTED] a écrit : 
Samuel,
 HttpClient does not implement its own SSL support.
 It relies on standard JSSE libraries to make the
 magic happen. The exception you are getting is
 thrown by the JSSE layer, which seems to indicate
 the problem with your SSL setup rather than a
 problem in HttpClient. Please have a look at
 troubleshooting section of the HttpClient SSL guide
 below
 

http://jakarta.apache.org/commons/httpclient/sslguide.html
 
 See if you can establish connection using plain
 SSLSocket. Another thing to try is hitting the
 server directly (not via a proxy) to see if that
 makes any difference. Usually SSL via proxy is
 highly prone to all sorts of mishaps due to its
 complexity. If possible, try to reduce the
 complexity of your setup in order to pinpoint the
 component that causes the trouble in the first
 place.
 
 Oleg
 
 
 -Original Message-
 From: Samuel BONNANFANT [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, November 05, 2003 11:26
 To: Commons HttpClient Project
 Subject: RE: [Https  proxy] Impossible to connect
 
 
 Thanks for your answer,
 
 Indeed, I tried a development version of HttpClient,
 since HttpClient v2.0 rc2 didn't work as I
 expected.
 
 Here are the logs with 2.0 rc2 :
 2003/11/05 11:16:05:140 CET [DEBUG] HttpConnection -
 -HttpConnection.setSoTimeout(0)
 2003/11/05 11:16:05:187 CET [DEBUG] HttpMethodBase -
 -Preemptively sending default basic credentials
 2003/11/05 11:16:05:515 CET [DEBUG] HttpMethodBase -
 -Default basic proxy credentials applied
 2003/11/05 11:16:05:515 CET [DEBUG] HttpMethodBase -
 -Execute loop try 1
 2003/11/05 11:16:05:531 CET [DEBUG] wire - - POST
 https://abc.sam.fr:8180/toto HTTP/1.1[\r][\n]
 2003/11/05 11:16:05:531 CET [DEBUG] HttpMethodBase -
 -Adding Host request header
 2003/11/05 11:16:05:546 CET [DEBUG] HttpMethodBase -
 -Default charset used: ISO-8859-1
 2003/11/05 11:16:05:578 CET [DEBUG] wire - -
 application/x-www-form-urlencoded: [\r][\n]
 2003/11/05 11:16:05:593 CET [DEBUG] wire - -
 Proxy-Authorization: Basic c2JuOnNibjI=[\r][\n]
 2003/11/05 11:16:05:593 CET [DEBUG] wire - -
 User-Agent: Jakarta
 Commons-HttpClient/2.0rc2[\r][\n]
 2003/11/05 11:16:05:593 CET [DEBUG] wire - -
 Host:
 abc.sam.fr:8180[\r][\n]
 2003/11/05 11:16:05:593 CET [DEBUG] wire - -
 Proxy-Connection: Keep-Alive[\r][\n]
 2003/11/05 11:16:05:593 CET [DEBUG] wire - -
 Content-Length: 774[\r][\n]
 2003/11/05 11:16:05:593 CET [DEBUG] wire - -
 Content-Type:
 application/x-www-form-urlencoded[\r][\n]
 %% No cached client session
 *** ClientHello, v3.1
 RandomCookie:  GMT: 1051184357 bytes = { [...] }
 Session ID:  {}
 Cipher Suites:  { [...] }
 Compression Methods:  { 0 }
 ***
 [write] MD5 and SHA1 hashes:  len = 59
 : [...]...
 main, WRITE:  SSL v3.1 Handshake, length = 59
 [write] MD5 and SHA1 hashes:  len = 77
 : [...]
 main, WRITE:  SSL v2, contentType = 22, translated
 length = 16310
 
 and... 2 mins later :
 main, SEND SSL v3.1 ALERT:  fatal, description =
 close_notify
 main, WRITE:  SSL v3.1 Alert, length = 2
 
 and the exception :
 javax.net.ssl.SSLException: error while writing to
 socket
   at

com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275)
   at

com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
 
 Note : it only happens if I use a client
 certificate.
 = It's urgent : What can I do ?
 Thanks.
 
 
 
 
  --- Kalnichevski, Oleg
 [EMAIL PROTECTED] a écrit : 
 Samuel, 
  According to the log you are using the development
  version of HttpClient (currently as designated
 2.1).
  I would strongly recommend using the 2.0 branch
  until CVS HEAD stabilizes somewhat. Currently
  authentication logic in CVS HEAD is completely
  broken by one of my recent patches. I am busy
  working on a fix, but it may take a while, as the
  fix is most likely to require changes in the API.
  
  Oleg
  
  -Original Message-
  From: Samuel BONNANFANT [mailto:[EMAIL PROTECTED]
  Sent: Wednesday, November 05, 2003 10:54
  To: [EMAIL PROTECTED]
  Subject: [Https  proxy] Impossible to connect
  
  
  Hi, I'm using HttpClient 2.0 rc2.
  I've got a pbm when trying to connect to a HTTPS
  server (with a client certificate), using a proxy.
  
  I saw the bug #7643 was resolved, but it seems it
  doesn't work with a client certificate.
  
  Can anybody help me ?
  Thanks.
  
  Here are the logs :
  2003/11/05 10:45:06:312 CET [DEBUG]
  HttpMethodDirector
  - -Execute loop try 1
  2003/11/05 10:45:06:421 CET [DEBUG]
  HttpMethodDirector
  - -Preemptively sending default basic credentials
  2003/11/05 10:45:06:453 CET [DEBUG]

Re: [Https proxy] Impossible to connect

2003-11-05 Thread Ortwin Glück

Samuel BONNANFANT wrote:
Do you know other reliable proxy ?
I guess the most widely used one is Squid.

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

RE: [Https proxy] Impossible to connect

2003-11-05 Thread Kalnichevski, Oleg

I would also recommend Squid

http://www.squid-cache.org/

Oleg

-Original Message-
From: Ortwin Glück [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 05, 2003 15:40
To: Commons HttpClient Project
Subject: Re: [Https  proxy] Impossible to connect


Samuel BONNANFANT wrote:
 Do you know other reliable proxy ?

I guess the most widely used one is Squid.


-
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: [Https proxy] Impossible to connect