Endre Stølsvik wrote:
> On Wed, 24 Jan 2001, Craig R. McClanahan wrote:
>
> | Try to write the DTD entry for a <RequestInterceptor> element (Tomcat 3.2) or a
> | <Valve> element (Tomcat 4.0) and you will see what I mean. In either case, the
>Java
> | class that gets instantiated can be *anything*, with any set of JavaBeans
>properties.
> | The initialization logic uses Java reflection to match up XML attributes to
>JavaBeans
> | property names at runtime, in the same way that the following JSP statement works:
> |
> | <jsp:setProperty name="beanname" property="*"/>
> |
> | Since the set of all possible meaningful property names is infinite, it *cannot* be
> | enumerated in a DTD, which requires you to list *all* valid attributes of every
> | element.
>
> Isn't the attribute here the "name" and "property", NOT the "beanname" and
> "*"? If so, couldn't you write a DTD for that? A "setProperty" element can
> have to attributes, "name" and "property". You could also have several
> parameters, like <parameter name="some" value="thing" />, there's room for
> that in DTDs?
>
> If that is true, you could validate all the required elements in a
> requestInterceptor (or whatever, I have no clue here), but leave the
> other, introspected stuff, for those <parameter />'s
>
Yes ... you can definitely change the "language" that Tomcat understands such
that a DTD
could be written. That requires changes to Tomcat itself (and *much* more
verbose
server.xml files, which I'm not a huge fan of) -- patches are welcome if someone
wants to
go this direction.
My contention was, and remains, that you cannot write a DTD that covers the
*current*
server.xml language that Tomcat accepts.
>
> --
> Mvh,
> Endre
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
