commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Waldhoff, Rodney" <rwald...@us.britannica.com>
Subject RE: Resisting the temptation
Date Fri, 10 May 2002 14:34:04 GMT
> [Concern] 3) Circular dependencies. Log4j depends on commons-digester,
which
> 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



> [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
(org.apache.commons.logging.*)
commons-logging-log4j.jar := the log4j implementation
(org.apache.commons.logging.impl.Log4J*)
commons-logging-logkit.jar := the logkit implementation
(org.apache.commons.logging.impl.LogKit*)
commons-logging-jdk14.jar := the merlin implementation
(org.apache.commons.logging.impl.Jdk14*)

etc. 

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.

Is that the solution that is unacceptable to the log4j team?  If so, can you
clarify why this is?

- Rod

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message