Forwarding apache requests (port 80) to Tomcat (port 8080)

I strongly suggest using a tool designed for load balancing purpose such as haproxy. You may define backend checks and thus avoid sending requests to unavailable apps with a great deal of flexibility.

Your solution is also not HA, as the load balancer is a SPOF (single point of failure). You may want to add another machine and use keepalived for failover.

HAproxy can run in any port that you want, you can even balance different kinds of traffic, not only http, and at the same time configuring frontends (service balancing entry points) and backends (container for service instances and balancing behavior). You can see an example here: http://www.tomcatexpert.com/blog/2010/07/12/trick-my-proxy-front-tomcat-haproxy-instead-apache

For the failover part, I would use keepalived. It checks that your active load balancer is available and failover to secondary machine if its not, floating your virtual ip addres.

You may check this link for an example: http://www.howtoforge.com/setting-up-a-high-availability-load-balancer-with-haproxy-keepalived-on-debian-lenny

For the benefit of others, I'll answer my own question. Actually, Tomcat (since version 6) provides a quite easy solution for adding URI prefixes to webapps, by prefixing the webapp folder or WAR file name with that prefix (or those prefixes), separated by a hash. So, e.g.:

${catalina.base}/webapps/apps#my_app
${catalina.base}/webapps/apps#my_app2.war

...would make both accessible via http://localhost:8082/apps/my_app/ and http://localhost:8080/apps/my_app2/, respectively, without any further configuration in ${catalina.base}/conf/server.xml.

It is explained somewhat cryptically in the Tomcat Context Container reference, but see this kind message on the Tomcat-users mailing list helped me a lot.

Unfortunately, there's a catch: apparently, Cocoon (up to 2.1.11, haven't tested with 2.2 apps) chokes on webapps whose paths contain a hash (see https://issues.apache.org/jira/browse/COCOON-2270).

Yet, there is a workaround for those Cocoon-based webapps, as shown in following configuration steps:

1. move the folder or WAR file containing the webapp outside of the host's appBase path, e.g.: F:\cocoonApps\my_CocoonApp

2. add a file ${catalina.base}\conf\Catalina[host name][prefix]#[app name].xml, e.g.: ${catalina.base}\conf\Catalina\localhost\apps#my_CocoonApp.xml, with following content:

   <Context docBase="F:/cocoonApps/my_CocoonApp"/>

Using this workaround, even Cocoon webapps are happy when accessed at e.g. http://localhost:8082/apps/my_CocoonApp/. This could allow for quite flexible managment overhead of Tomcat webapps:

• non-Cocoon-based webapps: just add them in the Host's appBase, prefixing the name of the folder or WAR file with the desired prefix(es), separated with a hash (#). Adding new non-Cocoon webapps requires no further steps than storing them with the desired URI prefix.
• Cocoon-based webapps: store them outside of the Host's appBase, with just the unprefixed webapp name. Additionally, add a context file for each Cocoon-based webapp, specifying the of the webapp as explained above. This additional step then is only needed for Cocoon-based webapps.

With the Apache proxy settings explained in my original question, this makes it possible to flexibly add Tomcat apps and have them reverse proxied behind Apache using the /apps/ URI prefix.