See intermixed.
----- Original Message ----- From: "Ignacio J. Ortega" <[EMAIL PROTECTED]> To: "'Tomcat Developers List'" <[EMAIL PROTECTED]> Sent: Wednesday, June 26, 2002 12:33 PM Subject: RE: [JK2] Trying 4.1.3 Beta + IIS > > De: Chris Brown [mailto:[EMAIL PROTECTED]] > > Enviado el: 26 de junio de 2002 9:53 > > > Should connectors to IIS and Apache behave differently > > according to whether > > a webapp is deployed as a WAR file or as an uncompressed set > > of files on the > > disk? When the webapp is deployed "uncompressed", it should > > be easy enough > > to find the static files to server, but when it's an unpacked > > WAR file, it's > > unlikely IIS et al know how to read from the WAR file > > directly, or locate > > the temporary folder into which WAR file contents are > > unpacked (so that it > > can find static files). > > I dont know what could be done if you try to run your app directly from > a war, but it seems to me that to do nothing is the way to go :), it is > simply a tradeoff.. I was just wondering if the connectors were aware that sometimes they won't find static contents using any "real" path, as they may be in a WAR file. As long as the connectors know that sometimes they shouldn't serve static content, they should just be a sort of proxy or man-in-the-middle. > An given that, to get static content served natively by the webserver, > it's a performance measure, it's seems that there is a little > contradiction with the possibility of run the webapp directly from the > war, isn't it? I agree that for performance reasons, it's best to let the frontal server handle static requests. However, in some scenarios (particularly development), it's useful to be able to overwrite previous versions in one go, i.e.: replace one WAR file with another, instead of deleting files that are no longer required, then adding all new files. Where I work, we also create webapps for other companies or organisations/associations, and it's much easier for them to handle one single file than lots of separate files, especially when they want to install an upgrade! > Saludos , > Ignacio J. Ortega Thanks, -Chris B. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
