Embrace Dreams

You have many choice, I have tried many ways on Domix.in. It’s not easy to learn how to make Apache&Tomcat&Glassfish to work fast.
These days I find a very good post http://rimuhosting.com/mod_jk2_and_mod_proxy_ajp.jsp, in order to mark it, I copy the post here, hope it’s useful.

Accessing Tomcat on Port 80: From example.com:8080 to example.com
By default Tomcat and JBoss run on port 8080. So your Tomcat urls look like http://example.com:8080/index.jsp.

There are a few ways ways you can access Tomcat webapps on the regular port 80 so that you do not need the port number in the URL.

Apache, mod_proxy/mod_jk2, Tomcat: You can use Apache as the front end to all requests then forward certain URLs or virtual hosts to Tomcat. This option lets have some content served by Tomcat (e.g. a whole domain, or a certain directory on a domain) and other content (e.g. HTML, PHP pages, etc) served by Apache. If you are on a newer distro (e.g. FC5, Centos5 and Debian Etch) with Apache 2.2 you would use mod_proxy or if you had an older distro with Apache 2.0 (e.g. RHEL4, Debian Sarge) then you would configure the Apache mod_jk2 module.
Tomcat, iptables, Port 80: Another method you can use is iptables. iptables let you forward traffic received on one port (80) to another port (8080). This method bypasses the Apache webserver completely (even if it is running on port 80). This is the simple to setup. But you will not be able to use Apache (e.g. for webmail, using PHP apps, or apps like phpMyAdmin).
Tomcat, Root, Port 80: You can also set Tomcat to run on port 80. We do not recommend this method, since then Tomcat would need to run as a privileged user. Which has security implications.
Apache 2.2 mod_proxy
Often customers want to combine the use of JSP and Apache. For example, they may have some PHP scripts and some JSP programs they want to run. (And the Servlet engines cannot execute PHP scripts). Using Apache to handle your incoming requests also gives you more options for things like using SSL, error logs, and using .htaccess files.

Apache 2 introduces the mod_proxy module. It is a standard module in most modern distros. This module pretty much deprecates the need for mod_jk2. Full documentation for mod_proxy is available.

To setup mod_proxy_ajp add something like the following inside of your Apache VirtualHost entries (e.g. in /etc/httpd/conf/httpd.conf under CentOS/Fedora, /etc/apache2/sites-enabled under Ubuntu/Debian):

ProxyPass /tomcat ajp://127.0.0.1:8009/
ProxyPassReverse /tomcat ajp://127.0.0.1:8009/
This will forward all requests to http://yourip/tomcat to tomcat’s ROOT webapp. Or you could use the following line to forward all requests to http://yourip/tomcat to tomcat’s jsp-examples webapp.

ProxyPass /tomcat ajp://127.0.0.1:8009/jsp-examples
Run the following to enable mod-proxy-ajp and to change allow/deny setting to Deny from none # was all:

a2enmod proxy proxy_ajp

sed –in-place ‘s/Deny from all/Deny from none # was all/’ /etc/apache2/mods-available/proxy.conf
Resolving “client denied by server configuration”
If you get an error in the Apache error log like client denied by server configuration: proxy:ajp://127.0.0.1:8009/tomcat then you may need to enable Proxying. e.g. on Ubuntu/Debian systems change the Proxy * setting from Deny all to Deny none in /etc/apache2/mods-enabled/proxy.conf:

AddDefaultCharset off
Order deny,allow
Deny from none
#Allow from .example.com

Also on Ubuntu/Debian systems, you may need to enable the specific proxy module for apache. Something like the shell commands bellow…

a2enmod proxy_ajp
a2enmod proxy_http
Running JSP Through Apache: mod_jk2
mod_jk2 is an option on Apache setups prior to Apache 2.2 (e.g. RHEL4, Debian 3.1). It is not an option on newer setups (e.g. not on Centos5, FC5 or newer, Debian Etch, or Ubuntu 7.10). For the newer distros you would use mod_proxy instead.

mod_jk2 intercepts Apache requests to certain URLs and forwards them to your Servlet engine. For example, it can hand off requests to certain “mount points” like /jsp to your Servlet engine. It can also hand off certain file types (e.g. *.jsp) to your Servlet engine.

