There's no problem with multiple wars. That's pretty much standard packaging.
But not all resources are shared across separate war files. Each has a separate context root, and session sharing between war files is not allowed by the standard, although I know IBM had some 'extensions' that did allow you to share session data between war files.
Here's a little something I wrote on the subject from a few years back:
Why would an ear file have more than one web module?
An ear file can contain any number of web and ejb modules. This begs 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, application partitioning is an inexact science, but there are some rules we can follow.
Take for instance a scenario where your enterprise application provides web access for both your human resources (hr) and accounting departments. Should this web application be separated into an accounting.war and hr.war file, or should everything be packaged together into a single hraccounting.war file?
When it comes to application packaging, there are no ‘right answers.’ There are only ‘wrong answers.’ The best we can do is try not to get the wrong answer.
Here are a few important points to consider when developing and subsequently deploying an application.
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 amongst hr and accounting modules, splitting your Servlets and JSPs across multiple war files is going be a problem.
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 accounting 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.
Forwarding to a 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 of your applications must always be a prime concern. The cost of any application is not how much money is require to develop 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
I think it doesn't matter many WAR/JAR files in an EAR..
we could unite all of it..
but, the issue that we've to consider is the deployment time..
the deployment time needs longer time, and sometimes its a bit difficult to maintained..
What the RSA stands for?..
its abbreviation is strength for me..
Sorry, perhaps my english language isn't too good.. Prepare for SCJP 6, Please God help me.. ☼
References : [Java.Boot] [JavaChamp] [JavaPrepare]