commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Smuts" <aaron.smu...@verizon.net>
Subject RE: [Logging] [VOTE] Commons Logging 1.0 Release
Date Mon, 04 Feb 2002 04:23:43 GMT
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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message