mod_jk2 forwards the Apache requests to your Servlet engine via a socket using a protocol called ajp13. Both Tomcat and Jetty support the ajp13 protocol.

First Step: Serve Content on Default Servlet Port
The first step towards running your webapps with Apache as a front end, is to first get them working directly from your default servlet eninge port. 8080 is the default port for Tomcat (including JBoss/Tomcat) and Jetty. Taking this step before testing the mod_jk2 setup makes troubleshooting problems easier:

Set up your web apps (you may use any of the installed Servlet engines, they all support mod_jk2).
Make sure your can browse your webapp using a URL like: http://yourip:8080/jsp/index.jsp. When using Apache as a front end, it is best to not use a ‘ROOT’ mounted webapp.
Do not run the iptables command to forward port 80 requests to the Servlet engine (since we want Apache to handle the incoming requests).
Test you can load your web app on http://yourip/jsp/index.jsp
Note: your Servlet container needs to listen for connections from Apache. The Tomcat and Jetty installations on RimuHosting VPSs are set up this way by default. You just need to make sure they are running (see the Tomcat and Jetty start up instructions above).

Next Steps: Serving up your WebApp from Apache
RimuHosting have pre-installed the mod_jk2.so module binary for the Fedora, White Box Enterprise Linux 3 and recent Red Hat 9 distributions. (If your Red Hat VPS was setup prior to 2004, contact support for information on how to get the mod_jk2.so module).

mod_jk2 is configured in the /etc/httpd/conf.d/mod_jk2.conf file.

This file includes a sample ‘Location’. It looks like this:

JkUriSet worker ajp13:localhost:8009

This Location tag will direct requests to http://yourdomain/jsp-examples to the jsp-examples webapp (if one exists) on your Servlet engine.

If you want to run your own webapp instead, just edit this file and rename jsp-examples to your own webapp’s name. Alternatively you can add your own Location tags in /etc/httpd/conf/httpd.conf.

You can put the Location tag inside a VirtualHost tag if you want the Location to only work for a particular domain. Note: on some servers there seems to be a problem where the VirtualHost is ignored, and the Location is used across all domains. In this case you will need to setup a workers2.properties.

ROOT WebApps
If you want to have all requests go to Tomcat, use a Location of / and your requests will go to the Tomcat ROOT webapp.

