Hi, It's a long time I want to ask a question but I was always afraid to ask. Very often I see that some of you strongly discourage using the server.xml for context elements, in favour of storing them in separate xml within subdirectories of the conf directory.
Unfortunately I need to put contexts in the server.xml file, for a couple of reasons, so I hope this will not become a deprecated feature (otherwise I will be in trouble). The reasons for my choice are the following: 1- As stated in the docs, the main reason why you shouldn't use the server.xml file is because you can't activate the new settings without restarting Tomcat. Well, as I use Windows I have no alternatives as I experience file locking issues - and there are other problems with antiResourceLocking I won't mention (unless asked). But - since I have no problems with Tomcat restarts - I have no reason why not to put contexts in the server.xml file, according to official documentation. 2 - I need to keep control on what is placed in the webapps directory by developers, on dev/test/prod machines. I need to decide the context path myself, so I had no other choice than disable autoDeploy. 3 - The same applies to the deployOnStartup setting - that by the way has a misleading name. It should be named autoDeployOnStartup, as it does not distinguish between what wars or directories it finds by chance in the webapps directory and what is placed on purpose under /conf/catilina/etc. By putting contexts into the server.xml file I can actually decide what to deploy as opposed to blindly deploy whatever is found in the webapps directory. Contexts under /conf/catilina/etc. don't deploy without deployOnStartup while contexts into server.xml do. There is no other way of allowing the behaviour I need without using the server.xml file for contexts. Is there an alternative or can I keep using server.xml for contexts? Thank you in advance, b. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
