commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [logging] make dependency on servlet api optional
Date Sat, 02 Jul 2005 23:51:04 GMT
On Sat, 2005-07-02 at 21:29 +0200, J.Pietschmann wrote:
> Simon Kitching wrote:
> > This is only a *compile-time* dependency.
> > 
> > Currently there is a single utility class provided in the standard
> > logging jar which can be used to avoid memory leaks when using
> > commons-logging in servlet containers.
> > 
> > The presence of the class doesn't do any harm when used in
> > non-servlet-containers; commons-logging will run fine and the class is
> > simply not used.
> There's a recurring problem: projects developing into kitchen-sinks

I don't believe this is the issue here. Commons-logging has a very
definite focus so arbitrary feature growth is not really a danger.

The memory-leak-in-servlet-engine issue is a common problem and does
need to be addressed one way or another. Taking a wild guess, I would
think that perhaps 50% of all uses of commons-logging is in a J2EE or
servlet container, so including this code in core seems reasonable to

> (Damn hard to avoid writing "kitching sink" here :-) ).

I won't comment on this!

> I had to build Apache software from source multiple times for debugging
> purposes, and I don't like to track down all of the obscure compile
> time dependencies. Nor do I like to wait half an hour until all
> dependencies have been fetched from ibiblio or whatever.

Tracking down obscure compile time dependencies is not an issue; they
are all right there on ibiblio. And we can provide an Ant task to
download them.

I guess for people on dial-up connections the download time could be a

> I'd prefer a more modular approach:
> - Split the project (preferred, but not all that easy)
> - Provide several build targets according to dependencies
> - Compile "optional" (non-core, or less likely to be missed) components
>   or features only if libraries they depend on are in the classpath.
>   Issue a warning otherwise: "Component/Feature FooBar not compiled
>   because FooLib not found..."

This is pretty much what commons-logging currently does. So obviously
people share your view.

However it complicates things:
* build.xml harder to read and maintain. For example, if building
  various parts is optional, then all the related unit tests also
  need to be made optional, and run only when the corresponding
  parts are present.
* we need more documentation, and more complex instructions for users.

It has to be remembered that commons-logging is generally something that
people don't deliberately use; it's a dependency that is dragged along
with some other lib that they are really interested in. So people don't
have much interest in reading docs or configuring it correctly.
Commons-logging really needs to work out-of-the-box as much as possible.

And already people moan about having to include commons-logging.jar when
using commons libs like digester or configuration. Providing them with
complex documentation indicating under what circumstances they need to
include additional jars won't make commons-logging more popular.

> Take a look at the FOP build file to see the third approach in action.

Yes, but FOP is quite a different beast from logging. People explicitly
download and use FOP, while people usually get commons-logging as an
accidental side-effect of some other lib.

And commons-logging is only half-a-dozen classes while FOP is -- just a
little bit larger!

Note that I'm not trying to "shoot down" your view. I'm just putting the
opposing case, and we'll see what the consensus is.



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

View raw message