25

I'm noticing a lot of projects (DropWizard, Grails, etc.) starting to embrace the notion of a "fat" JAR (using an embedded web server like Jetty or Tomcat) vs. the traditional WAR deploy. Both methods involve a single JVM process (i.e. no matter how many WARs are deployed to Tomcat, it's all the same JVM process).

Under what circumstances is either deployment method preferable over the other?

AdjustingForInflation
  • 1,571
  • 2
  • 26
  • 50
  • 1
    Traditional WARs-to-Tomcat are fine for internal apps (used by internal users/employees) that don't really have scaling/config management needs. The second you have a component (web app or REST service, etc.) that needs to be public-facing, you need to scale that component at its own rate and you need (well, *should*) automate the configuration of the nodes that component lives on (see Ansible/Chef/Puppet/Salt/etc.). Scaling and CM automation are next-to-impossible to accomplish on heterogenous nodes that contain different combinations of WAR files... – smeeb Nov 24 '15 at 10:21
  • 1
    ...for instance: if you have 10 Tomcat nodes and 30 WAR files (representing 30 different components), then to achieve automated CM you need to defines *types* of nodes (DB Node, App Node, Microservice Node, Cache Node, etc.) and deploy the same subset of your 30 components to each node type. But then you'll have scaling issues, because inevitable the components being shared on each Tomcat instance will have different scaling requirements. So it boils down to: what are you deploying, and what are its requirements? – smeeb Nov 24 '15 at 10:26
  • 1
    Internal componentry is fine as WAR-to-Tomcat. Web scale componentry needs homogeneity, and that can only be **cleanly** accomplished with these so-called fat JARs. – smeeb Nov 24 '15 at 10:26

3 Answers3

18

Here are some reasons:

In favor of JAR:

  1. Simple to build and deploy.
  2. Embedded servers like Jetty are easy to operate.
  3. Applications are easy for users to start and they can run on their personal computers too, because they are lightweight.
  4. Starting and stopping applications will require less knowledge than managing web servers.

In favor of WAR or EAR:

  1. The server would provide features like deployment, restart, security and so on for multiple web applications simultaneously.
  2. Perhaps a separate deployment team can handle the starting and stopping of apps.
  3. If your supervisors like to follow rules, they will be happy to find that you are not breaking them.

Having said this, you can always provide 2 or 3 types of executables to cater to all needs. Any build tool makes this easy.

wavicle
  • 1,284
  • 1
  • 10
  • 12
7

Distributing an application with an embedded webserver allows for standalone setup and running it by just calling java -jar application.jar.

However, there may be users who want to be in control of which web server is used or who want to deploy multiple applications into a single webserver (e.g. in order to prevent port clashes especially with ports 80 and 8080). In that case a "fat" jar might cause problems or at least some unneeded code and thus a larger memory footprint.

IMHO the best approach for those two cases would be to provide two artifacts: a "fat" jar for (easier) standalone setup and an application-only war/ear for those who want to deploy the application in their own container.

Thomas
  • 87,414
  • 12
  • 119
  • 157
4

I am thinking about user perspective. You could wrap this one-self containing jar within a .exe or .dmg and just install it without the need to have additional instructions on how to deploy. Also, since you are doing the deploy for a particular server only, you could take advantage of that particular server

Eugene
  • 117,005
  • 15
  • 201
  • 306