Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 29115 invoked from network); 10 May 2002 14:34:25 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 10 May 2002 14:34:25 -0000 Received: (qmail 9818 invoked by uid 97); 10 May 2002 14:34:19 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 9691 invoked by uid 97); 10 May 2002 14:34:18 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 9642 invoked by uid 98); 10 May 2002 14:34:18 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <921E60ADEB30D84EACA350AD31A1FD7506E4E9@chiex02.britannica.net> From: "Waldhoff, Rodney" To: 'Jakarta Commons Developers List' Subject: RE: Resisting the temptation Date: Fri, 10 May 2002 09:34:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F82F.BBF93F70" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ------_=_NextPart_001_01C1F82F.BBF93F70 Content-Type: text/plain; charset="iso-8859-1" > [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 ------_=_NextPart_001_01C1F82F.BBF93F70--