If you want to mix and match Apache and Servlet engine requests for the domain, you may need to change the Location tag. For example, set it to /*.jsp and /*.do. This will make it so only the Servlet related requests go to the Servlet engine.

Tomcat Host Directive: When Each Domain Has Their Own Root Webapp
Do you have more than one domain and you want each domain to use a different root webapp? Then you will need to use Tomcat Host directives so that Tomcat knows which webapp to serve for which domain.

Setup Apache VirtualHosts. Then add a Location tag inside each of the VirtualHost directives in /etc/httpd/conf/httpd.conf, e.g.

ServerName yourdomain.com
ServerAlias *.yourdomain.com

JkUriSet worker ajp13:localhost:8009


In your server.xml file (usually /usr/local/tomcat/conf/server.xml) add something like:

appBase="/usr/local/tomcat/webapps">




www.your2nddomain.com

These directives setup the default webapps for each of the virtual hosts.

Then restart Apache and Tomcat.

Note: The server.xml changes are only required if you want to run multiple virtual hosts with different ROOT webapps. If you just have multiple virtual hosts with uniquely named webapps, they are not required. Just use the regular Location tags and make sure the webapp name and the Location directory match.

workers2.properties: When Location Tags Inside VirtualHost Directives Do Not Work
On some versions of mod_jk2 and Apache we have noticed a problem where Apache ignores the VirtualHost that a Location tag is nested within. For example, a Location / inside one VirtualHost ends up applying to all VirtualHosts on the server. So that all requests go to Tomcat, not just the requests for the intended domain.

To workaround this problem, remove your Location directives. Create a /etc/httpd/conf/workers2.properties file. Then add directives like:

[uri:yourdomain.com:80/*]
worker=ajp13:localhost:8009
[uri:your2nddomain.com:80/*]
worker=ajp13:localhost:8009
These directives will pass the requests to the named virtual hosts to your Java server. If you have yourdomain.com and www.yourdomain.com you’ll need to add both those [uri] directives for each.

jk2_init Errors
Getting something like this in your apache error_log file?

[Mon Feb 04 15:36:04 2008] [error] jk2_init() Can’t find child 9744 in none of the 256 scoreboard slots
We have seen these errors before. They do not appear to cause any problems. And according to our googling can just be ignored.

IPTables: Forwarding Incoming Port 80 requests to Port 8080
If you want to use Apache as a front end to Tomcat, skip this section.

If you want to use iptables to forward incoming requests on port 80 to Tomcat on port 8080, run these commands to setup an iptable rule:

First, stop and disable apache. Under Centos or Fedora try the following…

# prevent Apache from running on startup
chkconfig –del httpd
# stop Apache from running right now
/etc/init.d/httpd stop
… or if you have Debian/Ubuntu based systems try …

# prevent Apache from running on startup
update-rc.d -f apache2 remove
# stop Apache from running right now
/etc/init.d/apache2 stop
… then set the redirection up…

# install the iptables applications if they are not already there
apt-get -y install iptables
# tell iptables to forward incoming requests on port 80 to tomcat
/sbin/iptables -t nat -I PREROUTING -p tcp –dport 80 -j REDIRECT –to-port 8080
For RedHat/Fedora/CentOS based distros (if there is a file called /etc/redhat-release) use this:

# save the iptable rules
/sbin/iptables-save > /etc/sysconfig/iptables
# make sure iptables starts up by default after a server restart
chkconfig –level 35 iptables on
For Debian based distros (if there is a file called /etc/debian_version) use this:

# save the iptable rules
/sbin/iptables-save > /etc/firewall.conf
# create a script so ifupdown loads these rules on boot
echo ‘#!/bin/sh’ > /etc/network/if-up.d/iptables
echo “iptables-restore < /etc/firewall.conf" >> /etc/network/if-up.d/iptables
chmod +x /etc/network/if-up.d/iptables
You may get a QM_MODULES warning. You can safely ignore that. Our VPS servers are built without modules and with the iptable features built into kernel itself. The iptables scripts just do not detect that modules are not available and do not know to skip that step.

If you decide to turn off your iptables rules, run this:

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
iptables -t nat -F
For RedHat/Fedora/CentOS based distros (if there is a file called /etc/redhat-release) use this:

# save the iptable rules
/sbin/iptables-save > /etc/sysconfig/iptables
# make sure iptables starts up by default after a server restart
chkconfig –level 35 iptables off
For Debian based distros (if there is a file called /etc/debian_version) use this:

# save the iptable rules
/sbin/iptables-save > /etc/firewall.conf
Maintaining Java Sessions through an Apache Proxy
If your application makes use of Java Sessions, you may need to tweak the Cookie Path attribute to make it work as expected. A common problem this might fix is when attempts to log in appear successful, but require you to log in again immediately.

The problem is that Java is sending a cookie path for a certain location, but Apache is configured to serve the application at a different location, so the browser receives the session cookie, but never sends it back because it never requests a page that matches the cookies location.

The original Set-Cookie header looks like this in the HTTP response

Set-Cookie: JSESSIONID=TOMCAT_SESSION_ID_HERE; Path=/myapp
If your application is not accessible at /myapp though, it won’t ever send that cookie back in a request, so you don’t appear to have working sessions. The solution is simple, but requires Apache 2.2 which introduced the ProxyPassReverseCookiePath setting with mod_proxy. Add this line to your Apache configuration to have Apache rewrite the Path attribute in the Set-Cookie header:

ProxyPass / ajp://127.0.0.1:8009/myapp/
ProxyPassReverse / ajp://127.0.0.1:8009/myapp/
ProxyPassReverseCookiePath /myapp /
That will change the path attribute in the Set-Cookie response header to this:

Set-Cookie: JSESSIONID=TOMCAT_SESSION_ID_HERE; Path=/
And now your browser will send the cookie back on requests to your application.