${tomcat_home} is the root directory of tomcat. Your Tomcat installation should have the following subdirectories:

• ${tomcat_home}\conf - Where you can place various configuration files
• ${tomcat_home}\webapps - Containing example applications
• ${tomcat_home}\bin - Where you place web server plugins

In all the examples in this document ${tomcat_home} will be c:\tomcat. A worker is defined to be a tomcat process that accepts work from the IIS server.

The IIS-Tomcat redirector was developed and tested on:

• WinNT4.0-i386 SP4/SP5/SP6a (should be able to work with other service packs), Win2K and WinXP and Win98
• IIS4.0 and PWS4.0 (numerous people have working IIS 5 and IIS 6 configurations)
• Tomcat 3.2 and later, Tomcat 4.x, Tomcat 5 and 5.5 and Tomcat 6

The redirector uses ajp12 and ajp13 to send requests to the Tomcat containers. There is also an option to use Tomcat in process, more about the in-process mode can be found in the in process howto.

There are extra steps you need to take for configuring Tomcat with IIS 5 and 6. Please see the appropriate links from Tomcat Useful Links.

There is a known bug in IIS that may result in incomplete log messages. See bug 45769 for further details.

The ajp12 protocol is only available in Tomcat 3.2.x and 3.3.x.

The ajp12 has been deprecated with Tomcat 3.3.x and you should use instead ajp13 which is the only ajp protocol known by Tomcat 4.x, 5 and 5.5 and Tomcat 6.

Of course Tomcat 3.2.x and 3.3.x also support ajp13 protocol.

Others servlet engines such as jetty have support for ajp13 protocol

1. The IIS-Tomcat redirector is an IIS plugin (filter + extension), IIS load the redirector plugin and calls its filter function for each in-coming request.
2. The filter then tests the request URL against a list of URI-paths held inside uriworkermap.properties, If the current request matches one of the entries in the list of URI-paths, the filter transfers the request to the extension.
3. The extension collects the request parameters and forwards them to the appropriate worker using the defined protocol like ajp13.
4. The extension collects the response from the worker and returns it to the browser.

The examples context is useful for verifying your installation, but you will also need to add your own contexts. Adding a new context requires two operations:

1. Adding the context to Tomcat (I am not going to talk about this).
2. Adding the context to the ISAPI redirector.

Adding a context to the ISAPI redirector is simple, all you need to do is to edit your uriworkermap.properties and to add a line that looks like:

Workers and their name are defined in workers.properties, by default workers.properties comes with a single pre-configured worker named "defworker" so you can use it. As an example, if you want to add a context named "shop", the line that you should add to uriworkermap.properties will be:

The above should be all you need for IIS to pass through to Tomcat any request for any URI which corresponds to a Tomcat context (webapp).

If your webiste is very busy (more than 100 requests/second, or more than 100 simultaneous client connections), it might sometimes be desirable to have IIS serve static content (html, gif, jpeg etc.) directly, even if these files are part of a context served by Tomcat. Allowing IIS to serve such files directly may avoid the small overhead consisting of passing the request to Tomcat via the redirector, and may free up Tomcat somewhat, by using it only to process requests that only Tomcat can handle (e.g. requests to JSP pages and java servlets).

For example, consider the html and gif files in the examples context : you could serve these files directly with IIS; there is no need to serve them from the Tomcat process.

Making IIS serve static files that are part of the Tomcat contexts requires the following:

1. Configuring IIS to know about the Tomcat contexts
2. Configuring the redirector to leave the static files for IIS

Adding a Tomcat context to IIS requires the addition of a new IIS virtual directory that covers the Tomcat context. For example adding a /example IIS virtual directory that covers the c:\tomcat\webapps\examples directory.

