commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [beanutils] remove dependency on commons-logging
Date Tue, 11 May 2004 22:53:23 GMT
Hi Robert,

On Wed, 2004-05-12 at 09:11, robert burrell donkin wrote:
> 1. if we're going to look at logging again, i'd prefer to think about 
> making beanutils a little more easy to use in a managed environment. 
> this means giving more programmatic control over logging.

Can you give some more detail?

My proposal is not a major change to logging; *all* it does is allow
BeanUtils to be used without having commons-logging in the classpath,
and allow BeanUtils releases to promise that they will work with any
commons-logging version that has a LogFactory class with a getLog(String
name) method.

And it does this without any changes to the commons-logging library.

I thought that this was what people wanted, and was what you yourself
suggested in an email a few days ago.

> 2. (for reasons given in a previous mail) i'd prefer it if this goes 
> into a branch rather than the head.
> 3. i'd prefer a service release for downstream developers to solve any 
> possible problems with commons-collections before looking at logging. 
> logging is a very delicate problem. it's crucial that it's quick, 
> simple and robust.
> 4. i'd want to be certain that it'd work with tomcat before any changes 
> to logging went into head.

If you think it better to postpone evaluating this patch until after
BeanUtils1.7 and Digester1.6 are released, then I'm ok with that. I just
thought that as you were putting so much effort into breaking the
BeanUtils->Collections dependency you would also be interested in
breaking the other lib dependency at the same time.

But I would strongly recommend not adding this code on a branch; the
only way to know if it works is for it to be used. Put in trunk, GUMP
will (presumably) run tomcat unit tests using it, struts developers will
use it, etc. As you point out, there are lots of BeanUtils users running
the code with potentially weird classloader setups. Put on a branch,
this testing will never occur and this patch will just wither away (pun

Or we could just drop the concept. It's not something I need personally;
I write java server code, where distributing a few extra libraries with
my apps is not a significant issue.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message