Re: Mapping in workers2.properties
There are actually several ways to map between Apache and Tomcat via mod_jk2. The first is using workers2.properties. If you've compiled with -pcre, then perl regular expressions should work as well as individual names. Also, remember that servlets traditionally live in /app-name/servlet/servlet-name. This is This is the physical location. controlled by the web.xml for the particular application (context) and is found in: $TOMCAT_HOME/webapps/app-name/WEB-INF/web.xml The example context is especially confusing, primarily due to the name. In Tomcat 4.1.29, you have the following: /examples/jsp/index.html /examples/servlets/index.html However, the actual location of the servlets according to web.xml would be: /examples/servlet/servlet-name This is the deployment path, which can be set to anything you choose. So, in your workers2.properties file you will need to have the following in order to map all servlets in the examples: [uri:/examples/servlet/*] worker=ajp13:unixsocket Why not [uri:/examples/*]? That way you map an entire web application to Tomcat's worker. I'll elaborate a bit more later. or whatever you called your worker name. While workers2.properties works well for a small number of sites, it does not scale very well since the match lookup is linear. Another way to manage mod_jk2 mapping is detailed in the source of mod_jk2. I know, I know, reading the source is not supposed to be a requirement, but then again this is open source so you do have the opportunity. Anyway, in jk/native2/server/apache2/mod_jk2.c, there is a little documentation concerning JkUriSet. Basically, you use Apache constructs to map the location and within that you use the JkUriSet directive to map the location to the appropriate worker. I've tried both ways, and they both work well. According to the source, using JkUriSet is the preferred method. OK, there are three things at work here. 1. Location of your files You can place files anywhere within your web application's subdir tree. Servlets go into ./WEB-INF/lib/*.jar (if packaged) or ./WEB-INF/classes/* (if unpacked). JSP files are anywhere outside ./WEB-INF. All other, static, files are outside ./WEB-INF. 2. Tomcat's deployment of the web-app You setup your Host and Context directives in server.xml so that each web application will have their URI, like http://your.host.domain.com/context/path/. Your web app will be invoked for all URIs of this kind. The invocation will come either from a Coyote HTTP connector or from mod_jk/mod_jk2/mod_webapp. 3. Apache's mapping of URI to a handler This is the mod_webapp/mod_jk/mod_jk2 stuff. In workers2.properties you map an URI from Apache to a worker. AFAIK, the URIs of Apache and Tomcat MUST match or Tomcat will ignore it. So, if you're setting up Virtual Hosts, both Apache and Tomcat must be the same (as they should, anyway) and deployment (deployment, not location path!) path of Tomcat's context must match. With this, there is no real benefit from using either workers2.properties [uri:...] or JkUriSet in httpd.conf, that I can see. Maybe I'm wrong? As for in-process, there has been some discussion on this mailing list about why in-process does not work with the current MPM (multi-processor modules) available for Apache httpd. The real problem seems to be that there is currently no MPM that runs all of apache within one process in UNIX, using threads exclusively to handle separate requests. Actually, this is not quite true since there is an experimental MPM that accomplishes this. However, according to the documentation this is slower than the current worker model (multi-process, multi-thread) and not recommended for production work. The problem is that when multiple processes get started, each process attempts to start its own Tomcat (if in-process is being used). This can't be done using the same server,xml. In recent kernels (Redhat 2.4.2x, generic 2.6.0, 2.6.1) there has been a new implementation of threads. It might be possible to build a new MPM that takes advantage of this. As far as I know, this is not being done (yet). This sounds like a great opportunity to make a contribution :-). What we need is new functionality in mod_jk2 for this, to support the notion of one worker process and multiple proxy workers. Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Mapping in workers2.properties
There are actually several ways to map between Apache and Tomcat via mod_jk2. The first is using workers2.properties. If you've compiled with -pcre, then perl regular expressions should work as well as individual names. Also, remember that servlets traditionally live in /app-name/servlet/servlet-name. This is controlled by the web.xml for the particular application (context) and is found in: $TOMCAT_HOME/webapps/app-name/WEB-INF/web.xml The example context is especially confusing, primarily due to the name. In Tomcat 4.1.29, you have the following: /examples/jsp/index.html /examples/servlets/index.html However, the actual location of the servlets according to web.xml would be: /examples/servlet/servlet-name So, in your workers2.properties file you will need to have the following in order to map all servlets in the examples: [uri:/examples/servlet/*] worker=ajp13:unixsocket or whatever you called your worker name. While workers2.properties works well for a small number of sites, it does not scale very well since the match lookup is linear. Another way to manage mod_jk2 mapping is detailed in the source of mod_jk2. I know, I know, reading the source is not supposed to be a requirement, but then again this is open source so you do have the opportunity. Anyway, in jk/native2/server/apache2/mod_jk2.c, there is a little documentation concerning JkUriSet. Basically, you use Apache constructs to map the location and within that you use the JkUriSet directive to map the location to the appropriate worker. I've tried both ways, and they both work well. According to the source, using JkUriSet is the preferred method. As for in-process, there has been some discussion on this mailing list about why in-process does not work with the current MPM (multi-processor modules) available for Apache httpd. The real problem seems to be that there is currently no MPM that runs all of apache within one process in UNIX, using threads exclusively to handle separate requests. Actually, this is not quite true since there is an experimental MPM that accomplishes this. However, according to the documentation this is slower than the current worker model (multi-process, multi-thread) and not recommended for production work. The problem is that when multiple processes get started, each process attempts to start its own Tomcat (if in-process is being used). This can't be done using the same server,xml. In recent kernels (Redhat 2.4.2x, generic 2.6.0, 2.6.1) there has been a new implementation of threads. It might be possible to build a new MPM that takes advantage of this. As far as I know, this is not being done (yet). This sounds like a great opportunity to make a contribution :-). Hope this has been helpful. /mde/ just my two cents . . . __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mapping in workers2.properties
Magic stuff Mark *** updated httpd.conf file snippet *** LoadModule jk2_module modules/mod_jk2.so IfModule mod_jk2.c JkSet config:file /usr/local/jakarta-tomcat-4.1.29/conf/workers2.properties /IfModule Alias /examples /usr/local/jakarta-tomcat-4.1.29/webapps/examples Location /examples JkUriSet worker ajp13:sslaptop.gsss.net:8001 /Location Location /examples/WEB-INF/ AllowOverride None deny from all /Location *** updated worker2.properties file [uri:/examples] info=Display status information and checks the config file for changes. worker=ajp13:sslaptop.gsss.net:8001 context=/examples group=status:status tomcatId=sslaptop.gsss.net:8001 [uri:/examples/*.jsp] info=jsp files [uri:/examples/servlet/*] info=servlet * take care, George - Original Message - From: Mark Eggers [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Cc: George Shafik [EMAIL PROTECTED] Sent: Sunday, January 11, 2004 6:16 AM Subject: Mapping in workers2.properties There are actually several ways to map between Apache and Tomcat via mod_jk2. The first is using workers2.properties. If you've compiled with -pcre, then perl regular expressions should work as well as individual names. Also, remember that servlets traditionally live in /app-name/servlet/servlet-name. This is controlled by the web.xml for the particular application (context) and is found in: $TOMCAT_HOME/webapps/app-name/WEB-INF/web.xml The example context is especially confusing, primarily due to the name. In Tomcat 4.1.29, you have the following: /examples/jsp/index.html /examples/servlets/index.html However, the actual location of the servlets according to web.xml would be: /examples/servlet/servlet-name So, in your workers2.properties file you will need to have the following in order to map all servlets in the examples: [uri:/examples/servlet/*] worker=ajp13:unixsocket or whatever you called your worker name. While workers2.properties works well for a small number of sites, it does not scale very well since the match lookup is linear. Another way to manage mod_jk2 mapping is detailed in the source of mod_jk2. I know, I know, reading the source is not supposed to be a requirement, but then again this is open source so you do have the opportunity. Anyway, in jk/native2/server/apache2/mod_jk2.c, there is a little documentation concerning JkUriSet. Basically, you use Apache constructs to map the location and within that you use the JkUriSet directive to map the location to the appropriate worker. I've tried both ways, and they both work well. According to the source, using JkUriSet is the preferred method. As for in-process, there has been some discussion on this mailing list about why in-process does not work with the current MPM (multi-processor modules) available for Apache httpd. The real problem seems to be that there is currently no MPM that runs all of apache within one process in UNIX, using threads exclusively to handle separate requests. Actually, this is not quite true since there is an experimental MPM that accomplishes this. However, according to the documentation this is slower than the current worker model (multi-process, multi-thread) and not recommended for production work. The problem is that when multiple processes get started, each process attempts to start its own Tomcat (if in-process is being used). This can't be done using the same server,xml. In recent kernels (Redhat 2.4.2x, generic 2.6.0, 2.6.1) there has been a new implementation of threads. It might be possible to build a new MPM that takes advantage of this. As far as I know, this is not being done (yet). This sounds like a great opportunity to make a contribution :-). Hope this has been helpful. /mde/ just my two cents . . . __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
