On Fri, 30 Nov 2001, Mika Goeckel wrote:
> Date: Fri, 30 Nov 2001 14:02:01 +0100
> From: Mika Goeckel <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
