Here's a quick writeup.
This is going to be a long reply, and I hope it will
be useful.
I am using Fedora Core 4 as a model. I hope it will
be close enough to RHEL 3 to be useful. You may have
to change paths in order to correspond to your
environment.
First of all, my environment:
Hardware/OS
===========
Dell 8200 with 768 MB memory
Dual boot:
Fedora Core 4 2.6.13-1.1526_FC4
Windows 2000 Professional
Software
========
Java 1.5.0_4 from Sun
Apache 2.0.54 from RPM
Tomcat 5.5.9 from jakarta.apache.org
mod_jk 1.2.14.1 from source
Installation
============
Java 1.5.0_4 is installed in /usr/jdk1.5.0_04 and soft
linked to /usr/java
JAVA_HOME is set in /etc/profile
$JAVA_HOME/bin is placed in $PATH before /usr/bin
I've left the Apache RPM install alone, which means
the following:
DocumentRoot /var/www
Logs /etc/logs soft linked to /var/log/httpd
modules /etc/modules soft linked to
/usr/lib/httpd/modules
conf /etc/conf
/etc/conf.d
I've created a tomcat user with the same group
membership as apache user. The home directory is
/home/tomcat.
/home/tomcat/jakarta-tomcat-5.5.9 Current Tomcat
installation
Configuration
=============
workers.properties
------------------
I've placed workers.properties in /etc/httpd/conf
#
# basic worker list
#
worker.list=local,status
#
# one to serve the applications
#
worker.local.type=ajp13
worker.local.host=localhost
worker.local.port=8009
#
# one to check the status
#
worker.status.type=status
worker.status.host=localhost
worker.status.port=8009
This is all you really need in order to connect a
local Apache to a local Tomcat.
I cannot think of a good reason to define more
workers. That isn't to say that there aren't any.
server.xml
----------
If you put multiple workers going to the same host and
different ports, then you will have to modify
server.xml. Basically, you will have to add a
connector statement for each unique port that you use
in your workers.properties file.
You have two different ports, so you will need two
connector statements.
<Connector port="10009"
enableLookups="false" redirectPort="8443"
protocol="AJP/1.3" />
<Connector port="8099"
enableLookups="false" redirectPort="8643"
protocol="AJP/1.3" />
jk.conf
-----------
I'm following the examples used by Fedora Core 4 in
configuring other add-on modules for Apache. You can
place the mod_jk configuration information directly in
/etc/httpd/conf/httpd.conf, but I've chosen to create
a separate file in /etc/httpd/conf.d
The contents of my file are as follows:
#
# following Fedora's add-on philosophy
#
LoadModule jk_module modules/mod_jk.so
JkWorkersFile /etc/httpd/conf/workers.properties
JkLogFile logs/mod_jk.log
JkLogLevel warn
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkShmFile logs/shm-file
#
# jk status
#
JkMount /jk-status/ status
httpd.conf
----------
Static File Problem
-------------------
This is where the configuration can become a little
more complex. It helps to understand how Apache finds
files to serve.
Each host in Apache has a DocumentRoot. In Redhat
Fedora, the line that defines that reads:
DocumentRoot "/var/www/html"
That means that when you enter the following URL:
http://localhost/application/
Apache will look for the DirectoryIndex files (usually
index.html) in:
/var/www/html/application/
This is fine until you add an application server into
the mix. Many people package up the entire
application into one war file. This means that all
static as well as dynamic content gets loaded into the
application server area.
In your case, that's
/usr/local/tomcat/jakarta-tomcat-5.5.9/webapps
Apache will know absolutely nothing about this
directory, and any files that are not mapped by
JkMount and served by Tomcat will not be found by
Apache
Static File Solutions
---------------------
1. Change DocumentRoot
The most global change is to change DocumentRoot. In
order for this to work, all files in
/usr/local/tomcat/jakarta-tomcat-5.5.9/webapps must be
readable by the user that runs Apache (typically
apache in a Redhat distribution).
The way to do this is to put the following as your
DocumentRoot statement.
DocumentRoot
"/usr/local/tomcat/jakarta-tomcat/webapps"
While this works, it means that you will have to place
all web sites in this location, even if they do not
have dynamic content.
In general, I don't like this solution.
2. Add Directory and Alias Statements
Traditionally locating static files in a dynamic web
site has been done by using a combination of Directory
and Alias directives. The Directory directive grants
appropriate server permissions (who gets to see the
files, etc.) and the Alias directive matches a
directory with a base URL.
For example, here's one way to map application1 living
in
/usr/local/tomcat/jakarta-tomcat/5.5.9/webapps/application1.
#
# This goes in httpd.conf
#
<Directory "/usr/local/tomcat/webapps/application1/">
Options Indexes FollowSymlinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
Alias /application1/
"/usr/local/tomcat/webapps/application1/"
#
# nice to block WEB-INF
#
<DirectoryMatch
"/usr/local/tomcat/webapps/*/WEB-INF/*">
AllowOverride None
Order allow,deny
Deny from all
</DirectoryMatch>
Now all static files in your
/usr/local/tomcat/jakarta-tomcat-5.5.9/webapps/application1
will be found by Apache. Until you set up JkMount
statements, all jsp pages will be served as source.
In general this works pretty well. The files in
/usr/local/tomcat/jakarta-tomcat/5.5.9/webapps must be
readable by the user that runs Apache.
3. Separate installations
If you use an IDE and ant to build your web
applications, you can set things up to build separate
war and zip (or tar) files. Put all the dynamic
(Tomcat) material in a war file, and put all the
static material in a tar or zip file.
You then install the tar or zip file in DocumentRoot,
and the war file in a appBase.
For example, if your DocumentRoot is /var/www/html and
your appBase is
/usr/local/tomcat/jakarta-tomcat-5.5.9/webapps, then:
a) install application1.tar in /var/www/html
b) install application1.war in
/usr/local/tomcat/jakarta-tomcat-5.5.9/webapps
Make sure that application1.tar explodes into
/var/www/html/application1
The dynamic portion of your web site will not be
available until you add the appropriate JkMount
statements.
One of the major advantages in this solution is that
it allows you to run Apache and Tomcat on separate
machines. While setting up the IDE and ant script to
create the appropriate builds may be challenging at
first, this setup creates a lot of installation
flexibility.
4. JkAutoAlias
JkAutoAlias is a relatively new configuration
directive
for mod_jk.
>From the documentation:
JkAutoAlias directive automatically Alias webapp
context directories into the Apache document space. It
enables Apache to serve a static context while Tomcat
serving dynamic context. This directive is used for
convenience so that you don't have to put an apache
Alias directive for each application directory inside
Tomcat's webapp directory.
So rather than setting up a Directory and Alias
directive for each application, you can use one
JkAutoAlias for the entire appBase.
In your environment, this would be:
JkAutoAlias
/usr/local/tomcat/jakarta-tomcat-5.5.9/webapps
Again, this directory must be readable by owner of the
Apache process.
This is a really nice solution and appears to inherit
all of the Directory settings of DocumentRoot.
Dynamic Files
-------------
Once you've made the choice as to how you map the
static files (probably 2 or 4 on a single host), you
will need to map dynamic content.
Simple JkMount statements work nicely.
If you have used Aliases or JkAutoAlias, the JkMount
statements need to occur after them. If you've moved
DocumentRoot, then the JkMount statements just need to
occur in the proper virtual host (or default host).
JkMounts for jsp and jspf files are pretty
straightforward. Usually all you need is:
JkMount /application1/*.jsp
JkKount /application1/*/*.jsp
Change the ending to jspf for files that end in jspf.
Servlets are a little more problematic. If you've
built a generic application and all of your servlet
mappings in web.xml are of the form:
/servlet/<servlet-name>
Then
JkMount /application1/servlet/*
will work for servlets in the /application1 context.
Struts applications have a slightly different
convention, in that all servlet mappings end in .do.
JkMount /application1/*.do
works.
This is by no means the complete story. The above
simple environment doesn't scale very well virtual
hosts. However, it should be a good start at
integrating Apache and Tomcat
HTH
/mde/
__________________________________
Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
