We have many Spring web applications to make on a WebLogic server and are curious about when WARs should go in an EAR and when they should just exist as WARs. Occassionally, the WARs will need to access common logic JARs, but I don't see why these would need to go into an EAR when they could just be packaged into the WARs.
From what I understand, if several WARs are in an EAR and you need to modify one of those WARs, you need to redeploy the entire EAR to update the server. This will cause all of the WARs to bounce. If they weren't in an EAR, however, I could just update the one WAR and it would be the only one to bounce.
What's wrong with having 100 different WAR files standing alone and using packaged JARs and shared libraries (using WebLogic)?
Thank you for any insight!
An EAR file requires a fully Java Platform, Enterprise Edition (Java EE)- or Jakarta Enterprise Edition (EE)-compliant application server, such as WebSphere or JBoss, to run. A WAR file only requires a Java EE Web Profile-compliant application server to run, and a JAR file only requires a Java installation.
An enterprise archive (EAR) file is a compressed file that contains the libraries, enterprise beans, and JAR files that the application requires for deployment. You create a JAR file when you export your application modules from IBM® Integration Designer.
Procedure. To deploy the EAR file: In the side panel of the console, click Applications > New Application and then New Enterprise Application. Click Browse and navigate to the Decision Center EAR file for your version of WebSphere Application Server.
Simplest solution will be to use Eclipse export function. Or generate two identical projects (e.g. 'ear2war'), first as EAR second as WAR, have a look at configuration files and finaly adjust your project.
If all you have is WAR files, then an EAR is of limited usefulness, serving only as a deployment container for your WARs. You can save a bit of bloat by sharing JARs between the WARs in this way, but that in itself is not hugely compelling.
EARs are essential, however, when dealing with full JavaEE/J2EE applications, which use WARs, EJBs, JMS, JCA resources, etc. The interactions and dependencies between the components of these sort of applications is vastly easier to manage in an EAR.
But if all you're using Weblogic for is a WAR container, then you might as well use a vanilla servlet container like Tomcat or Jetty, for all the functional use you get out of Weblogic.
I agree with almost all of skaffman's (typically) spot on comments.
If you're using Spring without EJBs you can stick with a WAR file, of course. No need for an EAR that I can see.
However, if your Spring app uses message-driven POJOs I can see where you'd still deploy a WAR file on WebLogic to take advantage of JMS.
An EAR might be necessary if you've got EJBs or JCA, but I wouldn't say that JMS mandates an EAR. I've used JMS and deployed a WAR file on WebLogic and it's worked just fine.
If you decide to go with Tomcat and deploy a WAR there, you can still keep JMS functionality if you use ActiveMQ.
The argument to package multiple WARs into an EAR can be compelling if you run into the situation that my last employer did, where you have a common set of library JARs that are used by multiple WARs, and the size of that collection of JARs is considerable. In our particular situation, the total size of 3 WARs with the common JARs packaged into each WAR totaled 124MB. By locating the JARs in the containing EAR and configuring the classpath of each WAR to use those JARs, the footprint of the EAR that contained the 3 WARs was reduced to 40MB. I'd consider that a compelling reason.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With