A WAR file is simply a snapshot of your web app structure, in a nice portable, compressed form (it’s really just a JAR file). You jar up your entire web app structure (minus the web app context directory—the one that’s above WEB-INF), and give it a .war extension. But that does leave one problem—if you don’t include the specific web app directory (BeerApp, for example), how does the Container know the name/ context of this web app?

That depends on your Container. In Tomcat, the name of the WAR file becomes the web app name! Imagine you deploy BeerApp as a normal directory structure under tomcat/webapps/BeerApp. To deploy it as a WAR file, you jar up everything in the BeerApp directory (but not the BeerApp directory itself), then name the resulting JAR file BeerApp.war. Then you drop the BeerApp.war file into the tomcat/webapps directory. That’s it. Tomcat unpacks the WAR file, and creates the web app context directory using the name of the WAR file. But again, your Container may handle WAR deployment and naming differently. What matters to us here is what’s required by the spec, and the answer is—it makes almost no difference whether the app is deployed in or out of a WAR! In other words, you still need WEB-INF, web.xml, etc. Everything on the previous pages applies.

Almost everything. There is one thing you can do when you use a WAR file that you can’t do when you deploy without one—declare library dependencies.

In a WAR file, you can declare library dependencies in the META-INF/MANIFEST.MF file, which gives you a deploy-time check for whether the Container can find the packages and classes your app depends on. That means you don’t have to wait until a resource is requested before the whole thing blows up because the Container doesn’t have a particular class in its classpath that the requested resource needs.