commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <>
Subject RE: [Logging] [VOTE] Commons Logging 1.0 Release
Date Mon, 04 Feb 2002 12:00:53 GMT
Aaron, you just touched on what is the usefulness of the commons.

The idea is that the Tomcat team and other teams with _common_ use
code can drop such _common_ use components here, and hence the
_commons_ name.

Of course that dropping such components here also means making them
usable without depending on the mother project.

Have fun,

> -----Original Message-----
> From: Aaron Smuts []
> Sent: Monday, February 04, 2002 5:24 AM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [Logging] [VOTE] Commons Logging 1.0 Release
> It doesn't sound like there is a clear dependency chain among the
> projects.
> In JCS I've had a hell of a time trying to use utilities from Tomcat,
> since they seem to move around.  Maybe I just shouldn't have been using
> them.  Outside of Jakarta this would be fine, since I can control the
> release version of 3rd party libraries, but inside it is more difficult.
> This is a difficult problem.  You seem to have to stick to a project's
> high level API or intended usage.  I can use Tomcat as a servlet engine,
> but not as a source of thread pool utility classes.
> When trying to use utilities, say the log4j configuration code or the
> Tomcat thread pool, you have to pretty much copy and modify the code
> (making appropriate citations to the source) and go on.  I'm not sure
> how to solve this.  In my own projects I define a dependency hierarchy
> and make sure that no one violates the chain.  If commons becomes the
> base then it will probably end up bloating and being filled with
> redundant code and version with number in the names of classes . . .
> Every committer will need commons commit access so they can keep all
> their utilities that might be attractive to another project accessible
> and stable, or there will need to be a common acceptance to giving code
> a new home (my technique) to reduce the dependency complexity.
> For instance: JCS has a great indexed disk storage system, but I
> wouldn't try to use it outside of the JCS framework, since it is subject
> to change, but it has a much broader utility.
> Many of the log4j appenders are like this.   In JCS I used some of the
> socket appender code for a TCP lateral cache.  If they could be
> abstracted out into commons utilities they would be very useful, but
> this would require building with added flexibility and wrappers. . . .
> This is a tough problem.
> Cheers,
> Aaron
> --
> To unsubscribe, e-mail:
For additional commands, e-mail:

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

View raw message