commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <>
Subject RE: Resisting the temptation
Date Fri, 10 May 2002 15:07:30 GMT
At 09:34 10.05.2002 -0500, you wrote:
> > [Concern] 3) Circular dependencies. Log4j depends on commons-digester,
> > depends on commons-logging which depends on log4j.
>Why not split the commons-logging interface from the specific
>implementations, for example, by moving the log4j implementation of
>commons-logging into log4j itself?
>Ceki, is this what you meant by:
> > [Solution] 2) log4j accepts to depend on commons-logging [but this] is not
>acceptable to the log4j community

No, that is not what I meant. The dependency I am talking about is more
abstract. More precisely, if log4j depends on commons-logging for its
configuration, then it if something goes wrong, the more dependencies you
have the longer it takes longer isolate the problem. I do not wish to deal
with bug reports that take a day to solve. I want users to be able to install
log4j and have it work in half an hour and if it doesn't they should be able
to identify the problem by themselves.

I'll be the first to admit that my reaction is a variant of NIH. Maybe 
there would
be a way for log4j to override commons-logging's search mechanism and force
c-l to use log4j as the underlying implementation. C-l changed quite a bit 
since I
last looked at it. Before continuing with more talk, I'll now take the time 
to study
it. I'll get back to this discussion later.

> > [Solution] 3) some new innovative approach...
>Alternatively, we could split the various commons-logging implementations
>out into separate trees and/or jars, giving something like:
>commons-logging-core.jar := the abstraction itself
>commons-logging-log4j.jar := the log4j implementation
>commons-logging-logkit.jar := the logkit implementation
>commons-logging-jdk14.jar := the merlin implementation
>That should remove compile-time circular dependencies, but it'll obviously
>increase the number of JARs one might be concerned with.
>Moving the Log4JCategoryLog and Log4JFactory into log4j itself (perhaps in a
>separate jar?) seems like the cleanest solution to me.  If you want/need
>them, then you'll have the log4j JARs around anyway, and we're left with the
>same number of JARs but no circularity.

I am currently not in a position to grasp the implications of this approach. It
sounds reasonable but I'll have to look at c-l code more carefully before 
a definitive answer.


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

View raw message