| Links Top Level Elements Connectors Containers Nested Components | The AJP Connector| Introduction |  | 
  The AJP Connector element represents a
  Connector component that communicates with a web
  connector via the AJPprotocol.  This is used for cases
  where you wish to invisibly integrate Tomcat 4 into an existing (or new)
  Apache installation, and you want Apache to handle the static content
  contained in the web application, and/or utilize Apache's SSL
  processing.  In many application environments, this will result in
  better overall performance than running your applications under
  Tomcat stand-alone using the 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. | 
 | Attributes |  | 
  | Common Attributes |  | 
  All implementations of Connector
  support the following attributes: | Attribute | Description | 
|---|
 | className | Java class name of the implementation to use.  This class must
      implement the org.apache.catalina.Connectorinterface.
      You must specify the standard value defined below. |  | enableLookups | Set to trueif you want calls torequest.getRemoteHost()to perform DNS lookups in
      order to return the actual host name of the remote client.  Set
      tofalseto skip the DNS lookup and return the IP
      address in String form instead (thereby improving performance).
      By default, DNS lookups are enabled. |  | redirectPort | If this Connector is supporting non-SSL
      requests, and a request is received for which a matching
      <security-constraint>requires SSL transport,
      Catalina will automatically redirect the request to the port
      number specified here. |  | scheme | Set this attribute to the name of the protocol you wish to have
      returned by calls to request.getScheme().  For
      example, you would set this attribute to "https"
      for an SSL Connector.  The default value is "http".
      See SSL Support for more information. |  | secure | Set this attribute to trueif you wish to have
      calls torequest.isSecure()to returntruefor requests received by this Connector (you would want this on an
      SSL Connector).  The default value isfalse. | 
 | 
 | Standard Implementation |  | 
  The standard implementation of AJP Connector is
  org.apache.ajp.tomcat4.Ajp13Connector. This implementation supports the AJP 1.3 protocol. It supports the following additional attributes (in addition to the
  common attributes listed above): | Attribute | Description | 
|---|
 | acceptCount | The maximum queue length for incoming connection requests when
      all possible request processing threads are in use.  Any requests
      received when the queue is full will be refused.  The default
      value is 10. |  | debug | The debugging detail level of log messages generated by this
      component, with higher numbers creating more detailed output.
      If not specified, this attribute is set to zero (0). |  | maxProcessors | The maximum number of request processing threads to be created
      by this Connector, which therefore determines the
      maximum number of simultaneous requests that can be handled.  If
      not specified, this attribute is set to 20. |  | minProcessors | The number of request processing threads that will be created
      when this Connector is first started.  This
      attribute should be set to a value smaller than that set for
      maxProcessors.  The default value is 5. |  | port | The TCP port number on which this Connector
      will create a server socket and await incoming connections.  Your
      operating system will allow only one server application to listen
      to a particular port number on a particular IP address. | 
 | 
 | 
 | 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 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. | 
 | 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! Unlike Tomcat 3, Tomcat 4 doesn't automatically generate the 
           necessary $CATALINA_HOME/conf/mod_jk.conf,
           and it will have to be created manually. Note that Tomcat 
           and Apache must be restarted after adding a new context. 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] "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. | 
 | Configuring Tomcat |  | 
           Tomcat 4 won't automatically generate the Apache configuration 
           file at the moment. After enabling the AJP 1.3 connector, you need to define workers,
           using a $CATALINA_HOME/conf/workers.propertiesfile.
           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. | 
 | 
 | 
 | 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.
         Note: See below for examples of the configuration files. Those 
        configuration files assume Tomcat is installed in the 
        c:\jakarta-tomcat-4.0.1directory. 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.propertiesfile must be created
        in%CATALINA_HOME%\confdirectory. | 
 | Configuring IIS |  | 
        
         
           Launch Internet Service ManagerStop the Web Site if it is runningCreate a virtual directory, by clicking on the default 
               web site
              
                 Type the alias to say jakarta, press NextSet the directory to %CATALINA_HOME%\binwhere you installed isapi_redirect.dll, press nextProvide only read and execute privileges for 
                     security purposesAdd 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.dllCopy and paste the registry entries found below into a file 
           iis_redirect.reg. Remember to correct the 
           directories where Tomcat is installed in this file. 
           Run the iis_redirect.reg file found at the end of this document. 
           This will create entries in the registry which 
           the isapi_redirect.dll looks for to determine the configuration 
           and location of Tomcat.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. | 
 | 
 | 
 |