Hi, >Hmm, it seems that keeping it in memory would provide better performance >than writing it to disk...admittedly with a higher cost in terms of >overhead.
You can, and Tomcat does this, for the relevant parts of the WAR. But a WAR can contain an unlimited amount of resources, including for example 2 GB of static .html files ;) Getting all that in memory would lead to a bad situation. Of course you could write something adaptive, "load up to X" into memory, but than it gets trickier and slower. >I guess I still do not see the difference between a war file and a jar >file other than the size - they are both zip files, they are both >intended to simplify deployment, etc. The differences are numerous. Pretty much the only similarities are the compressions format (Zip for both) and the ar part of the extension. Beyond that, JARs have various properties (sealed, class-path, indexing) that are specific to them and designed for use-cases like applets. WARs have various properties (such as content under WEB-INF/ is special and cannot be served by the container, classes before lib, etc.) that are specific to them and designed for Servlet Container use-cases only. >It is just that the war file has to be unpacked while the jar file does >not. That is what I do not understand...what makes it so much more >difficult with a war file than a jar file? The WAR file does not *have* to be unpacked. In fact, the Servlet Spec requires its Containers to support running a packed WAR, and not vice versa. Whether to unpack a WAR partially, fully, transparently, or optionally are all Servlet Container implementation choices. The ones made by Tomcat are not only well thought-out (and I can say that without arrogance because I wasn't involved in most of them, it's not credit to me ;)), but proven to work well in the real world. As other technologies emerge, these implementations choices are subject to change. For example, java.nio's direct-mapped memory buffers provide interesting possibilie for in-memory WAR manipulation. So we constantly evaluate these options, sometimes going so far as to benchmark and test them out. This is not a dead area of development, nor one that we see as unimportant. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
