title: Advice deploying war files vs executable jar with embedded container
body: <p>There seems to be a current trend in java space to move away from deploying java web applications to a java servlet container (or application server) in the form of a war file (or ear file) and instead package the application as an executable jar with an embedded servlet/HTTP server like jetty. And I mean this more so in the way newer frameworks are influencing how new applications are developed and deployed rather than how applications are delivered to end users (because, for example, I get why Jenkins uses an embedded container, very easy to grab and go). Examples of frameworks adopting the executable jar option:
  <a href="https://dropwizard.github.io/dropwizard/" rel="noreferrer">Dropwizard</a>, <a href="http://projects.spring.io/spring-boot/" rel="noreferrer">Spring Boot</a>, and <a href="http://www.playframework.com/" rel="noreferrer">Play</a>  (well it doesn't run on a servlet container but the HTTP server is embedded).</p>
  
  <p>My question is, coming from an environment where we have deployed our (up to this point mostly Struts2) applications to a single tomcat application server, what changes, best practices, or considerations need to be made if we plan on using an embedded container approach? Currently, we have about 10 homegrown applications running on a single tomcat server and for these smallish applications
  the ability to share resources and be managed on one server is nice. Our applications are not intended to be distributed to end users to run within their environment.  However, moving forward if we decide to leverage a newer java framework, should this approach change?  Is the shift to executable jars spurred on by the increasing use of cloud deployments (e.g., Heroku)?</p>
  
  <p>If you've had experience managing multiple applications in the Play style of deployment versus traditional war file deployment on a single application server, please share your insight.</p>