At 11:38 AM 10/26/2001, brian moseley wrote: >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.
I don't consider either of these solutions very automatic. I guess I just don't see why a war file is all that much easier than a tar ball that you can unzip or an rpm that can be installed via a set of rules or makemaker CPAN style installation of an app. It's all basically about the same. It's nice that there is a standard, but it's a thinly veiled luxury that in practice still doesn't solve the major headaches of deployment -- dealing with ancillary resource files such as images, database connections, and setting up other servers such as creating the database schema in the first place. I approach this from a perspective that we've been giving out tarball web apps for 8 years and if you untar an application of ours, to make it use database etcs... you'd have to do all the same things you'd have to do if we deployed as a warfile instead of a tarball. I apologize for being so skeptical. It's just that as I deal with installing custom web apps constantly in different servlet environments and I do it with war files, I have not seen my workload really go down that much. And the hard deployment problems are still largely unsolved in J2EE so we shouldn't just follow J2EE blindly for this. So all I am saying is that in the case of warfiles that the Emporer isn't wearing very much... although I would acknowledge that he isn't entirely naked. :)
