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 me. > (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 nuisance. > > 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. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
