![[ZOIS]](../pics/little.zois.gif){kind=small}
Home Page *
Contact ZOIS *
Technical Notes
ZOIS Technical Note TN-2002-05-23.
Author and Audience
This TN is intended for persons working with Java 2
Enterprise Edition (J2EE) products and methodologies on Linux and
similar platforms. UNIX systems and Java programming skills are
assumed. Written by Martin Sullivan[1],
ZOIS Limited, Cockermouth.
Abstract
As part of work conducted for one of ZOIS's clients using
Struts[2] it was found necessary to upgrade to Tomcat 4,
also known as Catalina[3]. At the same time Apache[4] was upgraded to allow mod_ssl[5] to
be installed. Connection between Tomcat and Apache was also upgraded
to use the mod_webapp module and the newer Warp protocol (rather
than mod_jk). Tomcat 4, as a purely Java based system was installed as
a binary but Apache/mod_ssl/mod_webapp required extensive compilation.
Introduction
Apache is the HTTP server of choice form many. Being both Open
Source and robust it is an extremely attractive commercial choice for
serving web-pages. Its functionality is extended by Apache Modules,
which are usually configured to be loaded via a Dynamic Shared Object
mechanism. Such modules are frequently labelled
mod_<something>. The current trend in HTTP Server technology is
to construct web pages on the fly in response to form based input
allowing functionality that would normally be expected in an OLTP
system. A number of Apache Modules have been written which offer such
systems, the particular one of interest to ZOIS is based
around Java Server Pages (JSP) a system where Java programs are
embedded within HTML marked-up web pages. This system can be combined
with Enterprise Java Beans (EJB) to deliver powerful, scalable
technologies, which match traditionally OLTP systems based on products
such as CICS and Tuxedo.
At the time of writing ZOIS has a demonstration system
based on Apache 1.3, Tomcat 3.2, JBoss 2.2 and PostgreSQL 7.0. JBoss
is a EJB Container and PostgreSQL is a Relational Database Management
System, these are not directly involved in this work.
To demonstrate Struts, a JSP system and methodology which uses the
Model View Control (MVC) paradigm and a client's application that ran on
it, it was necessary to upgrade to Tomcat 4 (Catalina). At the same time
it was thought good to upgrade Apache and use mod_ssl, to provide Secure
Socket Level (SSL, hence the modules name). A more modern connector
between Tomcat and Apache would also be used (the current system had
used mod_jserv and then mod_jk). Tomcat 4 installations appear to favour
using mod_webapp, so this was chosen as an experiment.
Materials and Platform
The J2EE demonstration runs on the Red Hat distribution of Linux
(version 6.2, kernel 2.2.14). It runs on conventional Intel
based PCs and Laptops, to allow demonstrations at remote sites. The
minimum for this works seems to be a 200 MHz CPU and 64 Mbytes of main
memory. A generous amount of disk space is required too and
the /opt directory was used as the installation target for all
these packages. The Java used was IBM's 1.3 (IBMJava2-13) for Linux.
Method
Mod_ssl is required by Apache HTTP servers to implement the Secure Sockets Layer Protocol allowing sensitive information exchanges to be secured cryptographically. This is frequently used for credit-card authorization and the like, its use is signalled on most popular web-browsers by a closed pad-lock or similar icon.
From the mod_ssl web-site[5] it was learned that mod_ssl would require a particular version of Apache and could only be built in conjunction with the version of Apache from source. The versions chosen were mod_ssl 2.8.8 and Apache 1.3.24 (which at time of writing was the latest in the series of 1.3 Apaches).
Mod_ssl is dependent upon the OpenSSL package[6]. It was found that an existing OpenSSL installation was insufficient, lacking several critical include files. The latest versions of this (0.9.6d) was therefore download and compiled according to instructions in the INSTALL file without incident. Instructions for obtaining this package can be found on the mod_ssl web-site and in the README files accompanying the source package.
Mod_ssl is built in conjunction with Apache. It uses the Apache Configure script system which is similar to GNU autoconf. Running configure with the appropriate arguments in the mod_ssl build tree runs an appropriate configure in the Apache one as well. The following script was used to build an Apache that could use mod_ssl and act as a proxy. As many Dynamic Shared Object (DSO) modules as possible were to be loaded at run-time. Additional modules were select based on the existing Red Hat supplied Apache.
./configure \
--with-apache=../apache_1.3.24\
--with-ssl=../openssl \
--prefix=/opt/apache \
--enable-shared=max \
--enable-module=vhost_alias \
--enable-module=env \
--enable-module=log_config \
--enable-module=log_agent \
--enable-module=log_referer \
--enable-module=mime \
--enable-module=negotiation \
--enable-module=status \
--enable-module=info \
--enable-module=include \
--enable-module=autoindex \
--enable-module=dir \
--enable-module=cgi \
--enable-module=asis \
--enable-module=imap \
--enable-module=actions \
--enable-module=userdir \
--enable-module=alias \
--enable-module=rewrite \
--enable-module=access \
--enable-module=auth \
--enable-module=auth_anon \
--enable-module=auth_db \
--enable-module=digest \
--enable-module=proxy \
--enable-module=expires \
--enable-module=headers \
--enable-module=usertrack \
--enable-module=setenvif
|
After configuration, make ran successfully in both build trees. A test SSL certificate was also made using "make certificate", as indicated in the README.
The Apache source code is required when building a mod_webapp module to connect to Tomcat 4 (Catalina). So if following these instructions don't throw the Apache build tree away just yet.
Apache needs further configuration through the httpd.conf file found in the deployed conf directory (as in /opt/apache/conf). The following local changes were made.
ZOIS's
ISP for further processing with the following ...
<IfModule mod_proxy.c>
ProxyRequests On
ProxyRemote * http://www-cache.demon.co.uk:8080
<Directory proxy:*>
Order deny,allow
Allow from all
</Directory>
CacheRoot "/var/cache/httpd"
CacheSize 5
CacheGcInterval 4
CacheMaxExpire 24
CacheLastModifiedFactor 0.1
CacheDefaultExpire 1
</IfModule>
|
Tomcat 4 (Catalina) is a set of Java binaries and some scripts. The installation of the system was therefore relatively trivial. Some changes were required post-install however, to allow interoperation with Apache and to allow Java Classes (programs) external to it to be executed.
As distributed Catalina expects normal HTTP connections on port 8080. This is an unfortunate choice, 8080 is recognized as the web-proxy port. Further, it was intended to run Tomcat via Apache, therefore this connection would not be required. The appropriate entry in Catalina's configuration file (conf/server.xml) was therefore commented out. To connect between Catalina and Apache a connector is necessary. It was decided to use mod_webapp, for this appears to be the replacement for mod_jk, the original way of doing this and the configuration of the connector appeared to be a good deal easier. Although the Apache web-site offers binary downloads for the DSO, these proved unworkable as they expected a later C library than the one that was installed on Red Hat Linux 6.2. You get this error message:
/lib/libc.so.6: version `GLIBC_2.2' not found
It is therefore necessary to build this from sources. The separate connectors download available from the source-download areas of the Apache web site contains the bulk of the code, but additional code needs to be obtained from the Concurrent Versions System (CVS) repository found at Apache. This is outlined in the build instructions found in the webapp build tree. Again Apache source is required so it's a good job you didn't throw it away. You will also need a reasonably uptodate libtool, a shell script used in managing shared libraries. This can be obtained from GNU[7]
The results of this effort, a binary version of this Red Hat 6.2 GLIBC_2.1 mod_webapp.so can be found on this site[8].
Once made, mod_webapp.so is installed in Apache's libexec directory and the following added to Apache's configuration file (conf/httpd.conf).
# Apache 1.3 - Tomcat 4 LoadModule webapp_module libexec/mod_webapp.so WebAppConnection warpConnection warp localhost:8008 WebAppDeploy examples warpConnection /examples WebAppDeploy tomcat-docs warpConnection /tomcat-docs WebAppDeploy test warpConnection /test # client demo. WebAppDeploy clientdemo warpConnection /clientdemo |
The WebAppDeploy directive links directory trees of JSP/Serverlets found in Catalina's webapps directory into the HTTP tree that your web-browser navigates.
With all installed the existing set up can be shutdown ...
/etc/rc.d/init.d/httpd stop sh /opt/tomcat/bin/shutdown.sh |
sh /opt/catalina/bin/startup.sh sleep 120 /opt/apache/bin/apachectl start |
The sleep was found to be necessary (and it needed to be two minutes) to allow communications to be established between Apache and Catalina. Catalina must be started before Apache, and if shutdown, Apache must be stopped and restarted after Catalina (with this two minute delay). Should this not be done then the Apache reports HTTP error 440, "Webapp not deployed" when an attempt is made to run JSPs.
Should the JSPs make reference to Java Archives and Classes outside Catalina, then modifications must be made to setclasspath.sh found in the Catalina bin directory (together with startup.sh and shutdown.sh). This script, as distributed resets the all important CLASSPATH variable prior to starting Catalina. The file can be modified itself either to include an external CLASSPATH or to set CLASSPATH appropriately for your application. The CLASSPATH variable, for those who don't know, is how Java Programs find libraries (Java Archives, or `jar' files) and subroutines (Classes).
We are currently experimenting with implementing connections
from Tomcat JSPs to Enterprise Java Beans running in newer JBoss EJB
Containers. When this work is completed it will be subject to a further
Technical Note.
Conclusion
The customer's Struts 1.0.2 based work could now be demonstrated. This
work, which featured a large amount of code complying with the later 2.3
Serverlet and 1.2 JSP specifications could only supported in Tomcat 4
(Catalina). Apache successfully communicates with Catalina and can use
SSL. Additional work is required to implement connections to Enterprise
Java Beans (EJBs) and this is ongoing.
References
$Date: 2009/12/06 11:13:23 $