Here's a quick writeup. This is going to be a long reply, and I hope it will be useful.
I am using Fedora Core 4 as a model. I hope it will be close enough to RHEL 3 to be useful. You may have to change paths in order to correspond to your environment. First of all, my environment: Hardware/OS =========== Dell 8200 with 768 MB memory Dual boot: Fedora Core 4 2.6.13-1.1526_FC4 Windows 2000 Professional Software ======== Java 1.5.0_4 from Sun Apache 2.0.54 from RPM Tomcat 5.5.9 from jakarta.apache.org mod_jk 188.8.131.52 from source Installation ============ Java 1.5.0_4 is installed in /usr/jdk1.5.0_04 and soft linked to /usr/java JAVA_HOME is set in /etc/profile $JAVA_HOME/bin is placed in $PATH before /usr/bin I've left the Apache RPM install alone, which means the following: DocumentRoot /var/www Logs /etc/logs soft linked to /var/log/httpd modules /etc/modules soft linked to /usr/lib/httpd/modules conf /etc/conf /etc/conf.d I've created a tomcat user with the same group membership as apache user. The home directory is /home/tomcat. /home/tomcat/jakarta-tomcat-5.5.9 Current Tomcat installation Configuration ============= workers.properties ------------------ I've placed workers.properties in /etc/httpd/conf # # basic worker list # worker.list=local,status # # one to serve the applications # worker.local.type=ajp13 worker.local.host=localhost worker.local.port=8009 # # one to check the status # worker.status.type=status worker.status.host=localhost worker.status.port=8009 This is all you really need in order to connect a local Apache to a local Tomcat. I cannot think of a good reason to define more workers. That isn't to say that there aren't any. server.xml ---------- If you put multiple workers going to the same host and different ports, then you will have to modify server.xml. Basically, you will have to add a connector statement for each unique port that you use in your workers.properties file. You have two different ports, so you will need two connector statements. <Connector port="10009" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" /> <Connector port="8099" enableLookups="false" redirectPort="8643" protocol="AJP/1.3" /> jk.conf ----------- I'm following the examples used by Fedora Core 4 in configuring other add-on modules for Apache. You can place the mod_jk configuration information directly in /etc/httpd/conf/httpd.conf, but I've chosen to create a separate file in /etc/httpd/conf.d The contents of my file are as follows: # # following Fedora's add-on philosophy # LoadModule jk_module modules/mod_jk.so JkWorkersFile /etc/httpd/conf/workers.properties JkLogFile logs/mod_jk.log JkLogLevel warn JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " JkShmFile logs/shm-file # # jk status # JkMount /jk-status/ status httpd.conf ---------- Static File Problem ------------------- This is where the configuration can become a little more complex. It helps to understand how Apache finds files to serve. Each host in Apache has a DocumentRoot. In Redhat Fedora, the line that defines that reads: DocumentRoot "/var/www/html" That means that when you enter the following URL: http://localhost/application/ Apache will look for the DirectoryIndex files (usually index.html) in: /var/www/html/application/ This is fine until you add an application server into the mix. Many people package up the entire application into one war file. This means that all static as well as dynamic content gets loaded into the application server area. In your case, that's /usr/local/tomcat/jakarta-tomcat-5.5.9/webapps Apache will know absolutely nothing about this directory, and any files that are not mapped by JkMount and served by Tomcat will not be found by Apache Static File Solutions --------------------- 1. Change DocumentRoot The most global change is to change DocumentRoot. In order for this to work, all files in /usr/local/tomcat/jakarta-tomcat-5.5.9/webapps must be readable by the user that runs Apache (typically apache in a Redhat distribution). The way to do this is to put the following as your DocumentRoot statement. DocumentRoot "/usr/local/tomcat/jakarta-tomcat/webapps" While this works, it means that you will have to place all web sites in this location, even if they do not have dynamic content. In general, I don't like this solution. 2. Add Directory and Alias Statements Traditionally locating static files in a dynamic web site has been done by using a combination of Directory and Alias directives. The Directory directive grants appropriate server permissions (who gets to see the files, etc.) and the Alias directive matches a directory with a base URL. For example, here's one way to map application1 living in /usr/local/tomcat/jakarta-tomcat/5.5.9/webapps/application1. # # This goes in httpd.conf # <Directory "/usr/local/tomcat/webapps/application1/"> Options Indexes FollowSymlinks MultiViews AllowOverride None Order allow,deny Allow from all </Directory> Alias /application1/ "/usr/local/tomcat/webapps/application1/" # # nice to block WEB-INF # <DirectoryMatch "/usr/local/tomcat/webapps/*/WEB-INF/*"> AllowOverride None Order allow,deny Deny from all </DirectoryMatch> Now all static files in your /usr/local/tomcat/jakarta-tomcat-5.5.9/webapps/application1 will be found by Apache. Until you set up JkMount statements, all jsp pages will be served as source. In general this works pretty well. The files in /usr/local/tomcat/jakarta-tomcat/5.5.9/webapps must be readable by the user that runs Apache. 3. Separate installations If you use an IDE and ant to build your web applications, you can set things up to build separate war and zip (or tar) files. Put all the dynamic (Tomcat) material in a war file, and put all the static material in a tar or zip file. You then install the tar or zip file in DocumentRoot, and the war file in a appBase. For example, if your DocumentRoot is /var/www/html and your appBase is /usr/local/tomcat/jakarta-tomcat-5.5.9/webapps, then: a) install application1.tar in /var/www/html b) install application1.war in /usr/local/tomcat/jakarta-tomcat-5.5.9/webapps Make sure that application1.tar explodes into /var/www/html/application1 The dynamic portion of your web site will not be available until you add the appropriate JkMount statements. One of the major advantages in this solution is that it allows you to run Apache and Tomcat on separate machines. While setting up the IDE and ant script to create the appropriate builds may be challenging at first, this setup creates a lot of installation flexibility. 4. JkAutoAlias JkAutoAlias is a relatively new configuration directive for mod_jk. >From the documentation: JkAutoAlias directive automatically Alias webapp context directories into the Apache document space. It enables Apache to serve a static context while Tomcat serving dynamic context. This directive is used for convenience so that you don't have to put an apache Alias directive for each application directory inside Tomcat's webapp directory. So rather than setting up a Directory and Alias directive for each application, you can use one JkAutoAlias for the entire appBase. In your environment, this would be: JkAutoAlias /usr/local/tomcat/jakarta-tomcat-5.5.9/webapps Again, this directory must be readable by owner of the Apache process. This is a really nice solution and appears to inherit all of the Directory settings of DocumentRoot. Dynamic Files ------------- Once you've made the choice as to how you map the static files (probably 2 or 4 on a single host), you will need to map dynamic content. Simple JkMount statements work nicely. If you have used Aliases or JkAutoAlias, the JkMount statements need to occur after them. If you've moved DocumentRoot, then the JkMount statements just need to occur in the proper virtual host (or default host). JkMounts for jsp and jspf files are pretty straightforward. Usually all you need is: JkMount /application1/*.jsp JkKount /application1/*/*.jsp Change the ending to jspf for files that end in jspf. Servlets are a little more problematic. If you've built a generic application and all of your servlet mappings in web.xml are of the form: /servlet/<servlet-name> Then JkMount /application1/servlet/* will work for servlets in the /application1 context. Struts applications have a slightly different convention, in that all servlet mappings end in .do. JkMount /application1/*.do works. This is by no means the complete story. The above simple environment doesn't scale very well virtual hosts. However, it should be a good start at integrating Apache and Tomcat HTH /mde/ __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]