Quite often the questions appears ‘Can we have 2 wars in the same ear?’
Yes, we can have multiple wars as well as jars in one ear and they can share the same class loader. This means that all the classes are accessible from all the jars/wars.
The only problem appears when you try to load the pages of the other module (war). The server would complain that configuration file for that module is missing and you are stuck there.
To resolve this problem, change WAR class loader policy from Module to Application in the Application.xml of the EAR. Please note that each .war has an independent isolated classloader (mandated by spec). If you have common classes which are required by both those wars, then you’ll have to package them in a jar and place that jar in .ear/lib folder.
Two WARs will have independent WebApp Classloaders which have EAR Classloader as their parent.
Rule of thumb is the classes loaded by Parent are visible in Child classloader but not vice-a-versa. Sibling classloaders do not see each others classes.
The reason for an ear file to have more than one web module?
An ear file can contain any number of web and ejb modules. This brings the question, “should I deploy all of my web content in a common war file, or should I separate my web content into separate war files?”
Well, there are some rules we can follow for application partitioning:
Take for instance a scenario where your enterprise application provides web access for both your human resources and payroll. Should this web application be separated into a payroll.war and hr.war file, or should everything be packaged together into a single sharedservice.war file?
Here are a few important points to consider when developing and subsequently deploying an application.
The Common ServletContext : Servlets and JSPs can share information between each other by using a special scope named the ServletContext. If you are placing information in this ServletContext, such as the IP address of the payroll database, you probably don’t want you’re hr application to be able to access it.
The ServletContext is not shared between war files. If you do not want one set of Servlets to see another set of Servlets ServletContext, you’re going to have to separate the two applications into separate war files.
The Session Problem: Sessions, a mechanism for storing transient information about the client interacting with your website, are not shared across war files. If session information needs to be shared among hr and payroll modules, splitting your Servlets and JSPs across multiple war files is going be a problem.
Forwarding to JSPs: A common design pattern is to have a Servlet handle a request, and have it forward to a JSP for display. However, Servlets can only forward to JSPs packaged inside of a common war. You can use a special method called ‘redirect’ to send a user to a JSP in a different web module, but the redirection becomes a brand new request, and information about the initial request and response is lost.
Manageability: Manageability of your applications must always be a prime concern. The cost of any application is not how much money is require developing it, or the hardware required to run it, but is instead the cost of managing that application over the long-term.
If the two applications you are packaging are large, separating them into two separate war files would make them much easier to manage. Modularity helps facilitate maintainability.
The main advantage of having multiple .war in one .ear is that you can update individual .war without affecting whole application.