Re: server.xml DTD/Schema
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]
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. 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. Mika - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, November 30, 2001 4:09 AM Subject: Re: server.xml DTD/Schema One thing to remember is that it is not technically possible to write a DTD for server.xml that covers all possible cases (and I suspect that's true for Schema as well). Consider the following cases: * Elements like Logger and Realm let you define which implementation class you want, from the set of choices included with Tomcat. The set of attributes that are valid depends on which implementation class you choose -- and there is no way to make that distinction in a DTD. The best you could do is list the union of all possible attributes -- but that is not semantically valid for any single implementation. * Even more generally, Tomcat users are free to install their own implementations of Tomcat classes, and there's no way your general purpose DTD would know which attributes are valid. Craig McClanahan On Fri, 30 Nov 2001, Mika Goeckel wrote: Date: Fri, 30 Nov 2001 01:01:46 +0100 From: Mika Goeckel [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: server.xml DTD/Schema Hi, I've built a first version of a DTD/Schema for server.xml and would ask if someone would like to review it? I would prefer the Schema, because it allows more checking, but I haven't seen a parser which checks against schemes, so I created a DTD from it as well. As this is quite a bunch of lines, please hands up who wants to receive it. Cheers, Mika P.S.: The initial cut is from the docu, I plan to go through the source tomorrow to recheck. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: server.xml DTD/Schema
A first cut of dtd and schema are reviewable under: http://www.mikagoeckel.de/tomcat/server.html, http://www.mikagoeckel.de/tomcat/server.xsd http://www.mikagoeckel.de/tomcat/server.dtd I've thrown all possible attributes for the different classes into the tag, so this is nothing more than to validate structure of tags. Remember this is a first cut, so validate your server.xml against it and report flaws to me, I'm happy to continue refining it. Comments welcome. P.S.: Who is maintaining the documentation on jakarta.apache.org/tomcat I think the graphics from this work could add some clarity to it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: server.xml DTD/Schema
H I've been too fast with this announcement, I need some help. I've got a problem with Connector (and other cases). I miss a concept like interface in XML Schema. A Connector might be of different types: HTTP/1.1 Connector HTTP/1.1 Connector with SSL support Warp Connector and others might come in the future. All of these three connectors have different attributes, but the XML colloquial definition name all of them simply Connector. There is no way to check for 'required' if we simply just throw all possible attributes in the dtd/schema definition, because some are mutual exclusive. Does anybody have a clue how to solve that? My suggestion would be to clean up the XML and define proper elements for different purposes which might result in some coding work... Mika - Original Message - From: Mika Goeckel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 30, 2001 1:01 AM Subject: server.xml DTD/Schema Hi, I've built a first version of a DTD/Schema for server.xml and would ask if someone would like to review it? I would prefer the Schema, because it allows more checking, but I haven't seen a parser which checks against schemes, so I created a DTD from it as well. As this is quite a bunch of lines, please hands up who wants to receive it. Cheers, Mika P.S.: The initial cut is from the docu, I plan to go through the source tomorrow to recheck. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: server.xml DTD/Schema
One thing to remember is that it is not technically possible to write a DTD for server.xml that covers all possible cases (and I suspect that's true for Schema as well). Consider the following cases: * Elements like Logger and Realm let you define which implementation class you want, from the set of choices included with Tomcat. The set of attributes that are valid depends on which implementation class you choose -- and there is no way to make that distinction in a DTD. The best you could do is list the union of all possible attributes -- but that is not semantically valid for any single implementation. * Even more generally, Tomcat users are free to install their own implementations of Tomcat classes, and there's no way your general purpose DTD would know which attributes are valid. Craig McClanahan On Fri, 30 Nov 2001, Mika Goeckel wrote: Date: Fri, 30 Nov 2001 01:01:46 +0100 From: Mika Goeckel [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: server.xml DTD/Schema Hi, I've built a first version of a DTD/Schema for server.xml and would ask if someone would like to review it? I would prefer the Schema, because it allows more checking, but I haven't seen a parser which checks against schemes, so I created a DTD from it as well. As this is quite a bunch of lines, please hands up who wants to receive it. Cheers, Mika P.S.: The initial cut is from the docu, I plan to go through the source tomorrow to recheck. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
