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 [mailto:[EMAIL PROTECTED]] Sent: Friday, May 10, 2002 6:07 AM To: [EMAIL PROTECTED] 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 to resist the temptation? TIA, Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
