• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

What does unpackWARs attribute of host container achieve?

 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Greetings,

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?

Any help is highly appreciated.

 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Atul Singhal
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank a lot Tim. You are always here to help us!!!
 
reply
    Bookmark Topic Watch Topic
  • New Topic