commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Cook <>
Subject RE: Resisting the temptation
Date Fri, 10 May 2002 16:57:15 GMT
Just a though from left field, but why not change log4j to be an interface
and use a factory to generate the trace instances.  While my company had
standardized on the use of log4j, we had cases where it was not desireable
to distribute the log4j.jar file.  

To get around the problem we created an interface that exposed most of the
tracing functionality, then created a wrapper for log4j that implemented
the interface.  We also create a skeleton implementation that just passed
all tracing calls through to a basic System.out.println() call.  Classes 
use a factory to get the trace instance. The factory tests for the 
existance of the log4j based class and if it is not available, creates an 
instance of the skeleton implemenaton. If an interface was used, the 
implementation and its dependancies become less important.   

-----Original Message-----
From: Ceki Gulcu []
Sent: Friday, May 10, 2002 6:07 AM
Subject: Resisting the temptation

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
resist the temptation?

TIA, Ceki

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

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

View raw message