5

We're deploying our JavaEE 7 application on Wildfly 8. Previously, we've packaged all of our enterprise applications (WAR, multiple EJB JAR files) as an EAR. However, with JavaEE now allowing you to package EJBs in a WAR file (or as a JAR within the WAR's WEB-INF/lib) we're wondering if there is any benefit in deploying an EAR rather than going with WAR packaging.

Does an EAR provide something that a WAR does not? It certainly reduces packaging complexity to make use of a WAR. Is there any difference in terms of deployment? EJB naming? Anything?

Shadowman
  • 11,150
  • 19
  • 100
  • 198

2 Answers2

5
  • Easier to deploy (only one package instead of multiples).
  • Some server (example Weblogic, but not wildfly) allow shared session for an entire EAR.
  • In general, EAR provide more option to configure with AS.
  • Special folder (APP-INF) that let you define a config file application.xml.

If your application would consist only of multiple WARs then you may not find it such a big deal to maintain multiple deploy. However, consider an application which use WARs, EJBs, JMS etc. It will be a lot easier to mananage the interaction between all these components in an EAR.

You might want to read the packaging application part of the Java EE tutorial.

Jean-François Savard
  • 20,626
  • 7
  • 49
  • 76
  • 3
    I don't understand why this is the correct answer. I think it is definitely easier to package everything in one WAR and deploy that, than to build several modules and package them in one EAR. Why use several WARs? At least the question mentioned only one WAR. Additionally the link refers to j2ee 6, the question refered to j2ee 7. – aschoerk Aug 11 '17 at 16:58
  • @aschoerk Agreed. Just adding my two cents, I don't know why would someone want more than one WAR, because if you use JSF (even without JSF) you can put views in a JAR to be referenced by a WAR (in a multi-module maven project). – julianomqs Jan 29 '18 at 16:22
0

Setup of deployment of an EAR is painfully hard work (especially under Weblogic). Deployment of a WAR is simpler. Deployment as EAR has two benefits:

  1. You can aggregate several unlinked applications in one file (whole eggs in one basket).
  2. You can reduce size of this file with help of skinny war technology.
  3. Your devops can deploy only one application instead of several. Links restoring is not needed.
  4. You can setup a well build barrier between in\out ear modules.

And many many others.

In other words one-war pattern in most of cases is devoted only for test and training purposes.

  • Using WARs, you can put libraries inside application server as modules and marking them as provided scope in pom, reducing WAR size. I did that many times successfully, in WildFly and Payara (Glassfish). – julianomqs Jan 29 '18 at 16:25
  • @julianomqs It is a very-very-very bad practice. You know that size of ear does not matter. How do you plan to calculate whole provided items? It's a real headache. Looking back I understand that EAR is the best way to develop a large application. – Alexander Fedyukov Jan 29 '18 at 17:26