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.