You have created a Web application using a JBoss application server and you are going to put it in production. Great!

But deploying your application with JBoss serving the Web requests directly may not be the optimal solution. First because the Tomcat

In a production environment, you should not put your JBoss application as a Web front-end. Instead, you should use an Apache server and configure it to redirect specific Web application requests to your J2EE server. There are many many advantages in doing this:

• The Apache server can serve static files (CSS, images, javascript files) faster than JBoss/Tomcat.
• When you need it, you can activate SSL on Apache without having to change your application.
• The Apache SSL implementation is faster compared to the Tomcat implementation (and a lot easier to configure!).
• You can have a better control of HTTP headers. No need to develop any servlet filter for that.
• You can get compression out of the box. No need to develop another servlet filter either (no need to configure Tomcat connector either!).

I assume here that the Apache server is already installed with the following modules and these modules are enabled.

jk headers expires ssl deflate rewrite

If they are not enabled, you can enable them using the command:

sudo a2enmod jk

Step 1: Explode your Web or J2EE application

For Apache to serve the static files, it is necessary to have those files available in a directory that the Apache server can access. For this, explode your J2EE application (EAR file) and all the Web applications which have static files to be served by Apache. You will do this in a directory somewhere with one of the command:

mkdir ''myapplication''
cd myapplication && jar xf ../''myapplication''.ear
mv ''mywebapp''.war ''mywebapp''-new.war && mkdir ''mywebapp.war''
cd ''mywebapp''.war && jar xf ../''mywebapp''-new.war

If your EAR file contains a WAR file, you have to explode it as well (the static files to be served are there!). It is also a good practice to explode it in a directory having the same name as the WAR. Once everything is exploded, you can also configure JBoss to directly use the exploded directory (this will speed up JBoss startup significantly).

Step 2: Create a site configuration file

For good practices, you should write a configuration file that corresponds to the site that you are going to manage. This allows to enable or not a server configuration which will be useful during the maintenance. For this, create a file in /etc/apache2/sites-available and put an initial content (replace myserver.mydomain.com with your server name and server-installation-dir with the path of your installation directory):

 <VirtualHost _default_:80>
       ServerAdmin webmaster@localhost
       ServerAlias ''myserver.mydomain''.com
       ServerName ''myserver.mydomain''.com
       DocumentRoot /''server-installation-dir''
       <Directory />
               Options FollowSymLinks
               AllowOverride None
       </Directory>
       ErrorLog /var/log/apache2/''myserver''-error.log
       LogLevel warn
       CustomLog /var/log/apache2/''myserver''-access.log combined
 </VirtualHost>

The server-installation-dir should point to the WAR exploded directory.

It is also a good practice to use a specific log file for each server (virtual host) that you configure in Apache. Restrict the number of options to the minimum so that you do not activate an option that could compromise the security and also to keep the configuration understandable and manageable.

You may find additional information about virtual hosts on Apache Virtual Host documentation.

Step 3: Configure Apache mod_jk

The Apache server can redirect requests to JBoss/Tomcat by using the mod_jk module (jk). Edit the file /etc/apache2/mods-available/jk.load and define the following properties:

 
JkWorkersFile /etc/apache2/worker.properties
JkShmFile     /var/log/apache2/mod_jk.shm
JkLogFile     /var/log/apache2/mod_jk.log
JkLogLevel    info
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

Write a /etc/apache2/worker.properties file with the following example (be sure to replace some of the paths):

workers.tomcat_home=''directory where Tomcat is installed''
workers.java_home=''directory of the JDK installation home'' 
ps=/
worker.list=workerName
worker.workerName.port=8009
worker.workerName.host=localhost
worker.workerName.type=ajp13
worker.wokerName.lbfactor=1

The workerName is the name you are going to use within your site configuration file to tell Apache to which JBoss/Tomcat the requests are going to be forwarded.

You may find additional information on The Apache Tomcat Connector - Webserver HowTo

Step 4: Configure mod_jk in your site configuration file

Now that mod_jk is configured, you have to setup your site configuration file to redirect some of your URLs to your JBoss/Tomcat server through the AJP connector. This is done by the JkMount and JkUnMount directives. For this, add the following lines:

<VirtualHost _default_:80>
 ....
 JkMount /''mywebapp''/* ''workerName''
 JkOptions +ForwardURICompat
</VirtualHost>

where mywebap is the Web application context of your Web application when it is running. All request to /mywebapp will be redirected to JBoss/Tomcat. If Apache has to serve static files located in the same context, you have to use:

   JkUnMount /mywebapp/*.css workerName
   JkUnMount /mywebapp/*.js workerName
   JkUnMount /mywebapp/*.html workerName
   JkUnMount /mywebapp/*.png workerName

The Javascript, CSS, images and HTML files will not be served by JBoss/Tomcat because the JK connector is not activated for these links.

You could also only mount the dynamic files that your Web application is serving (like *.jsp, *.do, *.jsf or *.seam). This may not be the best solution if your Web application has specific servlets that are mapped without any extension (like an XMLRPC servlet, a Seam resource servlet and others). This is why, it is best to mount everything to your Web application and then manually specify what is static and served by Apache directly. This will prevent you from big surprises!

Step 5: Configure caching and compression

Compression can be activated easily by adding the following line at the top of your site configuration file (see the deflate module):

       AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/x-javascript

Browser caching is activated and controlled by the expires module in Apache. You may add the following options within the <Directory> section controlling the static files.

       # enable expirations
       ExpiresActive On

       # Activate the browser caching (CSS, images and scripts should not
       # change)
       ExpiresByType text/css A1296000
       ExpiresByType image/png A1296000
       ExpiresByType image/gif A1296000
       ExpiresByType image/jpg A1296000
       ExpiresByType text/javascript A1296000

You may find additional information on Apache Module mod_expires and Apache Module mod_deflate.

Step 6: Harden you Apache configuration

JBoss can add headers in the HTTP response. The X-Powered-By header exposes what implementation is behind your site. This header is created by a servlet filter that is activated by default in JBoss web configuration files (server/default/deploy/jbossweb-tomcat55.sar/conf/web.xml). You can either disable this filter by commenting the following lines:

  <!-- <filter-mapping>
     <filter-name>CommonHeadersFilter</filter-name>
     <url-pattern>/*</url-pattern>
  </filter-mapping> -->

If you cannot change this, don't worry! The Apache server can remove those headers for you. Just add the following directives in your site configuration file:

   # For security reasons, do not expose who serves the page
   <LocationMatch '^/''mywebap''/.*'>
       Header unset 'X-Powered-By'
   </LocationMatch>

Removing this header is also good for performance as it reduces the size of responses. You may have a look at the Apache documentation Apache Module mod_headers.

By default, the Apache server sends a complete signature in the Server header response. You should verify the /etc/apache2/apache2.conf file and make sure you have the following options:

ServerSignature Off
ServerTokens Prod

To verify that your server generates the good response headers, you may use the wget -S command or Firebug to look at those headers.