tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject PROPOSAL: mod_jk2 autoconfig
Date Mon, 29 Apr 2002 17:17:19 GMT
I spent a lot of time on this - and I think this is a very good solution.
Please send feedback - the sooner the better...

I think the current solution of generating configs on tomcat startup,
or having tomcat send it's config to apache is wrong. 

Basically what I would like to propose is similar with what Glen 
implemented in jk1 for apache1.3 ( the webapp/ directory auto-conf )- with 
few enhancements. 

The major requirement is that mod_jk2 is configured with the location
of the webapp/ directory. Inside webapp, it'll look for directories
and configure them automatically, like tomcat is doing. 

Some 'special' files ( like in 4.1 and the 3.3 apps- files ) will
also be read and used to load webapps that sit in different directories.

In addition, a separate directory ( named ??? ) can be used with a 
host-based hierarchy. Given that most users are using a single
host and the current webapps/ habbits, the vhost hierarchy will
be different from the 'default server'.

For each discovered webapp ( either directory or CONTEXT.jk2 file ) , jk 
will look for WEB-INF/jk2/ and load the file.

The file will be generated from web.xml - using a
small tool ( I'll commit the first code shortly ) that is independent
of tomcat ( it doesn't require starting tomcat ). It can be used
as CLI, as ant task or as a bean inside an admin or deploy application.

The tool curently uses DOM - and very simple and strictly specialized
code, no "LoadModule" or anything that is beyond web.xml content. 
In addition, the tool may generate Apache-specific configuration 
fragments for the 'native' mapper ( as you may remember, jk2 can 
map URIs using it's internal mapper - but also using <Location>
and Set-Handler directives ). It'll also generate JkMounts for
backward compat. 

All other code from the jk1 autoconf will be separated ( or replaced
with some templates ) - the location of jk, other global settings
are better to be done manually ( and have decent defaults ). 

Finally, the shmem system that is ( will be ) used for autoconfiguration 
of workers ( i.e. when a tomcat starts up it can add itself automatically,
without admin intervention ) can be used by the deploy/admin tool to 
reconfigure uri mappings ( with the common mapper, the native mapper
still requires a soft restart - but that can be automated as well ). 

Implementation-wise - this is not difficult, and can be done pretty
fast if Glenn and few other people step in. 

I believe that's going to be very close to 'minimal' pain for the 
regular user while preserving the ability to fine tune everything.

NOTE: jk2 will use a different model for the lb, see next mail.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message