Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 49191 invoked from network); 10 May 2002 13:06:39 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 10 May 2002 13:06:39 -0000 Received: (qmail 9331 invoked by uid 97); 10 May 2002 13:06:38 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 9293 invoked by uid 97); 10 May 2002 13:06:37 -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 9279 invoked by uid 98); 10 May 2002 13:06:37 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-Id: <5.1.0.14.0.20020510145949.016e9988@mail.qos.ch> X-Sender: ceki@mail.qos.ch X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 10 May 2002 15:06:32 +0200 To: commons-dev@jakarta.apache.org From: Ceki =?iso-8859-1?Q?G=FClc=FC?= Subject: Resisting the temptation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Greetings to all, As most of you are probably aware, log4j version 1.2 final was released just a few hours ago. One of the important planned new features of log4j 1.3 is the capability to interpret configuration files (in XML) with tags that were unknown at compile time. In other words, we would like log4j to be able to learn about new tags dynamically. This probably similar to ANT's capability of learning new tasks. The commons-digester library offers the infrastructure to support such capability. In short, I think commons-digester has what log4j needs. However, commons-digester requires commons-collections, commons-beanutils and commons-logging. Here is short list of concerns in increasing order of importance: 1) That's log4j.jar plus 4 jars instead of just log4j.jar. 2) Commons-xxx depends on JDK 1.2 where as log4j runs with JDK 1.1. 3) Circular dependencies. Log4j depends on commons-digester, which depends on commons-logging which depends on log4j. Given this seemingly intractable concerns, I have asked Costin Manolache, Craig McClanahan and Scott Sanders to borrow the commons-digester code. They all graciously granted permission for the modification of their code and its inclusion in log4j. So what's problem you might ask? Well, it seems rather wasteful to start a new code base while a perfectly good one exists already. In other words, I am trying to resist the urge to start all over again. Concern number 1), that is the increase in the number of jars, is a fact of (modular) life. As for concern 2), log4j can enforce that the extensible configuration capability requires JDK 1.2 while the rest remains JDK 1.1 compatible. Concern 3) is the one I find most challenging. There are 3 possible approaches: 1) commons-digester et al. drop the requirement for commons-logging. 2) log4j accepts to depend on commons-logging 3) some new innovative approach... Solution 1) is probably not acceptable to the commons community. Solution 2 is not acceptable to the log4j community. Solution 3 requires a fresh approach. Can you please help us find a solution in order to resist the temptation? TIA, Ceki -- To unsubscribe, e-mail: For additional commands, e-mail: