Hi Remy, It might be worth COPYING the original web.xml at deployment time, to make a runtime-web.xml, to do what you propose, leaving the original web.xml untouched. This way, you can add the declarations for compiled JSPs, and -- as a bonus -- allow clean modification of things like init-params for servlets, filters, and the context itself. Such modifications could be done in the admin webapp.
If the application is redeployed, or at least if web.xml is modified, then a new copy of web.xml can be made, merging in the modifications made to the older (now obsolete) copy, and of course, the declarations for the compiled JSPs. I'm all for deploying applications as simply as possible, letting end-users customise things from nice graphical interfaces without touching configuration files directly. Many less experienced individuals screw up web.xml when attempting to modify stuff, and it implies unpacking WARs, and looking through lots of "confusing" application structure (where's web.xml? what's xml anyway? why doesn't tomcat start now that I've typed an apostrophie in the servlet's init-param...?) - Chris ----- Original Message ----- From: "Remy Maucherat" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Friday, March 21, 2003 12:05 PM Subject: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs > Hi, > > It is not very convinient or easy to insert the declarations for > compiled JSPs into the webapp's web.xml file. It also has the > disadvantage of adding a lot of mess in the web.xml, which the user may > not like. > > For that reason, I propose that Tomcat parses a new (optional) XML file, > with the same DTD as web.xml, which would contain declarations identical > to web.xml, and which would be used for declaring the compiled JSPs. I > propose naming that file compiledjsp.xml. > > An additional advantage is that it would allow Tomcat to precompile > webapps as they are deployed (otherwise, nasty XML manipulation is > needed to do that, and I think overwriting the originial web.xml during > deployment is bad). > > Maybe someone has a better solution for this problem. Any comments ? > > Remy > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
