commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [logging] eliminate dependencies on commons-logging [was[beanutils] PROPOSAL: eliminate core dependency on collections
Date Tue, 11 May 2004 21:09:54 GMT
On 11 May 2004, at 21:57, Tomasz Pik wrote:

> robert burrell donkin wrote:
>> On 10 May 2004, at 21:26, Stephen Colebourne wrote:
>>> This looks like a very neat solution to the problem to me. The 
>>> Class.forName
>>> worries me a little though, as I believe that its not too happy in 
>>> class
>>> loaders.
>> it should probably try the context classloader first.
>> note: it is *very* important to remember that beanutils is used 
>> indirectly by a *very* large user base. (think about the user base 
>> for strut and tomcat at the very least.) i'd be *very* likely to veto 
>> any changes that risk breaking a release without adequate time for 
>> testing.
> Hmm, Struts is bad example here because it's already using
> commons-logging ;)

the point i was trying (but failed) to make was that both tomcat and 
struts use beanutils. that's a lot of users.

>> (it took a lot of work to make commons-logging work anywhere near 
>> reasonably in complex container environments.)
> And I'm worry that this will be the same process but code will be split
> across different modules.

i'd definitely agree with that.

that's why the key is keeping the bootstrap code very, very simple. all 
the sophistication needs to be in the LogFactory implementation. this 
may mean generating the bootstrap source from a common template.

> One more note - I don't know how many 'server applications' are not
> using commons-logging, directly or not. Please, take a look at Gump
> email and a list of projects depending on o.a.c.l. All of the projects
> depending on those projects depends on o.a.c.l.
> Also, some recent RIs from Sun using o.a.c.l.
> And for them running 'wrapper' around o.a.c.l will be a waste of
> force.


hopefully it wouldn't be a wrapper, just a bit of dependency magic...

> Also, o.a.c.l is probably the biggest success of Jakarta Commons team
> and I don't think that such solution is the best in the 'marketing'
> terms ('whole world using it so we're going not to use it...').

i'm glad someone appreciates it. we went through (political) hell 
creating it :)

- robert

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

View raw message