Glenn Nielsen wrote: > This code only does validation when the container is started or > when a web application context is reloaded. The current implementation > using the standard policy file does the same thing only not with XML.
??? Doing XML schema validation on each server start and webapp reload is what I disagree with. I think the config/deploy tools should use schema and validate as much as they wish - but at runtime it shouldn't be done ( except maybe once and on file change ) That applies to web.xml, tlds and any other xml file. > My only point is that the current policy is to bundle everything in > the Tomcat releases and not provide downloads for separate add on > modules. We can discuss whether we want to change that policy. We don't 'bundle everything' - there are some features that were aproved at some point. But I don't know of any policy of 'bundle everything'. We could create a 'tomcat+everything' distribution ( i.e. struts, velocity, axis, apache-soap, and so on ) - and it may be usefull. But a lot of people would like a smaller 'core' and more features moved in separate modules. In particular, for your policy.xml - that's much more 'core' than webdav for example. And if it is integrated with the rest of the config - and everyone agrees that it's better to use the XML ( with a JMX/JNDI wrapper to integrate into the admin app ) - then we should deprecate the use of the old policy file. >> - castor use. I like castor - and if a proposal is made to use >> castor in all xml processing, I may be +0. But I'm strongly -1 >> on using castor for policy, digester for server.xml and DOM for >> jasper. >> > > I agree with you in principal. From having worked with the code > in Tomcat which uses the digester and the code which the admin > application uses for marshalling XML, the current Tomcat 4 code > for configuration management looks very "brute force". I have > been thinking about how the current code works and whether > Castor would be a much simpler solution. If everyone agrees castor is a better solution - then we should use it. But we should do it consistently. The current proposal is to use a JNDI frontent ( and abstract XML out - i.e. support directory servers and other storages ). That means the current direct XML reading/writing will be changed. >> - DTD - what are jboss or j2ee using for policy ? What other >> DTDs are in use for this ? XML is just a file format, if >> everyone uses a different DTD we're in a mess. >> > > I very much doubt if any servlet/J2EE containers use the same > configuration methods. This is something the specs leave up to > the individual implementation. The whole value of XML is on commons DTDs and schemas. WEB.XML is such a standard - and each container supports it. In many cases it is impossible to get a standard DTD ( server.xml for example ). But for policy ( or the xml used in modeler ) - there are enough common things. If j2ee or jboss or some other app is using an xml policy file - I see no reason why we couldn't use the same DTD but invent our own. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
