On 17/05/2010 18:14, peter_f...@blm.gov wrote: > Pid <p...@pidster.com> wrote on 05/17/2010 10:55:06 AM: > >> On 17/05/2010 17:48, peter_f...@blm.gov wrote: >>> To clarify what I'm up to here - we have an in-house doc that suggests >>> switching off autoDeploy and deployOnStartup on production systems, and >> >> Does it explain why it makes this suggestion? > > To prevent someone accidentally (or otherwise, of course) deploying an > application in a production system simply by dropping in a WAR. > >> >>> I've been testing those recommendations on an experimental setup. What > the >>> in-house doc forgets to say is what you've explained here (and which >>> answers my original question - thanks!) which is that you have to put a >>> Context element into the server.xml to make it work. >> >> Which is explicity discouraged in current versions of Tomcat. > > Yes, but in a fixed production setting it makes sense. At least in that > setting you'd have to be able to edit server.xml, which is not something > you're going to do by accident.
With the right settings, you'd still need to restart the server, even if someone had managed to accidentally update the war files. Seems a little paranoid, but hey... p > Pete > >> >> >> p >> >>> I need to get our doc corrected. >>> >>> Problem solved. Thanks all. >>> >>> Pete >>> >>> Mark Thomas <ma...@apache.org> wrote on 05/17/2010 10:38:11 AM: >>> >>>> On 17/05/2010 17:33, peter_f...@blm.gov wrote: >>>>> Mark Thomas <ma...@apache.org> wrote on 05/17/2010 10:12:20 AM: >>>>>> Not pointless. It limits deployed apps to *only* those defined in >>>>>> server.xml. >>>>> >>>>> Ok - so if I want my app to start I have to place the context element >>> in >>>>> server.xml. I would have thought that an external context.xml would >>> have >>>>> the same effect (I thought that was the point) but I'm not seeing > that >>>>> happen; maybe got something wrong in that file. >>>> >>>> No. context.xml files are deployed via the auto-deploy process so they >>>> need deployOnStartup or autoDeploy to be true. When I wrote "*only* >>>> those defined in server.xml" that is exactly what I meant. >>>> >>>>>> That is plain wrong. autoDeployment /deployOnStartup do play a role > in >>>>>> double-deployment but only when your configuration is wrong to start >>>>> with. >>>>> >>>>> Well, I guess I'll just have to be careful with my configuration :) >>>>> (seriously, unless I missed it in the documentation it wasn't clear > on >>>>> double-deployment as a consequence of bad config.) >>>> >>>> Explicit definition in server.xml + autoDeploy == double deployment. >>>> I'll add a few words to the docs to try and clarify that. >>>> >>>> Mark >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >> >> >> [attachment "signature.asc" deleted by Peter Ford/NOC/BLM/DOI] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
signature.asc
Description: OpenPGP digital signature
