mod_jk configuration

[cm...@yahoo.com]

The goals:

1. Full support for all the settings in web.xml. Right now the generated
config fragment is incomplete, security configs are not generated, neither
welcome files.

2. As easy as possible for the admin. The user should install the
.so/.dll, add few lines in httpd.conf, and get a running system. No
further configuration should be needed ( when you add a context for
example ).

3. Support "manual override". We can't expect the "automatic" config
to resolve all the needs, only the common use case. A smart apache admin
with a complex site might want to fine-tune the system. A complex load
balancing site might also want to do advanced settings. 

4. Fit into a "bigger view" - we want to extend the solution with more
features and integrate it into the /admin or some other tools. 

Possible solution:

1. Start by using the same mapping as in webapp, i.e. mount the context
and have all the requests served by tomcat. 

2. Stop generating the current set of files but only 
uri_workers.properties ( which is equivalent with mount directives, only 
simpler and consistent for all supported web servers ) 

3. For some webapps it should be possible to generate a better mapping,
by including all the rules - but if we can't generate something equivalent
with web.xml, we'll fall back to (2).

4. Fix the problem that was pointed by Dirk, i.e. allow explicit mappings
in httpd.conf ( that set handler to script/jakarta ). This will be the 
"override" mode, with explicit settings in the config files.

5. For ajp14, add a set of classes to represent the configuration and the
handler that will send it when the server connects. 

6. (optional) Extend the current config generator to automatically edit 
httpd.conf and include the "Include" statements

I'm still working on a longer term solution that could address more compex
configurations and user tunning ( like server pools, special settings for
security integration, etc ).

Note that we already plan some extensions to ajp14 to support chunks of
static content ( discussed mostly in jasper34 threads I think ), and this
will extend very well for static files ( and reduce the problem that 
static files are served by tomcat intead of apache ).

The extension will send the file name ( and offsets ) instead of the
actual chunk, reducing the wire transfer and letting apache handle the
static content ( assuming it is big enough ). This will be great for
jasper, but also for static files. Also note that this is a temporary
solution ( for static files ), until we figure out a way to map web.xml 
into apache, iis, nes, aol, domino ( or at least jk ) configurations. 

Please send feedback, I'll start implementing some of it tommorow or 
early next week ( I have a vacation - and I  plan to go out for few
days at the end of next week ).

Costin

Re: mod_jk configuration

[kevin seguin <se...@motive.com>]

> 
> 2. Stop generating the current set of files but only
> uri_workers.properties ( which is equivalent with mount directives, only
> simpler and consistent for all supported web servers )
> 

a big +1 on using one common configuration mechanism across web servers
!!!

Re: mod_jk configuration

[Andy Armstrong <an...@tagish.com>]

Can we broaden this out to all connectors? At the moment the IIS
connector has stuff in the registry, the Domino connector has stuff
either in the registry or in an INI file (depending on platform). It's
all a bit messy really.

cmanolache@yahoo.com wrote:
> 
> The goals:
> 
> 1. Full support for all the settings in web.xml. Right now the generated
> config fragment is incomplete, security configs are not generated, neither
> welcome files.
> 
> 2. As easy as possible for the admin. The user should install the
> .so/.dll, add few lines in httpd.conf, and get a running system. No
> further configuration should be needed ( when you add a context for
> example ).
> 
> 3. Support "manual override". We can't expect the "automatic" config
> to resolve all the needs, only the common use case. A smart apache admin
> with a complex site might want to fine-tune the system. A complex load
> balancing site might also want to do advanced settings.
> 
> 4. Fit into a "bigger view" - we want to extend the solution with more
> features and integrate it into the /admin or some other tools.
> 
> Possible solution:
> 
> 1. Start by using the same mapping as in webapp, i.e. mount the context
> and have all the requests served by tomcat.
> 
> 2. Stop generating the current set of files but only
> uri_workers.properties ( which is equivalent with mount directives, only
> simpler and consistent for all supported web servers )
> 
> 3. For some webapps it should be possible to generate a better mapping,
> by including all the rules - but if we can't generate something equivalent
> with web.xml, we'll fall back to (2).
> 
> 4. Fix the problem that was pointed by Dirk, i.e. allow explicit mappings
> in httpd.conf ( that set handler to script/jakarta ). This will be the
> "override" mode, with explicit settings in the config files.
> 
> 5. For ajp14, add a set of classes to represent the configuration and the
> handler that will send it when the server connects.
> 
> 6. (optional) Extend the current config generator to automatically edit
> httpd.conf and include the "Include" statements
> 
> I'm still working on a longer term solution that could address more compex
> configurations and user tunning ( like server pools, special settings for
> security integration, etc ).
> 
> Note that we already plan some extensions to ajp14 to support chunks of
> static content ( discussed mostly in jasper34 threads I think ), and this
> will extend very well for static files ( and reduce the problem that
> static files are served by tomcat intead of apache ).
> 
> The extension will send the file name ( and offsets ) instead of the
> actual chunk, reducing the wire transfer and letting apache handle the
> static content ( assuming it is big enough ). This will be great for
> jasper, but also for static files. Also note that this is a temporary
> solution ( for static files ), until we figure out a way to map web.xml
> into apache, iis, nes, aol, domino ( or at least jk ) configurations.
> 
> Please send feedback, I'll start implementing some of it tommorow or
> early next week ( I have a vacation - and I  plan to go out for few
> days at the end of next week ).
> 
> Costin

-- 
Andy Armstrong, Tagish