commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Resisting the temptation
Date Fri, 10 May 2002 14:29:39 GMT
Hi Ceki,

I can give you a quick solution - use XmlMapper from tomcat3.3.
It's doing the same thing, works with JDK1.1, no external dependencies 
( except IntrospectionUtil - where all the real stuff happens ). It is 
quite optimized and tuned and polished.

The downside: 
- I no longer believe this is the right way to configure
software or deal with XML configuration :-)
- it is less documented than Digester ( however it is similar enough )
- I don't think we'll make too many changes to it - it works too good to 
fix it :-) 

BTW, having log4j depend on commons-logging would be a huge benefit for 
the whole community. I know it may be hard for log4j people, but sometimes 
we must make painfull things. 


On Fri, 10 May 2002, Ceki Gülcü wrote:

> 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: <>

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

View raw message