You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Deacon Marcus <de...@wwtech.pl> on 2001/09/05 02:23:39 UTC

Tomcat logging and xml

Hi,
I was wondering, why Tomcat isn't using JDOM and/or Log4j? They're great
APIs, much clearer than what's used currently.

Greetings, deacon Marcus


Re: Tomcat logging and xml

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Wed, 5 Sep 2001, Deacon Marcus wrote:

> Date: Wed, 5 Sep 2001 02:23:39 +0200
> From: Deacon Marcus <de...@wwtech.pl>
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org
> Subject: Tomcat logging and xml
>
> Hi,
> I was wondering, why Tomcat isn't using JDOM and/or Log4j? They're great
> APIs, much clearer than what's used currently.
>
> Greetings, deacon Marcus
>
>

I can give you some personal thoughts, relevant only to Tomcat 4.x
development:

Regarding JDOM:

* JDOM is not a stable API yet.  It seems unwise to me to commit to
  an API that is still subject to change when we're trying to release
  a stable container soon.

* The amount of XML processing done within Tomcat itself is pretty
  small, so using JDOM wouldn't add much value:

  - Parsing web.xml and server.xml files is done with XmlMapper, which
    is a nice wrapper around SAX events.  This seems quite sufficient.

  - Parsing JSP pages in XML syntax might benefit from some sort of a
    DOM view of the world, but this is a pretty major change -- and only
    seems worthwhile in the context of an optimizing compiler that will
    go scan the tree and modify it prior to code generation.

* JDOM isn't the only DOM-like API gaining popularity -- DOM4J seems to be
  gaining mindshare as well.  Choosing one or the other will need some
  careful comparisons.

Regarding Log4J:

* The existing model of logging in Tomcat 4 (where you can override
  loggers at the context or host level) does not map very well to Log4J's
  "category" concept, although (as Ceki has pointed out) it is feasible
  to establish such a mapping that at least works.

* I don't care for the performance impact of the programming approach
  that lets the logger decide to throw away a log message that is not
  wanted *after* the component has paid the performance penalty for doing
  all the string concatenations in a typical log message.  There's a way
  around this (seeing if debug is enabled, for example), but it is *much*
  more cumbersome to type than the current "if (debug >= 1)" type tests.

* Overall, migrating to Log4J is something worth considering in a
  Tomcat 4.1 time frame, but it's medium-to-low on my personal priority
  list.

None of the above, of course, has anything to do with the use of JDOM
and/or LOG4J in web applications that run on top of Tomcat.  They are free
to do whatever they want.

Craig