tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hans Schmid" <Hans.Sch...@einsurance.de>
Subject AW: PROPOSAL: mod_jk2 autoconfig
Date Tue, 30 Apr 2002 08:03:46 GMT
See intermixed

> -----Ursprungliche Nachricht-----
> Von: costinm@covalent.net [mailto:costinm@covalent.net]
> Gesendet: Montag, 29. April 2002 19:17
> An: List Tomcat-Dev
> Betreff: PROPOSAL: mod_jk2 autoconfig
>
>
> Hi,
>
> 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.

I can not see how this works if you have Apache and Tomcat on different
machines.
This way we do not have a webapp/ directory on that Apache server.

Or does this work across several machines?

We have two Apache 1.3 servers which are busy serving static contents plus
PHP legacy stuff.
We run at least 4 Tomcats on two different servers to distribute our
webapps.

Did I misunderstand the intent of this configuration? Is it a 'best guess'
for simple setups?
Probably in our scenario we have to configure it manually anyways.

>
> 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.

same here we are on different machines.

>
> 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/map.properties and load the file.
>

I would need a complete webapp structure for configurating mod_jk2 on a
server
which does not have any tomcat - and webapp installed.

Just make sure, everything in the config can be overwritten and configures
manually
if possible in a single file (as workers.properties right now)

But I agree the concept is nice for simple setups.

> The map.properties 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.
>
> Costin
>
>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>

Thanks,
Hans



--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message