For application developers, this can lead to a rather daunting challenge, particularly when two disparate technologies need to coexist within the same application. An example of this is side-by-side deployment of PHP-based content and JSP-based content within the same Web application. This 10-Minute Solution offers one approach for deploying PHP and JSP pages within the same Web context.

How do I deploy PHP-based content and JSP-based content together within the same Web application context?

Configure Apache to locate PHP pages within the JSP Web context and to handle all PHP/CGI requests while letting Tomcat handle all other requests.

Solution Methodology

• Let Apache serve as the primary or default request processor, passing only Servlet/JSP requests to the Java container.
• Let the Java container serve as the primary or default request processor, allowing only PHP/CGI requests to be natively handled within Apache.
• Kick Apache to the curb and run PHP/CGI natively within Tomcat.

The first two categories represent fairly similar approaches. Which approach appeals most to you may largely be determined by your comfort level with Apache HTTP and Tomcat, respectively. The third category, although a temptingly simple solution, is undesirable because Apache handles PHP/CGI content so efficiently and it offers a more secure front end to Web applications.

The approach this solution takes is the second category: Tomcat serves as the primary request processor while Apache serves as the secondary supporting processor. (Figure 1 presents a simple visualization of this approach.) If your preference is more along the lines of the first category outlined above, it is simple enough to adapt this approach accordingly.

Figure 1. Tomcat as Primary Request Processor and Apache as Secondary Supporting Processor

Configuring Apache

At the bottom of Apache’s HTTP config file (/$APACHE_INSTALL/conf/httpd.conf), you should find the following block of code:

#
# Use name-based virtual hosting.
#
#NameVirtualHost *:80

#
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for requests without a known
# server name.
#

Below this section, create a VirtualHost element to capture all HTTP requests on port 80 and map them according to the methodology described previously (Tomcat is default, Apache only handles PHP and CGI requests):

<VirtualHost *:80>
    # Set DocumentRoot equal to Tomcat ROOT context
    DocumentRoot /www/webapps/ROOT

    # Exclude PHP & CGI (let Apache handle)
    SetEnvIf Request_URI \.php no-jk
    SetEnvIf Request_URI \.cgi no-jk

    # Tell mod_jk to handle everything else (non PHP and CGI content)
    # Assign the worker from worker.properties (‘myWorker’) to broker 
    #  the hand-off from Apache to Tomcat
    JkMount /* myWorker

</VirtualHost>

As previously described, you could easily tailor the above approach to fit a variant methodology by changing the JkMount element to pass only certain requests (i.e. *.jsp or /*/servlet/*) to Tomcat.

Deploying the Application

Although you certainly can set the Apache DocumentRoot to another directory (perhaps the default ‘htdocs’ directory), this is not as convenient for application deployment. By specifying Apache’s doc root to be the same as Tomcat’s, you can deploy PHP/CGI content along with JSP content as a part of the same archive (EAR/WAR). Simply place the pages/scripts into the Web application directory structure, just as you would JSP and HTML pages (either in the base of the app or in a subfolder). This makes deployment from dev to test to production very easy and removes potential human errors.

Additionally, deploying PHP pages and CGI scripts inside the normal directory structure enables them to share the same support files (CSS, JS, images, etc.) with the Java Web content. Also, this model provides an intuitive view into the Web application’s structure and how URIs are likely to be resolved. Calling PHP/CGI content from Java Web components (and vice versa) becomes much simpler.

Have Your Cake and Eat It Too

This solution has offered one viable means of integrating PHP/CGI content with JSP/Servlet content as a part of a single deployment Web context. Some situations demand that you bite the bullet and choose one technological path, but in this case, you really can have both.