Configuring the redirector is somewhat harder, you will need to specify the exact URL-Path pattern(s) which you want Tomcat to handle (usually only JSP files and servlets). This requires a change to the uriworkermap.properties : For the examples context it requires to replace the following line /examples/*=defworker with the following two lines /examples/*.jsp=defworker /examples/servlet/*=defworker

As you can see the second configuration is more explicit, it actually instruct the redirector to redirect only requests to resources under /examples/servlet/ and resources under /examples/ whose name ends with .jsp.

You can even be more explicit and provide lines such as: /example/servletname=defworker

that instructs the redirector to redirect all requests whose URL-path matches the leading string "/example/servletname" to the worker named defworker.

Once again, be aware that by allowing IIS to access the content of your Tomcat context directly, you are potentially bypassing Tomcat's protection of that content. You should thus make sure to protect this content at the IIS level if needed, by using the corresponding IIS management console functions.

In particular, each servlet application (context) has a special directory named WEB-INF, which contains sensitive configuration data and Java classes, and which should always be kept hidden from web users. Using the IIS management console it is possible to protect the WEB-INF directory from user access, but considering that this is a general requirement, and considering that it is easy to forget to implement this protection at the IIS level, the redirector plugin does it automatically for you, and it will reject any request which contains WEB-INF in its URL-path.

Sometimes you may want to serve different contexts with different Tomcat processes (for example to spread the load among different machines). To achieve such a goal you will need to define several workers and assign each context to its own worker.

Defining additional workers is done in the workers.properties file. This file includes two types of entries:

# An entry that lists all the workers defined worker.list=worker1, worker2 # Entries that define the host and port associated with each of these workers worker.worker1.host=localhost worker.worker1.port=8009 worker.worker1.type=ajp13 worker.worker2.host=otherhost worker.worker2.port=8009 worker.worker2.type=ajp13

The above example defined two workers, now we can use these workers to serve two different contexts each with its own worker: example uriworkermap.properties fragment /examples/*=worker1 /webpages/*=worker2

As you can see the examples context is served by worker1 while the webpages context is served by worker2.

More information on using and configuring workers in the Workers HowTo and in the worker.properties configuration reference.

Start the IIS service and Tomcat.

Check for the presence of the ISAPI redirector log file you specified in the log_file setting. If not found, verify the following:

• Check the "Filter DLLs" setting in the "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters" key and make sure the path is correct.
• Check the spelling of the "HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\1.0" key. Case isn't important, but an incorrect letter will prevent the isapi_redirect.dll from finding its registry settings.
• Check the log_file setting for typos, name and data. Also insure the directory in which the log file will appear already exists.
If the above are set correctly, the ISAPI redirector should be able to create the log file.

Invoke the URL http://localhost/examples/jsp/index.html in your browser. Case is important in Tomcat. The characters following "localhost" in the URL must be lower case. If the page fails to appear, stop the IIS service (required to view the IIS log file). Then examine the last line in the IIS log file in found in SYSTEM/LogFiles/W3SVC1 :

If the last line contains:

then the ISAPI redirector is not recognising that it should be handling requests for the "/examples" context. Check the following:

• Check the extension_uri name for typos.
• Check the worker_file setting for typos, name and data.
• Check the worker_mount_file setting typos, name and data.
If these are set correctly, the ISAPI redirector should recognise that it should handle requests for the "/examples" context.

If the last line contains something like:

then the ISAPI redirector is recognising that it should handle the request, but is not successful at getting Tomcat to service the request.

You should check the HTTP error code following GET "/..." :

• Make sure you entered the URL correctly.
• Make sure the virtual directory created was called "jakarta". It should display in Personal Web Manager as "/jakarta" (without the quotes).
• Make sure the extension_uri data begins with "/jakarta/" (without the quotes).

• Make sure that "isapi_redirect.dll" follows "/jakarta/" in the extension_uri setting.
• Check the workers.properties file and make sure the port setting for worker.ajp12.port is the same as the port specified in the server.xml for the "Apache AJP12 support".

• Make sure you have checked Execute Access for the jakarta virtual directory in the Advanced Options of the Personal Web Manager.

If the above settings are correct, the index.html page should appear in your browser. You should also be able to click the Execute links to execute the JSP examples.

Start the World Wide Web Publishing Service and Tomcat.

Check for the presence of the ISAPI redirector log file you specified in the log_file setting. If not found, check the following:

• Check the "executable" you set for the filter in the IIS Management Console and make sure the path is correct.
• Check the spelling of the "HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\1.0" key. Case isn't important, but an incorrect letter will prevent the isapi_redirect.dll from finding its registry settings.
• Check the log_file setting for typos, name and data. Also insure the directory in which the log file will appear already exists.
If the above are set correctly, the ISAPI redirector should be able to create the log file.

Check the tomcat filter you added and make sure its status shows a green upward-pointing arrow. If not, check the following:

• Check the worker_file setting for typos, name and data.
• Check the worker_mount_file setting typos, name and data.
If the above are set correctly, the green upward-pointing arrow should appear, even if the other settings are wrong.

Invoke the URL http://localhost/examples/jsp/index.html in your browser. Case is important in Tomcat. The characters following "localhost" in the URL must be lower case. If the page fails to appear, examine the last line in the IIS server log file in found in SYSTEM32/LogFiles/W3SVC1.

The last line should contain something like: GET "/jakarta/isapi_redirect.dll HTTP1.1", which indicates the ISAPI redirector is recognising that it should handle the request.

You should check the HTTP error code following GET "/..." :

• Make sure you entered the URL correctly.

• Make sure the virtual directory created was called "jakarta".
• Make sure that the extension_uri setting is correct.
• Check the workers.properties file and make sure the port setting for worker.ajp12.port is the same as the port specified in the server.xml for the "Apache AJP12 support".

• Make sure you have checked Execute Access for the jakarta virtual directory in the Advanced Options of the Personal Web Manager.

If the above settings are correct, the index.html page should appear in your browser. You should also be able to click the Execute links to execute the JSP examples.