Tuesday, January 26, 2010

Multiple war in an ear file (EJB and Other Java EE Technologies forum at JavaRanch)

Multiple war in an ear file (EJB and Other Java EE Technologies forum at JavaRanch):
"Why Would You Put Multiple War Files in a J2EE EAR?

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.

Managabitly

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"

Monday, January 25, 2010

How to Run a War File? : A Sunny Commune - Cheng's Blog


How to Run a War File?


This question has been asked many times, and I figured it's worth repeating. The Simple answer:

1. Start the web server;

2. Deploy the war file to the web server;

3. Visit JSP pages or servlets in the browser.

In more details:

1. It is not possible to run a war file outside of a container.

A war file contains JSP pages, Servlet classes, static html files, and other java classes and resources. It has to live inside of a container provided by application/web servers, just as applets are managed by a browser. For example, you can download and install Glassfish, Tomcat, or Jboss.

Start the web/application server. Start the browser and visit http://localhost:8080 to confirm the server is running. Your server may use a different web server port. If you are not sure, try 8080 first.

2. Copy the war file (say, helloworld.war) to the autodeploy directory of the application/web server.

It's so called auto-deploy or hot-deploy. If you can't find such a directory in your server, look again. If it's really not there, stop using this server immediately. Althoug auto-deploy is not required by J2EE standards, virtually all servers support this. Why choose an inferior one when you have so many choices? See how easy it is to deploy a war file to Glassfish.

3. In the browser visit http://localhost:8080/helloworld/

This is the root of your helloworld web application. You may see errors in the browser if helloworld.war doesn't have welcome page (usually index.html, index.jsp, index.htm), and the server has disabled directory listing.

For individual JSP pages, you can access http://localhost:8080/helloworld/say.jsp, assuming say.jsp is packaged directly inside the war file (that is, not under any subdirectory in the war file).

For individual Servlets, you can visit http://localhost:8080/helloworld/hello, assuming you have configured such a servlet-mapping for the url-pattern (/hello) and this servlet. Usually you have to map the Servlet to a url-pattern in web.xml, and when you visit this url, the Servlet will be invoked."