Return-Path: By Gal Shachor <shachor@il.ibm.com> This document explains how to set up Netscape/IIS web servers so that
Tomcat will run inside the web server process. It assumes that you have
already followed the instructions in the web server specific howto and
configured it to use Tomcat as an out of process servlet container.
Normally Tomcat is running in one process and the web servers runs in another;
this however requires the web server to communicate using some IPC mechanism
such as TCP/IP.
Note: Running the JVM inside the web server is not always a good
idea. Sure it gives the best performance, but is lacks the stability
associated with the out of process mode of operation. When deciding to run
in-process make sure that top speed is what you need.
<tomcat_home> is the root directory of tomcat. Your Tomcat
installation should have the following subdirectories:
In all the examples in this document <tomcat_home> will be d:\tomcat. A worker is defined to be a Tomcat process that accepts work from
the web server. For in-process operation you will have to use the Netscape/IIS
redirectors, look at their supported configuration sections.
The in-process adapter was tested using JDK1.1.7b/IBM's JDK 1.1.7/JDK1.2.2. The in-process adapter is not part of the "official" build of Jakarta, You
can obtain the code and binaries needed for it by accessing
http://jakarta.apache.org/builds/tomcat/release/v3.1_beta_1/bin/win32/i386/.
The adapter related file is jni_connect.dll. The Tomcat JNI adapter requires the following actions:
Put jni_connect.dll inside
<tomcat_home>\bin\i386\.
You should provide the JNI worker with several settings, some are
mandatory and some are an option...
By default Tomcat reads the file <tomcat_home>\conf\server.xml. This
file defines among other things the contexts and connectors used by Tomcat.
In order to work in-process you will have to perform the following actions:
You will need to select the contexts that you wish to serve using your
jni worker. On Netscape you can do that by modifying the lines in the servlet
configuration object to reflect redirect work to the new JNI worker.
For example:
In-Process HowTo
When Tomcat is running inside the web server process, requests for servlet
execution are passed using JNI (and performance improves).
Document Conventions and Assumptions
Supported Configuration
Installation
Putting jni_connect.dll in the bin directory
Update worker.properties and add the JNI worker
You can find a sample worker file (jni_workers.properties) under tomcat/conf.
Set the worker.list property to point on a worker named jni:
worker.list=jni
Announce that the worker named jni is of type jni:
worker.jni.type=jni
To set the classpath use the worker.name.class_path property,
for example:
worker.jni.class_path=d:\tomcat\classes
worker.jni.class_path=d:\tomcat\lib\xml.jar
worker.jni.class_path=d:\tomcat\lib\jasper.jar
worker.jni.class_path=d:\tomcat\lib\servlet.jar
worker.jni.class_path=d:\tomcat\lib\webserver.jar
worker.jni.class_path=d:\sdk\jdk1.2.2\lib\tools.jar
Note: Do not forget to include the JDK's tools.jar in your classpath.
worker.jni.jvm_lib=d:\sdk\jdk1.2.2\jre\bin\classic\jvm.dll
worker.jni.cmd_line=-config
worker.jni.cmd_line=d:\tomcat\conf\jni_server.xml
worker.jni.sysprops=tomcat.home=d:\tomcat
worker.jni.sysprops=java.compiler=NONE
worker.jni.stdout=d:\jvm.stdout
worker.jni.stderr=d:\jvm.stderr
worker.jni.ld_path=d:\SQLLIB\bin
worker.jni.ld_path=d:\my\native\code
Update server.xml
You can find a sample server file (jni_server.xml) under jakarta-tomcat/conf.
Remove all the connectors from your server.xml and add the following
lines (note that you will need to update the area marked
with <tomcat_home>)
<!-- New JNI, you need to compile the new/experimental module -->
<Connector className="org.apache.tomcat.service.JNIEndpointConnector">
<Parameter name="native_lib" value="<tomcat_home>\bin\i386\jni_connect.dll"/>
</Connector>
These lines add a JNI connector to Tomcat.
<ContextManager debug="0" workDir="work" home="<tomcat_home>" />
.
.
.
</ContextManager />
Again, make sure that you update <tomcat_home> to your real Tomcat
root.
Redirect contexts to the JNI workers
<Object name=servlet>
ObjectType fn=force-type type=text/plain
Service fn="jk_service" worker="jni"
</Object>
On IIS you will have to modify your worker mount file to mount contexts to the JNI worker. For example:
/examples/*=jniWhen you are done restart your server. That's all, you should now be able to execute Tomcat in-process.
The JNI connector was developed using Visual C++ Ver.6.0, so having this environment is a prereq if you want to perform a custom build. You will also need a JDK installation (the jre is not good enough) in order to use the JDK's include files.
The steps that you need to take are:
This will build both release and debug versions of the JNI connector.
An alternative will be to open the jni_connect workspace file (jni_connect.dsw) in msdev and build it using the build menu.
Please send feedback, bug report or any additional information to tomcat-dev@jakarta.apache.org.
1.1 jakarta-tomcat/src/doc/tomcat-iis-howto.html Index: tomcat-iis-howto.html ===================================================================By Gal Shachor <shachor@il.ibm.com>
This document explains how to set up IIS to cooperate with Tomcat. Normally IIS can not execute Servlets and Java Server Pages (JSPs), configuring IIS to use the Tomcat redirector plugin will let IIS send servlet and JSP requests to Tomcat (and this way, serve them to clients).
<tomcat_home> is the root directory of tomcat. Your Tomcat installation should have the following subdirectories:
In all the examples in this document <tomcat_home> will be d:\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:
The redirector uses ajp12 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.
The IIS redirector is not part of the "official" build of Jakarta, You can obtain the code and binaries needed for it by accessing http://jakarta.apache.org/builds/tomcat/release/v3.1_beta_1/bin/win32/i386/. The redirector related file is isapi_redirect.dll.
The Tomcat redirector requires three entities:
The installation includes the following parts:
In this document I will assume that isapi_redirect.dll is placed in d:\tomcat\bin\iis\i386\isapi_redirect.dll and that you created the properties files are in d:\tomcat\conf.
That's all, you should now start tomcat and ask IIS to serve you the /examples context.
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:
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:
/context/*=worker_name
Workers and their name are defined in workers.properties, by default workers.properties comes with a single pre-configured worker named "ajp12" 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:
/shop/*=ajp12
After saving uriworkermap.properties restart IIS and it will serve the new context.
The redirector was developed using Visual C++ Ver.6.0, so having this environment is a prereq if you want to perform a custom build.
The steps that you need to take are:
This will build both release and debug versions of the redirector plugin.
An alternative will be to open the isapi workspace file (isapi.dsw) in msdev and build it using the build menu.
Sometimes it is better to have IIS serve the static pages (html, gif, jpeg etc.) even if these files are part of a context served by Tomcat. For example, consider the html and gif files in the examples context, there is no need to serve them from the Tomcat process, IIS will suffice.
Making IIS serve static files that are part of the Tomcat contexts requires the following:
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 d:\tomkat\webapps\examples directory.
Configuring the redirector is somewhat harder, you will need to specify the exact URL-Path pattern(s) that 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/*=ajp12
with the following two lines:
/examples/*.jsp=ajp12
/examples/servlet/*=ajp12
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=ajp12
that instructs the redirector to redirect request whose URL-Path equals /example/servletname to the worker named ajp12.
Each servlet application (context) has a special directory named WEB-INF, this directory contains sensitive configurations data and Java classes and must be kept hidden from web users. Using the IIS management console it is possible to protect the WEB-INF directory from user access, this however requires the administrator to remember that. To avoid this need the redirector plugin automatically protects your WEB-INF directories by rejecting any request that contains WEB-INF in its URL-Path.
Sometimes you want to serve different contexts with different Tomcat processes (for example to spread the load among different machines). To achieve such goal you will need to define several workers and assign each context with its own worker.
Defining workers is done in workers.properties, this file includes two types of entries:
The above examples defined two workers, now we can use these workers to serve two different contexts each with its own worker. For example look at the following uriworkermap.properties fragment:
/examples/*=ajp12
/webpages/*=ajp12second
As you can see the examples context is served by ajp12 while the webpages context is served by ajp12second.
Please send feedback, bug report or any additional information to tomcat-user@jakarta.apache.org
1.1 jakarta-tomcat/src/doc/tomcat-netscape-howto.html Index: tomcat-netscape-howto.html ===================================================================By Gal Shachor <shachor@il.ibm.com>
This document explains how to set up Netscape web servers to cooperate with Tomcat. Normally the Netscape web servers come with their own Servlet engine, but you can also configure them to send servlet and JSP requests to Tomcat using the Tomcat redirector plugin.
<tomcat_home> is the root directory of tomcat. Your Tomcat installation should have the following subdirectories:
In all the examples in this document <tomcat_home> will be d:\tomcat.
A worker is defined to be a tomcat process that accepts work from the Netscape server.
The Netscape-Tomcat redirector was developed and tested on:
The redirector uses ajp12 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.
The Netscape redirector is not part of the "official" build of Jakarta, You can obtain the code and binaries needed for it by accessing http://jakarta.apache.org/builds/tomcat/release/v3.1_beta_1/bin/win32/i386/. The redirector related file is nsapi_redirect.dll.
The Tomcat redirector requires two entities:
The installation includes the following parts:
In this document I will assume that nsapi_redirect.dll is placed in d:\tomcat\bin\netscape\nt4\i386\nsapi_redirect.dll and that you created the properties files are in d:\tomcat\conf.
That's all, now you should start tomcat and ask Netscape for http://server:port/examples/
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:
Assigning the NSAPI redirector to handle this context is simple, all you need to do is to edit obj.conf and add a NameTrans line that looks like:
NameTrans fn="assign-name" from="/<context name>/*" name="servlet"
After saving obj.conf restart Netscape and it will serve the new context.
The redirector was developed using Visual C++ Ver.6.0, so having this environment is a prereq if you want to perform a custom build.
The steps that you need to take are:
This will build both release and debug versions of the redirector plugin.
An alternative will be to open the nsapi workspace file (nsapi.dsw) in msdev and build it using the build menu.
Sometimes it is better to have Netscape serve the static pages (html, gif, jpeg etc.) even if these files are part of a context served by Tomcat. For example, consider the html and gif files in the examples context, there is no need to serve them from the Tomcat process, Netscape will suffice.
Making Netscape serve static files that are part of the Tomcat contexts requires the following:
Adding a Tomcat context to Netscape requires the addition of a new Netscape virtual directory that covers the Tomcat context. For example, adding a /example Netscape virtual directory that covers the d:\tomkat\webapps\examples directory. To add a new virtual directory add the following line to your obj.conf:
NameTrans fn=pfx2dir from=/examples dir="d:/tomcat/webapps/examples"
WEB-INF protection requires some explanation; Each servlet application (context) has a special directory named WEB-INF, this directory contains sensitive configurations data and Java classes and must be kept hidden from web users. WEB-INF can be protected by adding the following line to the PathCheck section in the default configuration object:
PathCheck fn="deny-existence" path="*/WEB-INF/*"
This line instructs the Netscape server to reject any request with a URL that contain the path /WEB-INF/.
Configuring Netscape to assign the NSAPI redirector only specific requests is somewhat harder, you will need to specify the exact URL-Path pattern(s) that you want Tomcat to handle (usually only JSP files and servlets). This requires a change to NemaTrans portion of obj.conf. For the examples context it requires to replace the following line:
NameTrans fn="assign-name" from="/examples/*" name="servlet"
with the following two lines:
NameTrans fn="assign-name" from="/examples/jsp/*.jsp"
name="servlet"
NameTrans fn="assign-name" from="/examples/servlet/*"
name="servlet"
As you can see the second configuration is more explicit, it actually instructs Netscape to assign the redirector with only requests to resources under /examples/servlet/ and resources under /examples/ whose name ends with .jsp. You can be even more explicit and provide lines such as:
NameTrans fn="assign-name" from="/examples/servletname" name="servlet"
that instructs Netscape to assign the redirector request whose URL-Path equals /example/servletname.
Sometimes you want to serve different contexts with different Tomcat processes (for example to spread the load among different machines). To achieve such goal you will need to define several workers and assign each context with its own worker.
Defining workers is done in workers.properties, this file includes two types of entries:
The above examples defined two workers, now we can use these workers to serve two different contexts each with its own worker. Submitting requests to different workers is accomplished by using multiple Service directives in the servlet configuration Object, each with a different path pattern parameter. For example, if we want to submit the /servlet context to a worker named ajp12 and the /examples context to a worker named ajp12second we should use the following configuration:
<Object name=servlet>
ObjectType fn=force-type type=text/plain
Service fn="jk_service" worker="ajp12" path="/servlet/*"
Service fn="jk_service" worker="ajp12second"
path="/examples/*"
Service fn="jk_service" worker="ajp12"
</Object>
Please send feedback, bug report or any additional information to tomcat-user@jakarta.apache.org.