On Fri, 26 Oct 2001, Gunther Birznieks wrote: > 1) if you develop an application at home with some > config describing the database connection parameters in > the web.xml file in WEB-INF, then you jar up the WAR > File and send it to your client, they will still need to > edit the web.xml to change the username and password. > > Each time you give the client the new war file, it will > also overwrite the change they made to web.xml saying > that the JDBC connection info was.
this is one benefit of using tomcat. you can specify servlet context parameters in server.xml as well as in web.xml. so you can distribute a set of defaults in web.xml and then allow the deployer to override them in server.xml. > 2) The main nice thing about war files is that images > and HTML related to an application can also be stored > with the application. > > However, this too is not all that it's cracked up to be. > Servlet Engines are much slower at deliverying image > data than the native web server (netscape or apache), so > you would never in production really have the client > want to keep the images with the servlet. again, tomcat handles this well. you can have it unpack the war file, and you can then use standard apache configuration mechanisms to direct apache to serve the static resources.
