When is it appropriate to use an EAR and when should your apps be in WARs?


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!


Having multiple shared libraries rather should not be the compelling reason to go for an EAR, as a JAR (or set of JARs) can always be deployed as "library" on weblogic which can, therefore, be shared by all the WARs. Isn' it right?

By : Ashish

Nothing is actually wrong with just deploying wars, developers have an interest in getting tasks met quickly as possible. That means they often will take on technical debt, and if they are in a respectable team, they will clean that debt.

This however presents a problem, what happens when you avoid the complexity of EARs, and share a jar by adding it to the application server? Much more common in the war only team, is offloading all sorts of application complexity to the application server. Simply because it was easier to implement, in their often over-allocated schedule. I don't blame them for this at all, However now we have a new problem. A standard application server cannot be used, you must do system side customizations. Effectively the web application is bleeding all over the system. The person who maintains the Application server, now MUST also know application specific details... in an enterprise environment, this presents a very clear problem.

The developers can then take on system responsibility, but they still need to meet deadlines. They inevitably bleed all over the OS as well, and suddenly the developers are the only possible admins. If an admin doesn’t know what the application is using system side, they can very much cause major problems. These unclear lines always end in fingers pointing in both directions, unknown system states, and team isolation.

Do they have to use an EAR then? Nope, I'm a systems Engineer, so I always say they can deploy their own application server like another commercial application. Inside an RPM, if deploying a WAR is like other supported Application Servers, then they get the WAR deployment pipeline. If not, then RPM all in one... Once not allowing the team to externalize their costs, then EARs become a GREAT idea.

By : TechZilla

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.

This video can help you solving your question :)
By: admin