commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: Resisting the temptation
Date Mon, 13 May 2002 20:59:28 GMT
At 09:57 10.05.2002 -0700, costinm@covalent.net wrote:
> > >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
>XML.

Right, XML does not give you a standard syntax. Nevertheless, XML
gives you a standard and powerful syntax for expressing information,
in this case configuration information. XML is much more expressive
than key=value files.

Isn't the *location* of XML files completely orthogonal to the issue
of XML file *contents*? On the other hand, the prefs API seems to give
you a reasonable way to express data and at the same time manage its
persistence. By the way, thanks for sharing your perspective which has
been quite thought provoking.

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

If Sun's goal is to have people follow them, then they did the right
thing, at least from their stand point.

>A clone of util.prefs that can be used in any VM is ( IMHO ) the best
>solution.
>
> > >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 ).

With your permission, I'd like to avoid answering this one.

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