Costin, This is getting off topic from my original request. (And I am partly responsible ;-)
My proposal is for adding thr XML policy code to the current existing Tomcat 4 HEAD branch. I would like to commit the code to CVS. Building Tomcat with this support is optional and can be left out of the current release builds. The fact that it exists and is experimental can be documented in the security manager HOW-TO documentation along with information on building Tomcat to support this if someone desires to try it out. Other possible changes to Tocmat we started discussing may be better left for discussions of changes to the code base for Tomcat 5. Will that be acceptable? Regards, Glenn Costin Manolache wrote: > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
