commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Resisting the temptation
Date Fri, 10 May 2002 13:06:32 GMT

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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message