n an ideal world, businesses would select one technology platform and deploy it throughout their entire enterprises. In the real world, information systems are composed of a mix of operating systems, platforms, and application environments. To add to this complexity, the systems nearly always are a blend of modern and legacy.

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

As with any problem, several solutions are available. The solutions for this problem can be grouped into the following three major categories:

• 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

The first step in this whole process may very well be the most daunting. You need to install the Apache HTTP server and configure it to talk to Apache Tomcat. Google searches will quickly turn up a slew of tutorials, wikis, and mailing list entries on the subject. However you configure it, you will likely need to use an Apache Tomcat connector, either mod_jk or mod_jk2. I highly recommend that you use mod_jk, as the mod_jk2 branch was abandoned in 2004.

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

Once you have properly configured the environment, it is time to package and deploy the Web components. Packing and deploying your Java Web application is no different when you have Apache deployed in front of Tomcat. The directory structure and location of config files (WEB-INF/web.xml) does not change. The difference comes when storing the PHP and CGI files alongside your Java Web 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

Whether you are asked to integrate a legacy Web app with a new application, fold an open source utility into a custom Web app, or simply integrate the work done by two team members with differing skill sets, you will likely run into a need for combining disparate technologies into the same Web application. While converting the content and functionality to one technology platform is the best solution, integrating the two technologies into the same Web application context may be the answer.

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.