Glenn Nielsen wrote: > 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?
As I said, I think you need 3 +1 votes. And I strongly disagree with adding more complexity to the xml processing. I don't mind castor - but adding yet-another piece in the puzzle. I'm also not sure about 4 HEAD - tomcat4.1 is stable, and this would be a big change ( i.e. change of config format ). IMO that would require a 4.2 bump ( but most people agreed that the next step will be 5.0 ). If you want, create a proposal/ subdir and put it there. When it's no longer experimental you can reopen the issue. But integration with the rest of tomcat configuration is pretty important. That's my opinion - and aparently Remy expressed some concerns as well. You still need few +1 votes. Costin > > 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]> -- Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
