On Fri, 26 Oct 2001, Gunther Birznieks wrote: > I don't consider either of these solutions very > automatic.
you're right. the point is bundling of apps into discrete units with consistent internal structures and configuration mechanisms. anyway, the issue of war files is only one of the planks in the webapp specification platform. > 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. what problems do you have with images that can't be solved by simple <FilesMatch> type rules in httpd.conf? that's the recommended practice with tomcat. configuring database connections is pretty cake actually. one of the specs, servlet or j2ee, makes it mandatory for servlet containers to support database connections (maybe pooling too?) as resources that are configured in server.xml. other types are mandated as well. again, as a webapp developer, it's pretty great to never have to think about connecting, disconnecting, or managing pools; or even initializing other components that do it. the deployer specifies a jdbc url in server.xml and wham it all jfws. i'm not exactly sure what you meant by your third example. > 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. which ones are those? > 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. :) fair enough! war files are really a minor part of the servlet spec, there are many more important points.
