Working with mod_jk
By Gal Shachor <shachor@il.ibm.com>
Table of Contents
What is mod_jk?
mod_jk is a replacement to the elderly mod_jserv. It is a completely new
Tomcat-Apache plug-in that handles the communication between Tomcat and
Apache.
Why mod_jk?
Several reasons:
-
mod_jserv was too complex. Because it was ported from Apache/JServ,
it brought with it lots of JServ specific bits that aren't needed by Apache.
-
mod_jserv supported only Apache. Tomcat supports many web servers
through a compatibility layer named the jk library. Supporting two different
modes of work became problematic in terms of support, documentation and
bug fixes. mod_jk should fix that.
-
The layered approach provided by the jk library makes it easier to support
both Apache1.3.x and Apache2.xx.
-
Better support for SSL. mod_jserv couldn't reliably identify whether
a request was made via HTTP or HTTPS. mod_jk can, using the newer Ajpv13
protocol.
What does it mean to me?
You will need to get to know a new simplified configuration mechanism.
The advantage is that learning this mechanism will give you a head start
if you want to deploy Tomcat on Apache and other web servers, such as Microsoft's
Internet Information Server (IIS) and the iPlanet Enterprise Web Server.
Definitions and Terminology
In this document I am going to use a few terms, so let's define them:
| Term |
Meaning |
| Worker Process |
A worker is a tomcat instance that is running to serve
servlet requests coming from the web server. In most cases there is only
a single worker (the one and only tomcat process) but sometimes you will
run multiple workers to achieve load balancing or site partitioning. Each
worker is identified to the web server by the host were it is located,
the port where it listens and the communication protocol used to exchange
messages. |
| In-Process Worker |
This is a special worker. Instead of working with
a Tomcat process residing on another process, the web server opens a JVM
and executes Tomcat inside the web server process address space. Our discussion
in this document is not going to get into this special worker. |
| Web Server Plug-in/Tomcat Redirector |
For Tomcat to cooperate with any web server it needs
an "agent" to reside in the web server and send him servlet requests. This
is the web server plug-in, and in our case the web server plug-in is mod_jk.
The redirector usually comes in the shape of a DLL or shared object module
that you plug into the web server. |
| Plug-in Configuration |
We need to configure the web server plug-in so that
it knows where the different Tomcat workers are and to which of them it
should forward requests. This information, accompanied with some internal
parameter, such as the log level, comprises the plug-in configuration. |
| Web Server Configuration |
Each web server has some configuration that defines
its behavior, e.g. on which port to listen, what files to serve, what web
server plug-ins to load, etc. You will need to modify your web server configuration
to instruct it to load the Tomcat redirector mod_jk. |
Obtaining mod_jk
mod_jk can be obtained in two formats - binary and source. Depending
on the platform you are running your web server on, a binary version of
mod_jk may be available. It is recommended to use the binary version
if one is available. If the binary is not available, follow the instructions
for building mod_jk from source. Notes at the end of this section
offer recommendations for specific platforms.
mod_jk Binaries
Binaries for mod_jk are available for several platforms in the same area
as the Tomcat Binary Release. The binaries are located in subdirectories
by platform. For some platforms, such as Windows, this is the typical
way of obtaining mod_jk since most Windows systems do not have C compilers.
For others, the binary distribution of mod_jk offers simpler installation.
For example, the Tomcat 3.3 Release at
http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.3/bin/
contains the following:
| linux/i386 |
Contains mod_jk.so for Apache 1.3 for the standard API
as well as EAPI and mod_jk.so for Apache 2.0 |
| netware/i386 |
Contains the mod_jk.nlm and nsapi.nlm |
| win32/i386 |
Contains the mod_jk.dll for Windows as well as other useful
binaries. |
Check the site for the latest binaries.
Note: The version of mod_jk is not dependent on the version of Tomcat.
The Tomcat 3.3 distribution of mod_jk will function correctly with other
3.x versions of Tomcat, such as Tomcat 3.2.1.
Building mod_jk
mod_jk is available in source distribution for all Windows and most Unix
platforms. The source for mod_jk is included in the Binary Distribution
of Tomcat in the TOMCAT_HOME/native/mod_jk/ directory. This directory
is organized by Web Server name and version. Each directory contains
the source as well as the appropriate build scripts, make files, or project
files.
Building mod_jk for NT
The redirector was developed using Visual C++ version 6.0, so having this
environment is a prerequisite if you want to perform a custom build.
The steps that you need to take are:
-
Change directory to the apache1.3 or apache2.0 source directory depending
on your version of Apache.
-
Set an APACHE1_HOME environment variable which points to where your Apache
is installed.
-
Execute the following command:
MSDEV mod_jk.dsp /MAKE ALL
If msdev is not in your path, enter the full path to msdev.exe. Also,
ApacheCore.lib is expected to exist in the APACHE1_HOME\src\Debug or APACHE1_HOME\src\Release
(or the older APACHE1_HOME\src\CoreD or APACHE1_HOME\src\CoreR)
directories before linking will succeed. You will need to build enough
of the Apache source to create the required librarie(s).
-
Copy mod_jk.dll to Apache's modules directory.
This will build both release and debug versions of the redirector plug-in
(mod_jk).
An alternative will be to open mod_jk.dsp in msdev and build
it using the build menu.
Building mod_jk for Unix
Apache
-
Make sure your Apache has DSO support. You can check this with $APACHE_HOME/bin/httpd
-l. If you see "mod_so.c" in the output, DSO support is available.
If it's missing, you may have to recompile or reinstall Apache.
-
Find out whether your Apache has EAPI support. If you compiled it yourself
from source, EAPI is probably not compiled in, unless you added it yourself
(perhaps with mod_ssl). You need to build mod_jk.so with or without EAPI
to match your Apache configuration. If you install a mismatched mod_jk.so,
$APACHE_HOME/bin/apachectl configtest will warn you.
-
Make sure you have Perl 5 installed. The apxs script used to build
the module is written in Perl.
-
Change directory to TOMCAT_HOME/native/mod_jk/apache1.3 (or apache2.0).
Build mod_jk.so. Following are three techniques you can try, in
order of simplicity:
-
Run the build script for your platform. If a build script is not
available for your platform, you may be able to build mod_jk using ./build-unix.sh.
This script will set some variables, call apxs as below, and try
to copy mod_jk.so to $APACHE_HOME/libexec. If it fails, you need to do
the following manually:
-
set JAVA_HOME in your shell, e.g. "set JAVA_HOME=/usr/local/jdk1.3.1;
export JAVA_HOME"
-
set APACHE_HOME in your shell, e.g. "set APACHE_HOME=/usr/local/apache;
export APACHE_HOME"
-
uncomment the following line in the build-unix.sh file, replacing
"linux" with the name of your platform as specified in the Java include
directory for your installation
# JAVA_INCLUDE="-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/linux"
-
If build-unix.sh fails, you may have better luck with the Makefiles in
the same directory, e.g. "make -f Makefile.linux mod_jk.so"
Finally, you can try to build it manually. Run the apxs
command that came with your apache distribution (hint: look in /usr/local/apache/bin,
/usr/sbin, or wherever you installed apache). Type the command all on one
line.
For Linux:
apxs -o mod_jk.so -I../jk -I/usr/local/jdk/include -I/usr/local/jdk/include/linux
-c *.c ../jk/*.c
Your build may fail because the object files from the ../jk directory
have been compiled to the current directory, rather than their source directory.
Running gcc -shared -o mod_jk.so *.o should finish the build.
For Solaris:
Use the build-solaris.sh script as follows:
# sh build-solaris.sh
This will build and install mod_jk.so in your apache/libexec directory.
This script contains settings for your Java and Apache home locations.
Make sure that these are set according to your installation. The
default settings are JAVA_HOME=/usr/java and APACHE_HOME=/usr/local/apache.
If your installation is different, you will need to edit the build-solaris.sh
script and change these values appropriately.
See README.solaris located in TOMCAT_HOME/native/mod_jk/apache1.3
for more information.
If the build script does not work, you can also build mod_jk as follows:
$APACHE_HOME/bin/apxs -o mod_jk.so -DSOLARIS -I../jk -I/usr/java/include
-I/usr/java/include/solaris -c *.c ../jk/*.c
For HP-UX 11.00:
Use the build-hpux.sh script as follows:
# sh build-hpux.sh
This will build and install mod_jk.so in your apache/libexec directory.
This script contains settings for your Java and Apache home locations.
Make sure that these are set according to your installation. The
default settings are JAVA_HOME=/opt/java1.3 and APACHE_HOME=/usr/local/apache.
If your installation is different, you will need to edit the build-hpux.sh
script and change these values appropriately.
Also note that there are two HP-UX build scripts. One script was
written to build mod_jk without JNI support using GNU GCC. The other
script builds mod_jk with JNI support, however, this script requires the
HP ANSI C Compiler (not the stripped down C compiler included with HP-UX
to rebuild the kernel). The HP Compiler is required because the dlopen()
and related shared libraries are only available for 64-bit applications
and reliable 64-bit compilation is not available with the current version
of GCC.
The build-hpux.sh script should also work for HP-UX 10.00.
See README.hpux located in TOMCAT_HOME/native/mod_jk/apache1.3
for more information.
For other Unixes (including FreeBSD):
The build-hpux-cc.sh script should be modifiable for IRIX and
AIX. Edit the script and change the APACHE_HOME and JAVA_HOME locations
as required.
If you are using EAPI, try adding -DEAPI to the apxs command
after mod_jk.so.
If apxs fails with apxs:Break: Command failed with rc=255,
it may have been damaged by mod_ssl. Search for:
my $CFG_LD_SHLIB = q(); # substituted via Makefile.tmpl
my $CFG_LDFLAGS_SHLIB = q(); # substituted via Makefile.tmpl
and change to:
my $CFG_LD_SHLIB = q(ld); # substituted via Makefile.tmpl
my $CFG_LDFLAGS_SHLIB = q(-G); # substituted via Makefile.tmpl
If you've installed Java in another directory, adjust accordingly.
For other Unixes you should be able to work it out, but remember that
the order of the arguments to apxs is important!.
-
Now, copy the mod_jk library. # cp mod_jk.so $APACHE_HOME/libexec.
(Note that the build scripts attempt to do this, but you may have to su
first.)
Other Webservers
There are several Makefiles in the other directories under the TOMCAT_HOME/native/mod_jk/
directory. You should also check the Tomcat documentation for specific
information related to other web servers.
Configuring Apache
This section details the configuration that is required for the Apache
Web Server to support mod_jk.
Removing mod_jserv directives
If you've previously configured Apache to use mod_jserv,
remove any ApJServMount directives from your httpd.conf. If you're
including tomcat-apache.conf or tomcat.conf, you'll want
to remove them as well - they are specific to mod_jserv. The mod_jserv
configuration directives are not compatible with mod_jk!
Configure Apache to use mod_jk
The simplest way to configure Apache to use mod_jk
is to use Tomcat to generate the mod_jk configuration file and put the following
include directive at the end of your Apache httpd.conf file (make sure
you replace TOMCAT_HOME with the correct path for your Tomcat installation:
Include TOMCAT_HOME/conf/auto/mod_jk.conf
Example:
Include /usr/local/jakarta-tomcat/conf/auto/mod_jk.conf
This will tell Apache to use directives in the mod_jk.conf file
in the Apache configuration. This file is created by starting Tomcat
with the "jkconf" option. Tomcat will initialize, write the
configuration file and then exit. This may be done while an instance of Tomcat
is running. Options for controlling how the mod_jk configuration file is
generated are described in the configuring Tomcat section
below [Configuring Tomcat].
NOTE: If you plan to use the Tomcat generated configuration,
skip the rest of this section and continue with the Configuring
Tomcat section.
Custom configurations can be created by enabling the auto-configuration
and copying the TOMCAT_HOME/conf/auto/mod_jk.conf file to your
own configuration file, such as TOMCAT_HOME/conf/jk/mod_jk.conf.
The basic configuration is as follows:
-
You will need to instruct Apache to load Tomcat. This can be done with
Apache's LoadModule and AddModule configuration directives.
-
You must inform mod_jk the location of your workers.properties
file. Use mod_jk's JkWorkersFile configuration directive.
-
You should specify a location where mod_jk is going to place its log file
and a log level to be used. Use the JkLogFile and JkLogLevel
configuration directives. Possible log levels are debug, info,
error and emerg. If the JkLogLevel is not specified,
no log is generated.
-
The directive JkLogStampFormat will configure the date/time format
found on mod_jk logfile. Using strftime() format string it's set
by default to "[%a %b %d %H:%M:%S %Y] "
A simple example would be to include the following lines in your
httpd.conf
file:
LoadModule jk_module libexec/mod_jk.so
AddModule mod_jk.c
JkWorkersFile /usr/local/jakarta-tomcat/conf/workers.properties
JkLogFile /usr/local/apache/logs/mod_jk.log
JkLogLevel info
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
Assigning URLs to Tomcat
If you have created a custom or local version of
mod_jk.conf as noted above, you can change settings such
as the workers or URL prefix.
Use mod_jk's JkMount directive to assign specific URLs to Tomcat. In
general the structure of a JkMount directive is:
JkMount <URL prefix> <Worker name>
For example the following directives will send all requests ending in
.jsp
or beginning with
/servlet to the "
ajp13" worker, but
jsp requests to files located in /otherworker will go to "
remoteworker".
JkMount /*.jsp ajp13
JkMount /servlet/* ajp13
JkMount /otherworker/*.jsp remoteworker
You can use the
JkMount directive at the top level or inside
<VirtualHost>
sections of your httpd.conf file.
Configuring Tomcat
Enabling Tomcat's Apache Auto-Config
In most simple cases Tomcat can generate the needed
Apache configuration. The default installation of Tomcat comes configured to
generate a configuration file on demand for Apache to use mod_jk.
Most of the time you don't need to do anything but include this file (appending
"Include TOMCAT_HOME/conf/auto/mod_jk.conf") in your httpd.conf,
as shown in the previous section (
Configuring Apache).
To have Tomcat generate the configuration file, start Tomcat with the
"jkconf" option. Tomcat will initialize, write the configuration
file, and then exit. This may be done while an instance of Tomcat is running.
The generation of the mod_jk configuration file is controlled by the
ApacheConfig module. The default
installation of Tomcat 3.3 comes with the ApacheConfig directive already
present in the TOMCAT_HOME/conf/server.xml.
Note: Generating the mod_jk configuration file on demand is new in Tomcat 3.3.
Older versions of Tomcat create the auto-config file without a directive
in server.xml and generate it each time Tomcat is started.
The new ApacheConfig directive in Tomcat 3.3 allows for additional
configuration options as detailed later in this section. For older
versions of Tomcat, refer to the documentation that came with that version.
If you have special needs, for example mounting URL prefixes that are
not the default, you can use this file as a base for your customized configuration
and save the results in another file. If you manage the Apache configuration
yourself you'll need to update it whenever you add a new context.
Note that you must restart tomcat and apache after adding a new context;
Apache doesn't support configuration changes without a restart. Also the
file TOMCAT_HOME/conf/auto/mod_jk.conf is generated when tomcat
starts, so you'll need to start Tomcat before Apache. Tomcat will overwrite
TOMCAT_HOME/conf/auto/mod_jk.conf each startup so customized
configuration should be kept elsewhere. For example, copy
TOMCAT_HOME/conf/auto/mod_jk.conf
to TOMCAT_HOME/conf/jk/mod_jk.conf
before making changes.
You'll need to start Tomcat with the "jkconf" option once to generate
this file with your configuration for the first time.
It is also possible to specify the location of the auto generated files
by setting options in the <ApacheConfig /> block. The following
details the syntax:
< ContextManager ... >
...
<ApacheConfig options />
...
< /ContextManager >
where
options can include any of the following attributes:
- configHome - default parent directory for the following paths.
If not set, this defaults to TOMCAT_HOME. Ignored
whenever any of the following paths is absolute.
- jkConfig - path to use for writing Apache mod_jk conf file. If
not set, defaults to "conf/auto/mod_jk.conf".
- workersConfig - path to workers.properties file used by
mod_jk. If not set, defaults to "conf/jk/workers.properties".
- modJk - path to Apache mod_jk plug-in file. If not set,
defaults to "modules/mod_jk.dll" on windows,
"modules/mod_jk.nlm" on netware, and
"libexec/mod_jk.so" everywhere else.
- jkLog - path to log file to be used by mod_jk.
- jkDebug - JK Loglevel setting. May be debug, info, error, or emerg.
If not set, defaults to no log.
- jkWorker The desired worker. Must be set to one of the workers
defined in the workers.properties file. "ajp12", "ajp13"
or "inprocess" are the workers found in the default
workers.properties file. If not specified, defaults to "ajp13"
if an Ajp13Connector is in use, otherwise it defaults to "ajp12".
- forwardAll - If true, forward all requests to Tomcat.
This helps ensure that all the behavior configured in the web.xml
file functions correctly. If false, let Apache serve static resources.
The default is true. Warning: When false, some configuration in
the web.xml may not be duplicated in Apache.
Review the mod_jk conf file to see what
configuration is actually being set in Apache.
- noRoot - If true, the root context is not mapped to
Tomcat. If false and forwardAll is true, all requests
to the root context are mapped to Tomcat. If false and
forwardAll is false, only JSP and servlets requests to
the root context are mapped to Tomcat. When false,
to correctly serve Tomcat's root context you must also
modify the DocumentRoot setting in Apache's httpd.conf
file to point to Tomcat's root context directory.
Otherwise some content, such as Apache's index.html,
will be served by Apache before mod_jk gets a chance
to claim the request and pass it to Tomcat.
The default is true.
Example:
...
<ApacheConfig configHome="/home/mydir" />
...
Note: The default mod_jk configuration file generated by:
<ApacheConfig />
differs from the file generated by Tomcat 3.2.x. In Tomcat 3.3, the default
is to forward all requests to Tomcat for Tomcat's contexts (i.e.
forwardAll="true"), excluding the root context. This helps ensure
that behavior configured in web.xml files will function properly.
The configuration that best matches Tomcat 3.2.x behavior is:
<ApacheConfig forwardAll="false" noRoot="false"
jkConfig="conf/mod_jk.conf-auto" jkDebug="error" />
With this configuration, JSP and servlet requests to the root context
will be served from Tomcat's ROOT webapp. Other requests, such as for static
files, will be served from Apache's DocumentRoot directory. If Apache's
DocumentRoot isn't updated to point to Tomcat's ROOT webapp, then the
root context will malfunction. For example, JSP's that reference ".gif"
files in Tomcat's ROOT webapp will not be able to display them since
they won't be found under Apache's DocumentRoot directory.
(Optional) Configuring Tomcat to use the Ajpv13 protocol
mod_jk can use either the original Ajpv12 protocol
or the newer Ajpv13 protocol. Both protocols are enabled by default. The
"Ajp13" Connection Handler in Tomcat will give you the benefit of a faster
protocol and the ability to identify requests made via HTTPS.
The default installation of Tomcat 3.3 comes with connectors for both
protocols in the TOMCAT_HOME/conf/server.xml. The default choice by
the ApacheConfig directive will be to using the "ajp13" worker which
uses the Ajpv13 protocol. Even though mod_jk uses the Ajpv13 by default, you
shouldn't remove the Ajpv12 connector present in the server.xml file.
The Ajpv12 connector is also used for shutting down Tomcat.
(Optional) Defining "workers"
Configuring workers manually.
Workers are configured using the file
TOMCAT_HOME/conf/jk/workers.properties.
There is a great deal of information in the
workers.properties
howto document, and you should really look at that first. If you're
in a hurry however, you can probably get away with editing the file
workers.properties
and setting the
workers.tomcat_home,
workers.java_home
and
ps variables to the correct values for your system.
Example Configuration
Here's an example configuration which probably reflects many real-world
setups. A site is using Tomcat and Apache with two virtual hosts (one of
them using HTTPS as well, which we're assuming is being handled by mod_ssl).
URLs ending in .jsp and beginning with /servlet are handled by Tomcat,
the rest are handled by Apache. The files for each Host are server out
of /web/host1 and /web/host2 respectively.
The example are over-simplified and incomplete but should get you started.
Also note, this form virtual host setup is new in Tomcat 3.3 and later - this example
won't work with Tomcat 3.2 and earlier..
.
.
<Ajp12Connector port="8007" />
<Ajp13Connector port="8009" />
.
|
Table 1 - Excerpt from server.xml showing the Ajp12 and Ajp13 Connectors.
<?xml version="1.0" encoding="ISO-8859-1"?>
<Server>
<Host name="host1.apache.org">
<Context path="" docBase="/web/host1" debug="0"/>
</Host>
<Host name="host2.apache.org">
<Context path="" docBase="/web/host2" debug="0"/>
</Host>
</Server>
|
Table 2 - Apps-vhosts.xml file showing two virtual hosts, each with a default
context defined.
# Setup for Solaris system
#
workers.tomcat_home=/usr/local/jakarta-tomcat
workers.java_home=/usr/java
ps=/
worker.list=ajp12, ajp13
# Definition for Ajp13 worker (Ajp12 left to readers imagination)
#
worker.ajp13.port=8009
worker.ajp13.host=localhost
worker.ajp13.type=ajp13
|
Table 3 - Excerpt from workers.properties showing the Ajp13 worker
# Load mod_jk
#
LoadModule jk_module libexec/mod_jk.so
AddModule mod_jk.c
# Configure mod_jk
#
JkWorkersFile /usr/local/jakarta-tomcat/conf/jk/workers.properties
JkLogFile /usr/local/apache/logs/mod_jk.log
JkLogLevel info
# First Virtual Host.
#
<VirtualHost 10.0.0.1:80>
DocumentRoot /web/host1
ServerName host1.apache.org
JkMount /*.jsp ajp13
JkMount /servlet/* ajp13
</VirtualHost>
# Second Virtual Host. Also accessible via HTTPS
#
<VirtualHost 10.0.0.2:80>
DocumentRoot /web/host2
ServerName host2.apache.org
JkMount /*.jsp ajp13
JkMount /servlet/* ajp13
</VirtualHost>
<VirtualHost 10.0.0.2:443>
DocumentRoot /web/host2
ServerName host2.apache.org
SSLEngine On
JkMount /*.jsp ajp13
JkMount /servlet/* ajp13
</VirtualHost>
|
Table 4 - Excerpt from Apaches httpd.conf showing JK directives.
Troubleshooting and F.A.Q.s
Q. Where can I get help/support for mod_jk?
A. The primary mechanism for support is through the Tomcat Documentation
included in the TOMCAT_HOME/doc directory. These documents are viewable
via browser through Tomcat http://localhost:8080/doc/index.html.
Documentation is also available on the Apache Jakarta web site for Tomcat
at http://jakarta.apache.org/tomcat/tomcat-3.3-doc/index.html.
For additional help, the best resource is the Tomcat Users Discussion
list. You should start by searching the mail list archives located
at http://www.mail-archive.com/tomcat-user@jakarta.apache.org/
or http://mikal.org/interests/java/tomcat/index.jsp
before you post questions to the list. If you are unable to locate
the answer to your question in the archive, you can post questions about
Tomcat or mod_jk to the user list for assistance. Make sure that
you include the version of Apache and Tomcat that you are using as well
as the platform you are running on. http://jakarta.apache.org/site/mail.html
Q. I can't find mod_jk anywhere. Where is it?
A. Starting with Tomcat 3.3, the source for mod_jk is included with the
binary distribution, in the native/mod_jk
directory. You can also download the Source Distribution of Tomcat
to obtain the source for mod_jk, which is how it was obtained in versions
prior to Tomcat 3.3. The Binary Distributions of mod_jk are available at
the same location as the Binary Distribution of Tomcat. The mod_jk
binaries are located in subdirectories by platform. But in May 2001, the
jakarta-tomcat-connectors was started and you'll find here up to date featured
mod_jk (ie: new protocols AJP14/WARP)
Q. Which protocol should I use? Ajp12 or Ajp13?
A. Ajp13 is a newer protocol, it's faster, and it works better with SSL.
You almost certainly want to use it. There is more information in the
workers.properties
howto document.
Q. Whenever I restart Tomcat, Apache locks up!
A. The Ajp13 protocol keeps an open socket between Tomcat and Apache. The
latest release of mod_jk (the one found since Tomcat 3.3-m2 and J-T-C)
handle the network failure. But with previous release of mod_jk, you may
have to restart Apache as well.
Q. Why do two mod_jk.so files exist (-eapi ad -noeapi) in download dir
for Linux ?
A. Many versions of Apache use a modified API, known at Extended API.
For example, Apache using mod_ssl and the Apache present in certain recent
Linux distributions. So if you have an 'Extended Apache', you need to
use mod_jk.so-eapi, and use mod_jk.so-noeapi for standard Apache. It's wise
to avoid using EAPI modules on standard API Apache and standard API modules
on EAPI Apache. Always be sure to have the mod_jk.so for your version
of Apache.
Q. What's that message about 'garbled DSO ?'
A. It's related to Apache EAPI. The message 'mod_jk.so is garbled - perhaps
this is not an Apache module DSO ?' just told you are trying to install
a mod_jk.so DSO module that was compiled on an Apache using EAPI, such as
Apache-mod_ssl or Apache from Redhat distro 6.2/7.0. However, your system is using
the standard Apache with the normal API.
Q. And the message about 'module might crash under EAPI! '
A. Also related to EAPI, the message '[warn] Loaded DSO /usr/lib/apache/mod_jk.so
uses plain Apache 1.3 API, this module might crash under EAPI! (please
recompile it with -DEAPI)', the mod_jk.so was compiled under normal Apache
with standard API and you are trying to install the module on an Apache using
EAPI.
Q. Where can I get more information?
A. The workers.properties howto
document has considerably more in-depth information than this one, and
is worth a look. You could also try searching the mailing list archives
for "mod_jk" or look at the source.
Q. APXS is getting an error during the build of mod_jk, like rc=0 or rc=255.
I tried all of the steps in the build section, what do I do now?
A. APXS is a Perl script that is created when you build the Apache web
server from source. Chances are that if you are getting these errors
and you obtained Apache as a binary distribution, that APXS is not configured
correctly for your system. Your best bet is to get the Apache source
from http://httpd.apache.org and
build it yourself. Use the following for a basic build (read the
Apache docs for other options):
# cd /usr/local/src
# gzip -dc apache_1.3.19.tar.gz|tar xvf -
# cd apache_1.3.19
# ./configure --prefix=/usr/local/apache \
--enable-module=most \
--enable-shared=max
# make
# make install
Note: The above steps assume that you downloaded the Apache source and
placed it in your /usr/local/src directory.
Q. Why doesn't my form authentication work? I'm getting similar error messages
from Apache:
Not Found
The requested URL /login/j_security_check was not found on this server.
|
A. If you used manual configuration such as:
or
mod_jk will pass requests for all JSP or Velocity pages to Tomcat. If form
authentication is configured like this:
<login-config>
<auth-method>FORM</auth-method>
<realm-name>Protected</realm-name>
<form-login-config>
<form-login-page>/login/login.vm</form-login-page>
<form-error-page>/login/error.vm</form-error-page>
</form-login-config>
</login-config>
|
then there is also another, somewhat hidden request involved in the
authentication process: /login/j_security_check. It is the
'action' of the form specified within login.vm and
error.vm, usually:
<form method="post" action="j_security_check">
|
The request /login/j_security_check is not mapped, therefore
mod_jk doesn't know that it should pass it to Tomcat. The following fixes the
problem:
JkMount /*.vm ajp13
JkMount /login/j_security_check ajp13
|
Credits
This document was originally created by
Gal
Shachor
Revisions by (Alphabetical)
Mike Braden <mikeb@mwbinc.com>
Mike Bremford
Chris Pepper
With help from countless others on the tomcat-dev and tomcat-user lists!