tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Slightly OT: log4j - generic log4j.dtd
Date Fri, 01 May 2009 17:48:55 GMT
Hash: SHA1


On 4/30/2009 11:43 AM, Gregor Schneider wrote:
> <?xml version="1.0" encoding="UTF-8" ?>
> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

Is there a PUBLIC definition, too? IIRC, most XML parsers can use the
PUBLIC part to look up the DTD in their cache, as Peter suggests. I have
no idea how to prime the cache, though.

> Because every bloody servlet needs it's very own log4j.dtd together
> with it's log4j.xml, which is why I'm looking for a smarter solution.

Did you mean every webapp or every servlet? I suspect the former.

> However, with log4j.dtd things are slightly different since it's
> always a file with the same content and I really dislike redundancies.

How about using a fully-qualified SYSTEM identifier? It could be local
(using a file: URL) or remote (http:)?

> So my idea was to use ${CATALINA_HOME}, pass this via "-Dlog4j.dtd as
> a Java-property to Tomcat and evaluate this property within log4j.xml,
> however, that does not seem to work:

While this sounds like a great idea, I believe neither log4j nor your
XML parser will choose to auto-replace ${foo} with the result of
System.getProperty("foo"). I'd think you'd have to do that yourself.

> log4j:ERROR Could not parse url
> [file:/home/tomcat/www/common/classes/log4j.xml].
> no protocol: ${log4j.dtd}
>     at<init>(
>     at<init>(

Another Gregor suggested that the replacement happens but the file: URL
is not recognized. Both assertions are false. The replacement obviously
did *not* happen.

> I do [know] that I can pass a URL, so basically some thing like
> <!DOCTYPE log4j:configuration SYSTEM "http://localhost/mylog4jconf/log4j.dtd">
> should work, but I don't like the idea that I have some directory just
> containg some configuration-files which is accessible via http.

Gotcha. It's also kinda silly to fetch a remote file unless it's
absolutely necessary.

> Server version: Apache Tomcat/5.5.17


> Architecture:   i386

Really? Not i686? Hm...

I'll toss a suggestion out there that I use all the time: ant. I use ant
for WAR building and local deployment (i.e. not using the 'manager'
app), and I use the <copy> tool along with replacements enabled. I even
use it for log4j (in order to target my log files into
${CATALINA_BASE}/logs). Here's what I do: (haven't bothered to use XML yet) contains this line:

log4j.appender.A1.file = @app-log-dir@/log4j.log

I use ant to replace @app-log-dir@ with my actual log directory like this:

    .. lots of other filters ...
    <filter token="app-log-dir" value="${app.log.dir}" />
    <copy toDir="${build.classes.dir}"
      <fileset dir="${properties.dir}">
            <patternset refid="properties-shallow.file.pattern" />
            <patternset refid="xml-shallow.file.pattern" />
      <fileset dir="${properties.dir}/${app.release-type}">
            <patternset refid="properties-shallow.file.pattern" />
            <patternset refid="xml-shallow.file.pattern" />

This results in copying to my build/classes directory
(which ultimately turns into WEB-INF/classes) and applying a string
replacement to replace the text "@app-log-dir@" (the @ symbols are part
of the replacement mechanism and aren't mentioned in the build.xml file)
to replace it with the value of the ${app.log.dir} property which, I
promise, points to "${CATALINA_BASE}/logs".

I'm not sure if this will fit into your deployment model, but it works
exceedingly well for ours.

- -chris
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


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

View raw message