tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: server.xml DTD/Schema
Date Sun, 02 Dec 2001 23:57:17 GMT


On Fri, 30 Nov 2001, Mika Goeckel wrote:

> Date: Fri, 30 Nov 2001 14:02:01 +0100
> From: Mika Goeckel <mika.goeckel@gmx.de>
> Reply-To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
> To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
> Subject: Re: server.xml DTD/Schema
>
> Craig, yes, that's exactly the problem. Valve is another prominent case
> where the attribute-checking is not possible.
>
> One solution, but I confess that I would not recommend it, is to distinguish
> between the different types, i.e. change <Valve> to
> <AccessLogValve>,<RequestDumperValve>,<RemoteHostFilter> etc. That
would
> certainly make the server.xml validatable, but create the burden of changing
> the xsd/dtd every times a user creates her own Valve/Logger/Realm etc.
>

What if I wanted to add my own custom Valve implementation class?  Doing
this would mean I'd have to modify the code that processes server.xml,
versus the current approach of just sticking your Valve implementation
class in the right place, and adding the <Valve> entry in server.xml.

> Could xslt be a solution to check the required attributes if the dtd/schema
> uses union? Maybe that is to much effort because anyway if a required
> attribute is not present, the digester would moan.

We explicitly turn DTD validation *off* when parsing the server.xml file.
The problem isn't really missing required attributes.  The problem is that

* DTD validation will reject any attribute that is *not* listed
  in the DTD (required or not makes no difference).

* You cannot even identify what the valid set of attributes is
  until runtime, because a Digester Rule implementation can
  dynamically choose whatever implementation class it wants, and
  can push any arbitrary object onto the evaluation stack
  whenever it wants.  The "Set Properties Rule" works by matching
  attribute names against the JavaBeans properties of the top item
  on the evaluation stack, using Java reflection APIs.

Bottom line -- XML validation technology is just not up to supporting the
flexibility supported by the server.xml file.

>
> Mika
>

Craig


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message