tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: server.xml
Date Fri, 23 Jun 2000 16:57:11 GMT
Manie Coetzee wrote:

> Hi
>
> Does anybody know where I can find a complete and documented
> DTD for the server.xml file?  There is documentation on what certain
> tags mean; what I am interested in is the formal document that describes
>
> the server.xml file.
>

There is no complete server.dtd (and never can be), because the syntax of
this file is extensible.  Let me explain a little further.

The "conf/server.xml" file is processed in Tomcat's startup code (class
org.apache.tomcat.startup.Tomcat), by using a utility class called XmlMapper
to apply a bunch of rules that the program defines when it sees particular
patterns of nested XML elements.  For example, when the startup code sees a
<Logger> element nested inside a <Server> element, it performs the following
tasks:

* Create a new object of class org.apache.tomcat.logging.TomcatLogger
  (there are options on many XML elements to plug in your own class name
  here as well).  This object is pushed onto a stack maintained by the
  XmlMapper object.

* Match up the attributes on the <Logger> element against the JavaBeans
  property names of the object at the top of the stack (the TomcatLogger
  that was just created in this case), and calls all the property setter
methods
  that match.  Note that this means you cannot predict -- in a server.dtd --

  what attribute names are legal.  It depends on the object you are
creating.

* Calls the "addChild" method of the object one level down on the stack
(which
  happens to be the Tomcat startup code itself), passing the object at the
top
  of the stack (the logger) as an argument.

This approach is incredibly flexible, because the semantics is defined
solely by what the program parsing this file looks for -- the XML elements
that don't match the defined patterns are simply ignored, and the attribute
names are totally up to the objects you create.  Thus, the DTD syntax is not
powerful enough to capture what things are legal and what things are not
legal, and you cannot use a validating XML parser to read this file.

But shouldn't the "standard" tags and their options be documented anyway?
Absolutely!  Any volunteers?


> Manie Coetzee

Craig McClanahan




Mime
View raw message