Costin and Geoff,
Thanks very much for your help and interest. I don't think that doing the
"right thing" is as hard as you think though:) I've got the 2.2 servlet
spec and I reread the servlet mapping functionality. I believe Apache does
path matching in the same way so that any patterns specified in Apache have
the same context when passed to Tomcat, thus a direct mapping is still
feasible. In actuallity, Apache will map "*.jsp" as in the servlet 2.2.
spec and mod_jk requires "/*.jsp". I've attached a segment of an Apache
httpd.conf file containing the Tomcat configuration as I've modified it, a
sample WEB-INF/web.xml file, a sample workers.properties file, a sample
server.xml, and both the current mod_jk.c and my mod_jk.c files and a diff
between them. If you'll notice, the only configuration changes that differ
from the current way of doing things are in httpd.conf. The web.xml,
workers.properties, and server.xml files are nothing out of the ordinary.
Please let me know what you think of the differences and how they would
impact usability. Please note in particular the architectural changes I
made to mod_jk.c by unregistering it as a filter and changing the entry
point for the handler to allow URI resolution to determine the appropriate
Tomcat worker. I agree that the existing performance hit is minimal but I
just don't see an advantage to paying that price and risking URI
misinterpretation by other installed modules. Additionally, I'm fairly
confident that tomcat could be set up to produce the appropriate sample
httpd.conf file fairly easily too. Many thanks for your time and insight
and please let me know what you think.
Cheers,
Jamey
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 23, 2001 8:52 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: cvs commit: jakarta-tomcat/src/native/mod_jk/common
jk_uri_worker_map.c
Hi Jamey,
You are touching a very important subject in the mod_jk
implementation. And YES, you are absolutely right ( IMHO ) - Apache, IIS,
NES, AOLServer are pretty good at processing requests - after all that's
their main business.
Each requests is mapped by the ( optimized ) mappers of
the native web server, and then the same operation is duplicated in
mod_jk - adding a performance hit on all served requests.
Unfortunately, doing the "right thing" is hard and tricky - the current
solution works and the overhead it adds is acceptable.
The problem is that configuring the server is tricky and few people know
how to do it. An attempt has been made to generate server config file
automatically, but web.xml is quite complex and a lot is missing.
mod_jk has a lot of flexibility - it can send all the requests for a
particular context to tomcat ( where all web.xml settings will be
respected ).
Or you can translate the mapping from web.xml in server configs - and
operate in the most efficient way.
The translation is not easy and requires knowledge of the server. All
settings in web.xml have equivalent in the server settings - but not too
many people know how to do it. And it's even harder to do it
automatically. But what you get is maximum flexibility, you can authorize
using any of the server modules, etc.
That's why forwarding the whole context is sometimes an acceptable
solution ( and it automatically respects all settings in web.xml :-). The
only problem - static files in webapps will still be served by tomcat, and
the server is just a proxy.
I have serious doubts that an automated solution is the best for all
cases, but improvements to the current "forward all" are needed. On the
other side, I think it is very important to support/enhance the flexible
aproach where a server admin has the chance to tune the settings.
Case: authentication. There is no easy way to guess what mod_auth is used
by the server ( you may have multiple modules doing that ). A "manual
tunning" would allow the deployer to do implement his site policies and
tune the deployment. A "automated" deployment should be possible, but I
doubt it is the best for big production sites.
(thanks for reviewing the code, any enhancements in this area are
wellcomed )
Costin
> Many thanks,
> I was wondering why both the mod_jk module and IIS isapi act as filters
> instead of an Apache handler or an IIS application respectively. In their
> current implementation they scan all request URIs for ones that they are
> responsible for and then, in the case of Apache anyway, register a call
back
> to a handler to handle the actual request. I have had this cause problems
> for me with Apache in the case where I have a servlet named foo and
another
> file named foo.xxx. mod_jk correctly maps /foo to the servlet and
registers
> the callback but Apache never calls the callback and instead some other
> module or the Apache core make a best guess that the request really meant
> foo.xxx since no /foo exists as far as Apache is concerned. By adding
> handler entries to Apache's httpd.conf file like the following (pardon my
> syntax if it is somewhat off)
>
> <location path="/login">
> <handler name="jakarta-servlet">
> </location>
>
> Apache then automatically sends that URI to mod_jk without any filtering
> needed. All mod_jk need now do is determine which Tomcat handler to use
> (ajp12, ajp13, lb, etc...). Filtering is also more expensive because all
> modules get a chance to act on the URI before the callback handler. By
> registering mod_jk as a handler directly, Apache maps the URI directly to
> mod_jk with basically no overhead or searching. I've made some code
changes
> (about four changed lines) to mod_jk that make it behave as a pure handler
> with no filtering and it seems to run great but I'd like to know before
> proposing a change if there were specific reasons for the filter
> implementation. Many thanks to anyone who can help:)
> -Jamey
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 22, 2001 7:23 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: jakarta-tomcat/src/native/mod_jk/common
> jk_uri_worker_map.c
>
>
> danmil 01/01/22 19:23:03
>
> Modified: src/native/mod_jk/common jk_uri_worker_map.c
> Log:
> Adding more thorough DEBUG-level to describe what mapping the module is
> using for a given request.
>
> Submitted by: James Courtney
>
> Revision Changes Path
> 1.3 +18 -6
> jakarta-tomcat/src/native/mod_jk/common/jk_uri_worker_map.c
>
> Index: jk_uri_worker_map.c
> ===================================================================
> RCS file:
> /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_uri_worker_map.c,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- jk_uri_worker_map.c 2000/11/10 18:48:50 1.2
> +++ jk_uri_worker_map.c 2001/01/23 03:23:03 1.3
> @@ -65,7 +65,7 @@
> * servlet container.
> *
> *
> *
> * Author: Gal Shachor <[EMAIL PROTECTED]>
> *
> - * Version: $Revision: 1.2 $
> *
> + * Version: $Revision: 1.3 $
> *
>
>
***************************************************************************/
>
> #include "jk_pool.h"
> @@ -358,6 +358,7 @@
> uri = clean_uri;
> }
>
> + jk_log(l, JK_LOG_DEBUG, "Attempting to map URI %s\n", uri);
> for(i = 0 ; i < uw_map->size ; i++) {
>
> if(uw_map->maps[i].ctxt_len < longest_match) {
> @@ -369,10 +370,20 @@
> uw_map->maps[i].ctxt_len)) {
> if(MATCH_TYPE_EXACT == uw_map->maps[i].match_type) {
> if(strlen(uri) == uw_map->maps[i].ctxt_len) {
> + jk_log(l,
> + JK_LOG_DEBUG,
> + "jk_uri_worker_map_t::map_uri_to_worker, Found an exact
>match
> %s ->%s\n",
> + uw_map->maps[i].worker_name,
> + uw_map->maps[i].context );
> return uw_map->maps[i].worker_name;
> }
> } else if(MATCH_TYPE_CONTEXT ==
> uw_map->maps[i].match_type) {
> if(uw_map->maps[i].ctxt_len > longest_match) {
> + jk_log(l,
> + JK_LOG_DEBUG,
> + "jk_uri_worker_map_t::map_uri_to_worker, Found a context
match
> %s -> %s\n",
> + uw_map->maps[i].worker_name,
> + uw_map->maps[i].context );
> longest_match = uw_map->maps[i].ctxt_len;
> best_match = i;
> }
> @@ -393,6 +404,11 @@
> if(0 == strcmp(suffix, uw_map->maps[i].suffix))
{
> #endif
> if(uw_map->maps[i].ctxt_len >=
longest_match)
> {
> + jk_log(l,
> + JK_LOG_DEBUG,
> + "jk_uri_worker_map_t::map_uri_to_worker, Found
>a suffix
match
> %s -> *.%s\n",
> + uw_map->maps[i].worker_name,
> + uw_map->maps[i].suffix );
> longest_match =
uw_map->maps[i].ctxt_len;
> best_match = i;
> }
> @@ -403,10 +419,6 @@
> }
>
> if(-1 != best_match) {
> - jk_log(l, JK_LOG_DEBUG,
> - "jk_uri_worker_map_t::map_uri_to_worker, Found a
match
> %s\n",
> - uw_map->maps[best_match].worker_name);
> -
> return uw_map->maps[best_match].worker_name;
> } else {
> /*
> @@ -435,4 +447,4 @@
> "jk_uri_worker_map_t::map_uri_to_worker, done without a
> match\n");
>
> return NULL;
> -}
> \ No newline at end of file
> +}
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
--
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
workers.properties
mod_jk.c
mod_jk.diff
mod_jk.orig
<?xml version="1.0" encoding="ISO-8859-1"?>
<Server>
<!-- Debug low-level events in XmlMapper startup -->
<xmlmapper:debug level="0" />
<!--
Logging:
Logging in Tomcat is quite flexible; we can either have a log
file per module (example: ContextManager) or we can have one
for Servlets and one for Jasper, or we can just have one
tomcat.log for both Servlet and Jasper. Right now there are
three standard log streams, "tc_log", "servlet_log", and
"JASPER_LOG".
Path:
The file to which to output this log, relative to
TOMCAT_HOME. If you omit a "path" value, then stderr or
stdout will be used.
Verbosity:
Threshold for which types of messages are displayed in the
log. Levels are inclusive; that is, "WARNING" level displays
any log message marked as warning, error, or fatal. Default
level is WARNING.
verbosityLevel values can be:
FATAL
ERROR
WARNING
INFORMATION
DEBUG
Timestamps:
By default, logs print a timestamp in the form "yyyy-MM-dd
hh:mm:ss" in front of each message. To disable timestamps
completely, set 'timestamp="no"'. To use the raw
msec-since-epoch, which is more efficient, set
'timestampFormat="msec"'. If you want a custom format, you
can use 'timestampFormat="hh:mm:ss"' following the syntax of
java.text.SimpleDateFormat (see Javadoc API). For a
production environment, we recommend turning timestamps off,
or setting the format to "msec".
Custom Output:
"Custom" means "normal looking". "Non-custom" means
"surrounded with funny xml tags". In preparation for
possibly disposing of "custom" altogether, now the default is
'custom="yes"' (i.e. no tags)
Per-component Debugging:
Some components accept a "debug" attribute. This further
enhances log output. If you set the "debug" level for a
component, it may output extra debugging information.
-->
<!-- if you don't want messages on screen, add the attribute
path="logs/tomcat.log"
to the Logger element below
-->
<Logger name="tc_log"
verbosityLevel = "INFORMATION"
/>
<Logger name="servlet_log"
path="logs/servlet.log"
/>
<Logger name="JASPER_LOG"
path="logs/jasper.log"
verbosityLevel = "INFORMATION" />
<!-- You can add a "home" attribute to represent the "base" for
all relative paths. If none is set, the TOMCAT_HOME property
will be used, and if not set "." will be used.
webapps/, work/ and logs/ will be relative to this ( unless
set explicitely to absolute paths ).
You can also specify a "randomClass" attribute, which determines
a subclass of java.util.Random will be used for generating session IDs.
By default this is "java.security.SecureRandom".
Specifying "java.util.Random" will speed up Tomcat startup,
but it will cause sessions to be less secure.
You can specify the "showDebugInfo" attribute to control whether
debugging information is displayed in Tomcat's default responses.
This debugging information includes:
1. Stack traces for exceptions
2. Request URI's that cause status codes >= 400
The default is "true", so you must specify "false" to prevent
the debug information from appearing. Since the debugging
information reveals internal details about what Tomcat is serving,
set showDebugInfo="false" if you wish increased security.
-->
<ContextManager debug="0" workDir="work" showDebugInfo="true" >
<!-- ==================== Interceptors ==================== -->
<!--
ContextInterceptor className="org.apache.tomcat.context.LogEvents"
-->
<ContextInterceptor className="org.apache.tomcat.context.AutoSetup" />
<ContextInterceptor
className="org.apache.tomcat.context.WebXmlReader" />
<!-- Uncomment out if you have JDK1.2 and want to use policy
<ContextInterceptor
className="org.apache.tomcat.context.PolicyInterceptor" />
-->
<ContextInterceptor
className="org.apache.tomcat.context.LoaderInterceptor" />
<ContextInterceptor
className="org.apache.tomcat.context.DefaultCMSetter" />
<ContextInterceptor
className="org.apache.tomcat.context.WorkDirInterceptor" />
<!-- Request processing -->
<!-- Session interceptor will extract the session id from cookies and
deal with URL rewriting ( by fixing the URL ). If you wish to
suppress the use of cookies for session identifiers, change the
"noCookies" attribute to "true"
-->
<RequestInterceptor
className="org.apache.tomcat.request.SessionInterceptor"
noCookies="false" />
<!-- Find the container ( context and prefix/extension map )
for a request.
-->
<RequestInterceptor
className="org.apache.tomcat.request.SimpleMapper1"
debug="0" />
<!-- Non-standard invoker, for backward compat. ( /servlet/* )
You can modify the prefix that is matched by adjusting the
"prefix" parameter below. Be sure your modified pattern
starts and ends with a slash.
NOTE: This prefix applies to *all* web applications that
are running in this instance of Tomcat.
-->
<RequestInterceptor
className="org.apache.tomcat.request.InvokerInterceptor"
debug="0" prefix="/servlet/" />
<!-- "default" handler - static files and dirs. Set the
"suppress" property to "true" to suppress directory listings
when no welcome file is present.
NOTE: This setting applies to *all* web applications that
are running in this instance of Tomcat.
-->
<RequestInterceptor
className="org.apache.tomcat.request.StaticInterceptor"
debug="0" suppress="false" />
<!-- Plug a session manager. You can plug in more advanced session
modules.
-->
<RequestInterceptor
className="org.apache.tomcat.session.StandardSessionInterceptor" />
<!-- Check if the request requires an authenticated role.
-->
<RequestInterceptor
className="org.apache.tomcat.request.AccessInterceptor"
debug="0" />
<!-- Check permissions using the simple xml file. You can
plug more advanced authentication modules.
-->
<RequestInterceptor
className="org.apache.tomcat.request.SimpleRealm"
debug="0" />
<!-- UnComment the following and comment out the
above to get a JDBC realm.
Other options for driverName:
driverName="oracle.jdbc.driver.OracleDriver"
connectionURL="jdbc:oracle:thin:@ntserver:1521:ORCL"
connectionName="scott"
connectionPassword="tiger"
driverName="org.gjt.mm.mysql.Driver"
connectionURL="jdbc:mysql://localhost/authority"
connectionName="test"
connectionPassword="test"
"connectionName" and "connectionPassword" are optional.
-->
<!--
<RequestInterceptor
className="org.apache.tomcat.request.JDBCRealm"
debug="99"
driverName="sun.jdbc.odbc.JdbcOdbcDriver"
connectionURL="jdbc:odbc:TOMCAT"
userTable="users"
userNameCol="user_name"
userCredCol="user_pass"
userRoleTable="user_roles"
roleNameCol="role_name" />
-->
<!-- Loaded last since JSP's that load-on-startup use request handling -->
<ContextInterceptor
className="org.apache.tomcat.context.LoadOnStartupInterceptor" />
<!-- ==================== Connectors ==================== -->
<!-- Normal HTTP -->
<Connector className="org.apache.tomcat.service.PoolTcpConnector">
<Parameter name="handler"
value="org.apache.tomcat.service.http.HttpConnectionHandler"/>
<Parameter name="port"
value="6666"/>
</Connector>
<!--
Uncomment this for SSL support.
You _need_ to set up a server certificate if you want this
to work, and you need JSSE.
1. Add JSSE jars to CLASSPATH
2. Edit java.home/jre/lib/security/java.security
Add:
security.provider.2=com.sun.net.ssl.internal.ssl.Provider
3. Do: keytool -genkey -alias tomcat -keyalg RSA
RSA is essential to work with Netscape and IIS.
Use "changeit" as password. ( or add keypass attribute )
You don't need to sign the certificate.
You can set parameter keystore and keypass if you want
to change the default ( user.home/.keystore with changeit )
-->
<!--
<Connector className="org.apache.tomcat.service.PoolTcpConnector">
<Parameter name="handler"
value="org.apache.tomcat.service.http.HttpConnectionHandler"/>
<Parameter name="port"
value="6667"/>
<Parameter name="socketFactory"
value="org.apache.tomcat.net.SSLSocketFactory" />
</Connector>
-->
<!-- Apache AJP12 support. This is also used to shut down tomcat.
-->
<Connector className="org.apache.tomcat.service.PoolTcpConnector">
<Parameter name="handler"
value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/>
<Parameter name="port" value="6668"/>
</Connector>
<!-- Apache AJP13 support. This is also used to shut down tomcat.
-->
<Connector className="org.apache.tomcat.service.PoolTcpConnector">
<Parameter name="handler"
value="org.apache.tomcat.service.connector.Ajp13ConnectionHandler"/>
<Parameter name="port" value="6669"/>
</Connector>
<!--
TIMEWEAVER APPLICATION DOCUMENT ROOT
-->
<Context path="/" docBase="/path/to/your/document/root/" debug="5" reloadable="true" >
</Context>
</ContextManager>
</Server>
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
"http://java.sun.com/j2ee/dtds/web-app_2.2.dtd">
<web-app>
<servlet>
<servlet-name>foo</servlet-name>
<servlet-class>my.class.path.foo</servlet-class>
<load-on-startup>0</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>foo</servlet-name>
<url-pattern>foo</url-pattern>
</servlet-mapping>
</web-app>
httpd.conf
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
