The JK Connector |  |
| Introduction |
The JK Connector is a web server component used to
invisibly integrate Tomcat
with a web server such as Apache or IIS.
Communication between the web server and Tomcat is via the JK
protocol (also known as the AJP protocol).
Tomact is usually integrated with a web server in cases where you want
the web server to handle the static content contained in the web application,
and/or utilize the web server's SSL processing. In many application
environments, this will result in better overall performance than running
your applications under Tomcat stand-alone using the
Coyote HTTP/1.1 Connector. However, the only way to know for sure whether
it will provide better performance for your application is
to try it both ways.
|
| Configuration HOWTOs |
| Apache |
| Introduction |
This section explains how to connect Tomcat 4 to the popular
open source web server, Apache. It was originally part of
Tomcat: A Minimalistic User's Guide by Gal Shachor, but
has been split off for organizational reasons. It should be
considered a work in progress. Since the Tomcat source
tree is constantly changing, the information herein may be out
of date. The only definitive reference at this point is the source
code.
|
| Installation |
| Needed Components |
In a nutshell a web server is waiting for client HTTP requests.
When these requests arrive the server does whatever is needed to
serve the requests by providing the necessary content. Adding a
servlet container may somewhat change this behavior. Now the web
server needs also to perform the following:
- Load the servlet container adapter library
and initialize it (prior to serving requests).
- When a request arrives, it needs to check and see if a certain
request belongs to a servlet, if so it needs to let the adapter
take the request and handle it.
The adapter on the other hand needs to know what requests it is
going to serve, usually based on some pattern in the request URL,
and to where to direct these requests.
Things are even more complex when the user wants to set
a configuration that uses virtual hosts, or when they want multiple
developers to work on the same web server but on different servlet
container JVMs. We will cover these two cases
in the advanced sections.
|
| mod_jk Terminology |
The following terms are used in this section:
- 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. Note: Tomcat 4 can't be run as this type of
worker at the moment.
- 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 Tomcat 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 parameters, 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.
|
| Getting mod_jk |
The mod_jk source now resides in the jakarta-tomcat-connectors
subproject. Please refer to it for build instructions.
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.
Note: 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 Tomcat 4.x and other 3.x versions of
Tomcat, such as Tomcat 3.2.1.
|
| Configuring Apache |
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!
Like Tomcat 3, Tomcat 4 can automatically generate the
necessary $CATALINA_HOME/conf/mod_jk.conf,
but it can also be created manually. Note that Tomcat
and Apache must be restarted after adding a new context.
See the "Using ApacheConfig" section for more details.
Basic configuration
- 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] "
- 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. You can use the
JkMount directive at the top level or inside <VirtualHost>
sections of your httpd.conf file.
- The directive JkRequestLogFormat (Apache 1.3 only)
will configure the format of mod_jk
individual request logging. Request logging is configured and enabled on a per
virtual host basis. To enable request logging for a virtual host just add
a JkRequestLogFormat config.
The syntax of the format string is similiar to the Apache LogFormat command,
here is a list of the avaialbe request log format options:
- %b - Bytes sent, excluding HTTP headers. In CLF format
- %B - Bytes sent, excluding HTTP headers.
- %H - The request protocol
- %m - The request method
- %p - The canonical Port of the server serving the request
- %q - The query string (prepended with a ? if a query string exists,
otherwise an empty string)
- %r - First line of request
- %s - request HTTP status code
- %T - Requset duration, elapsed time to handle request in seconds '.'
micro seconds
- %U - The URL path requested, not including any query string.
- %v - The canonical ServerName of the server serving the request.
- %V - The server name according to the UseCanonicalName setting.
- %w - Tomcat worker name
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-local
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 with /servlet as the second path componenet 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 Apache to serve static web application files
If the Tomcat Host appBase (webapps) directory is accessible by the Apache
web server, Apache can be configured to serve web application context directory
static files instead of passing the request to Tomcat.
Caution: If Apache is configured to serve static pages for a web
application it bypasses any security contraints you may have configured in
your web application web.xml config file.
Use Apache's Alias directive to map a single web application context directory
into Apache's document space for a VirtualHost:
# Static files in the examples webapp are served by apache
Alias /examples /export/home/web/host1/webapps/examples
JkMount /*.jsp ajp13
JkMount /*/servlet/ ajp13
Use the mod_jk JkAutoAlias (Apache 1.3 only) directive to map all web application context
directories into Apache's document space. Attempts to access the WEB-INF
or META-INF directories within a web application context or a
Web Archive *.war within the Tomcat Host appBase (webapps) directory
will fail with an HTTP 403, Access Forbidden.
Example configuration for an Apache VirtualHost:
# Static files in all Tomcat webapp context directories are served by apache
JkAutoAlias /export/home/web/host2/webapps
JkMount /*.jsp ajp13
JkMount /*/servlet/ ajp13
|
| Configuring Tomcat |
Tomcat 4 can be configured to automatically generate the Apache
configuration file. The next section describes how to enable
this option.
After enabling the AJP 1.3 connector, you need to define workers,
using a $CATALINA_HOME/conf/workers.properties file.
In most cases, using the example workers.properties given below
should work fine, after changing the path values to reflect how your
environment is set up.
|
| Using ApacheConfig |
Tomcat 4 provides extra flexability over Tomcat 3 in setting up
the automatic generation of the Apache configuration file.
However, this comes at the cost of a bit more complexity. Each
time that Tomcat is started, it will write the configuration file
to $CATALINA_HOME/conf/auto/mod_jk.conf. You can
then either
| | | | Include $CATALINA_HOME/conf/auto/mod_jk.conf | | | | |
httpd.conf file.
To generate the global Apache directives (e.g.
LoadModule, JkLogFile), you define a
Server Listener:
| | | |
<Server port="8005" shutdown="SHUTDOWN" debug="0">
<Listener className="org.apache.ajp.tomcat4.config.ApacheConfig" />
...
| | | | |
To configure the individual context information, you then either
define a Host Listener or a Context
Listener depending on if you are using virutal hosting or not.
Defining a Host Listener will generate the Apache
<VirtualHost> directive and include all of
the configurations for the Contexts under this host.
Using the Context Listener allows you the flexability
to configure the Context the same way even if it
is being served from several hosts.
Except for the placement of the <Listener ...>,
the syntax is virtualy identical for the Host
Listener and the Context Listener. The examples that
follow will demonstrate the functionality for a Host
Listener. The simplest configuration is:
| | | |
<Host name="localhost" debug="0" appbase="webapps" >
<Listener className="org.apache.ajp.tomcat4.config.ApacheConfig"
append="true" />
| | | | |
It is possible to modify the output configuration file with the
following attributes:
| Attribute | Description |
|---|
configHome |
Default parent directory for the following paths. If not set, this
defaults to CATALINA_HOME. Ignored whenever any of the following
paths is absolute
| jkConfig |
Path to write apacke mod_jk conf file to. 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 plugin 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. "ajp13" or "inprocess" are
the workers found in the default workers.properties file. If not
specified, defaults to "ajp13".
| 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. | append |
Append to the current configuration file.
|
|
|
|
| IIS 4.x and 5.x |
| Introduction |
This section explains how to set up IIS 4.0 or newer to cooperate
with Tomcat 4. Normally IIS cannot execute Servlets and Java Server
Pages (JSPs), configuring IIS to use Tomcat redirector plugin
will allow IIS to redirect Servlet and JSP requests to Tomcat.
The Tomcat redirector for IIS is composed of four entities:
- isapi_redirect.dll - The IIS server plugin, either obtain a
pre-built DLL or build it yourself (see the build section).
- worker.properties - A file that describes the host(s) and
port (s) used by the workers (Tomcat processes).
- uriworkermap.properties - A file that maps URL-Path patterns
to workers.
- iis_redirect.reg - A file that creates registry entries
in the Windows registry.
|
| Installation |
Make sure the Tomcat AJP connector is properly declared in the
Catalina configuration file.
Download isapi_redirect.dll for Tomcat 3.3 release or use the
following
link.
You can then either manually define a few extra configuration files
(read below), or use the automatic IISConfig to have Tomcat generate
them for you (see next section).
The next step is to create worker.properties to help
isapi_redirect.dll to identify where to find Tomcat and its
configuration.
Next, the ISAPI filter for Tomcat must be configured to redirect
requests for specific webapps to Tomcat.
Then the uriworkermap.properties file must be created
in %CATALINA_HOME%\conf directory.
Note: See below for examples of the configuration files. Those
configuration files assume Tomcat is installed in the
c:\jakarta-tomcat-4.0.1 directory.
|
| Using IISConfig |
Tomcat 4 provides extra flexability over Tomcat 3 in setting up
the automatic generation of the IIS configuration file.
However, this comes at the cost of a bit more complexity. Each
time that Tomcat is started, it will write the configuration file
to %CATALINA_HOME%/conf/auto/uriworkersmap.properties.
If enabled as a Server Listener, it will also write
the required registry entries to
%CATALINA_HOME%/conf/auto/iis_redirect.reg. You may
enter the settings into the registry by double-clicking on this
file from the Windows Explorer.
To generate the global IIS directives (including the registry file),
you define a Server Listener:
| | | |
<Server port="8005" shutdown="SHUTDOWN" debug="0">
<Listener className="org.apache.ajp.tomcat4.config.IISConfig" />
...
| | | | |
To configure the individual context information, you then either
define a Host Listener or a Context
Listener depending on if you are using virutal hosting or not.
Defining a Host Listener will include all of
the configurations for the Contexts under this host.
Using the Context Listener allows you the flexability
to configure the Context the same way even if it
is being served from several hosts.
Except for the placement of the <Listener ...>,
the syntax is virtualy identical for the Host
Listener and the Context Listener. The examples that
follow will demonstrate the functionality for a Host
Listener. The simplest configuration is:
| | | |
<Host name="localhost" debug="0" appbase="webapps" >
<Listener className="org.apache.ajp.tomcat4.config.IISConfig"
append="true" />
| | | | |
It is possible to modify the output configuration file with the
following attributes:
| Attribute | Description |
|---|
configHome |
Default parent directory for the following paths. If not set, this
defaults to CATALINA_HOME. Ignored whenever any of the following
paths is absolute.
| regConfig |
Path to use for writing the registry settings configuration file.
If not set, defaults to "conf/auto/iis_redirect.reg".
| uriConfig |
Path to use for writing the URI worker map configuration file.
If not set, defaults to "conf/auto/uriworkermap.properties".
| workersConfig |
Path to workers.properties file used by mod_jk. If not set,
defaults to "conf/jk/workers.properties".
| 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 emerg.
| jkWorker |
The desired worker. Must be set to one of the workers defined in
the workers.properties file. "ajp13" or "inprocess" are
the workers found in the default workers.properties file. If not
specified, defaults to "ajp13".
| 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 IIS serve static resources. The
default is true. Warning: When false, some configuration in the
web.xml may not be duplicated in IIS. Review the mod_jk conf
file to see what configuration is actually being set in IIS.
| 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 IIS's httpd.conf file to point to
Tomcat's root context directory. Otherwise some content, such as
IIS's index.html, will be served by IIS before mod_jk gets a
chance to claim the request and pass it to Tomcat. The default is
true. | append |
Append to the current configuration file.
|
|
| Configuring IIS |
- Launch Internet Service Manager
- Stop the Web Site if it is running
- Create a virtual directory, by clicking on the default
web site
- Type the alias to say jakarta, press Next
- Set the directory to
%CATALINA_HOME%\bin
where you installed isapi_redirect.dll, press next
- Provide only read and execute privileges for
security purposes
- Add a filter to the default web site, using the
IIS Management Console, right click on the properties and
go to ISAPI filters tab. Press Add button,
add isapi_redirect.dll as a filter the name of the filter
should reflect its task (for example, "Jakarta Redirector").
The Executable field should point to the place where we installed
isapi_redirect.dll, in our case
%CATALINA_HOME%\bin\isapi_redirect.dll
- If not done yet, enter the keys from
iis_redirect.reg in the Windows registry (this can
be done by double-clicking on the file in the explorer).
Note: When manually creating the file (maybe from the example given
below), remember to correct the directories where Tomcat
is installed.
- Startup IIS.
- Go to the Properties of the web site and select the ISAPI
filters tab to make sure that the ISAPI filter got registered
correctly. It should have a Green arrow alongside it.
Note: it is recommended to restart computer for the ISAPI filter
to load.
|
|
|
|
