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 16:57:15 GMT
On Fri, 10 May 2002, Ceki Gülcü wrote:

> The down side is that jakarta would have two actively supported digesters,
> the one in commons and the one in log4j resulting in significant maintenance
> effort being wasted.

I wouldn't say XmlMapper is 'actively' supported - the code is frozen, it
does what it is supposed to do, last bug was ages ago, the performance
is good ( at least for tomcat configuration, it's no longer a 'visible'
factor ). If you can use it as is - great, if not problably it's not the 
right starting point.

> >The downside:
> >- I no longer believe this is the right way to configure
> >software or deal with XML configuration :-)
> Aaaah? Can you please expand on this?

There are few major problems:

- reading the XML file is not enough. Log4j (for example) supports JMX, 
and that means it should be able to be confiured at runtime. You need to 
be able to persist the changes - and in the process preserve the 
structure, comments and all the elements in the config file. 

- scalability. What if you have a distributed application, with hundreds 
of computers in a 'farm'. You could use some scripts to copy the xml file 
on all computers, but I think it's better to be able to use LDAP or 
NDS or another directory service, which scales much better. 

- integration. While configuring the logger may be the center of the 
universe for log4j, most applications have dozens of components to be 
configured, and not enough time to learn the syntax of each component. 
Don't make the mistake of believing that you have a standard syntax with 

Plus the fact that you end up with dozens of xml files in various 
locations. You can't combine them with namespaces - because you may have 
to write and you can only write your own piece.

I think a 'preferences' API is the only sane solution. But unfortunately 
Sun again bundled util.prefs with JDK1.4 and that means it's practically 
unusable. And JNDI is far too complex for this.

A clone of util.prefs that can be used in any VM is ( IMHO ) the best 

> >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.
> What would be the benefit of log4j depending on commons-logging to the
> community? All I tend to see is more complicated bug reports and more
> confusion on the user side. (I am afraid we have had this debate already.)

A common logging API is the benfit. Yes, things may be more complicated
and we may get more bugs - but using a single API for logging is worth it.
You can incorporate commons-logging in the log4j distribution ( like 
xalan/xerces are doing with jaxp ), even in the same jar ( and make sure
log4j is the default - for example by including only the log4j factory ).


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

View raw message