This week's book giveaway is in the Other Open Source APIs forum. We're giving away four copies of Storm Applied and have Sean Allen, Peter Pathirana & Matthew Jankowski on-line! See this thread for details.
May I ask someone here what unpackWARs attribute of host container achieve?
Apart of war file pack/unpack, Is there any performance hit?
Why would someone need to unpack the war file, if everything works fine with packed war file? Any risk with the packed war file?
In a pure pedantic sense, the only thing that can be deployed as a webapp to a J2EE server is a WAR or EAR file. EARs don't apply to Tomcat, so nothing more will be said about them.
In a practical sense, it is not uncommon for J2EE webapp servers to unpack WARs that have been deployed to them into some server-internal location. In the case of Tomcat, this unpacking is optional, but enabled by default. Furthermore, Tomcat can run WARs that were never packed to begin with.
I've never seen any claims of greater performance one way or another, but one advantage that you do get from working with unpacked WARs is that if you want to tinker with them "on the fly", it's a lot easier to update files in the exploded WAR directory than it is to build and deploy an entire new WAR. Especially since recent-vintage Tomcats have had a tendency to run out of PermGen space when apps are re-deployed.
I take advantage of the "never-packed" functionality to speed up my development process a smidgen. By setting my webapp context root to the target directory in my IDE project, all I have to do is run the compile/copy phases of the webapp build and skip the actual "pack into a WAR file" phase. It's not that the packing phase takes very long, but a few seconds here and there do add up.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Mar 04, 2012
Thank a lot Tim. You are always here to help us!!!