tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Jacobson <>
Subject Re: DTD for server.xml??
Date Thu, 09 Jan 2003 15:06:27 GMT
Craig R. McClanahan wrote:
> On Wed, 8 Jan 2003, Turner, John wrote:
>>Date: Wed, 8 Jan 2003 11:31:16 -0500
>>From: "Turner, John" <>
>>Reply-To: Tomcat Users List <>
>>To: "''" <>
>>Subject: DTD for server.xml??
>>Hello -
>>I notice that the top of web.xml has:
>><?xml version="1.0" encoding="ISO-8859-1"?>
>><!DOCTYPE web-app
>>     PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
>>     "">
>>yet the top of server.xml has nothing.
>>I'm very new to XML, so forgive me if this is a lame or FA question, but is
>>there a DTD for server.xml?  If so, why isn't it specified in server.xml,
>>and what is the URL?  Is server.xml "real, official XML" or just
>>"convenience" XML?
> There is no DTD for server.xml because there cannot be.
> The problem is that server.xml is extensible -- for example, the set of
> attributes recognized by a <Valve> or <Context> element depends on the
> implementation class of the internal component that corresponds to it.
> The startup process uses Java reflection to match them up to property
> setters on the corresponding beans.  There is no way to express this kind
> of thing in a DTD.
> Your server.xml is (and must be) "well formed" XML.  It just cannot be
> validated.

There may be other good reasons, but this isn't one of them :-)
Here is an extract from my server.xml...
<Logger className="org.apache.catalina.logger.FileLogger"
  prefix="catalina_log." suffix=".txt"

This could be equally well expressed as
<Logger className="org.apache.catalina.logger.FileLogger">

or, more concisely as

<Logger className="org.apache.catalina.logger.FileLogger">
   <property name="prefix" value="catalina_log."/>
   <property name="suffix" value=".txt"/>
   <property name="timestamp" value="true"/>

In both cases, the abstraction of property names allows a DTD to be 
defined that is inherently extensible, and thus would allow an XML 
parser to validate server.xml even if extended by an admin.

Or am I missing something?


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

View raw message