You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ricky Leung <ri...@booksense.com> on 2002/06/11 19:27:27 UTC

server.xml dtd

I can't find the dtd anywhere and the documentation area only gives the
explanation and not the order of the attributes and my guess is that the
ordering is a must.  Could someone point me to where the dtd where
server.xml uses so I can just look it up myself?

Thanks,
Ricky


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: server.xml dtd

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

On Tue, 11 Jun 2002, Ricky Leung wrote:

> Date: Tue, 11 Jun 2002 13:27:27 -0400
> From: Ricky Leung <ri...@booksense.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: server.xml dtd
>
> I can't find the dtd anywhere and the documentation area only gives the
> explanation and not the order of the attributes and my guess is that the
> ordering is a must.

Ordering of attributes is *never* relevant, in server.xml or any other XML
document, unless you are using some really insane XML parser that actually
cares.  If you're using JAXP (as Tomcat does when parsing these things),
you get all the attribute values as what amounts to a Hashtable keyed by
attribute name, so you cannot tell what the original order was.

Ordering of elements is required (by the DTD) in web.xml, but not in
server.xml -- in general, ordering does not matter unless the objects you
are configuring depend on it.  However, correct *nesting* of elements is
absolutely critical.

>  Could someone point me to where the dtd where
> server.xml uses so I can just look it up myself?
>

There is no such DTD, and there never can be -- the set of possible object
implementation classes (and therefore the set of configuration properties
that are supported) is infinite.  For example, there is no way to define
the list of all possible attribute names for all possible <Valve>
implementations that anyone in the world might create.

Beyond this, nothing stops you from using extra elements that Tomcat does
not recognize, and parsing server.xml yourself.  As long as you
don't introduce any new nesting levels, Tomcat will simply ignore
these elements, because they don't match the patterns it is looking for.

> Thanks,
> Ricky
>

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>