Hi Colin,
This idea is ( surprise ) already implemented, as part of the IIS
connector. It isn't a config file, but a properties file ( much easier to
parse and work with ).
We already discussed few times about adding this configuration "style" to
the other containers ( apache, nes ) - so your work will certainly be
helpfull.
One problem ( and that's common to apache as well ) is that if you are
using the NameTrans ( or SetHandler ), that means netscape/apache is
managing the mappings. By using the jk mapper, the whole thing is
duplicated, and that will affect ( slow down ) _all_ requests that are
processed by the server.
We are trying to enhance the "native config style", allowing the user to
use standard Apache directives ( SetHandler, etc ). This is also part of
the effort to integrate the authentication ( use apache to do auth, etc ).
Of course, this is just a choice - each config style has its benefits.
Regarding the config, the most common 2 cases shouldn't require any
additional user configuration.
- one web server, one tomcat instance - all the contexts are configured in
server.xml, tomcat can generate a config or, via Ajp14, send the config
on the wire
- one web server, pool of load-balanced tomcats - almost the same, there
is only one worker ( lb ) and the config can be generated with no extra
user info.
- one/many web servers, dispatching to different tomcats based on context
using different workers. For this you'll need some extra info, but I would
place it on the <Context> level ( or/and AutoWebApp ), it's much easier to
have it in a single place. Again, the properties file can be generated
from server.xml or sent on the wire.
The goal is to have the user do minimal configuration. It's not easy, and
it also mean the user will have less flexibility, but it's a good idea.
Anyway - it would be great to add this to NES and apache, and IMHO it
would be better if instead of spending your time parsing xml in C you
would add support for virtual host in the config file ( that would be
usefull for IIS, NES and Apache ). Right now virtual hosts work only with
manual configuration.
Costin
( I hope I didn't confused you - there is a lot of flexibility and
choices, and many possibilities )
On Thu, 9 Aug 2001, Colin Wilson-Salt wrote:
> I've been looking at the existing web server integration stuff (both mod_jk
> and mod_webapp), and it seems to me that there is one significant piece
> missing - a NameTrans directive that takes its configuration from a separate
> file.
>
> I know I'm talking iPlanet here - but that's where my experience is.
>
> At the moment I'm running a bodged together iPlanet / Tomcat 4 combo where
> the servlet requests are http-proxied to Tomcat, but I need to to the
> NameTrans part myself:
>
> NameTrans fn="assign-name" from="/myapp/firsturl" name="tomcat"
> NameTrans fn="assign-name" from="/myapp/secondurl" name="tomcat"
>
> Obviously you don't want hundreds on NameTrans directives to maintain in
> obj.conf, and you don't want your Java developers fiddling with your web
> server configuration.
>
> I don't do Apache, so I don't know whether there is an equivalent issue
> there.
>
> It seems to me that a single configuration file that is read at web server
> init time, that tells the web server where the webapps are, what url
> prefixes they map to, and whether they are distributable etc would be a good
> idea.
>
> Something like:
>
> <deployment>
> <connection name="serverone" type="warp">
> <host>hostone</host>
> <port>8081</port>
> </connection>
> <connection name="servertwo" type="warp">
> <host>hosttwo</host>
> <port>8081</port>
> </connection>
> <webapp name="myapp" distributable="no">
> <url-mapping>/myapp</url-mapping>
> <connections>
> <connection>serverone</connection>
> <connection>servertwo</connection>
> </connections>
> </webapp>
> </deployment>
>
> Does this sound sensible? I think I want this for myself anyway, so I might
> see if I can knock it up. The only complex thing would be parsing the file
> (I want to stick to C - so I don't know what I'd do about XML parsing). Does
> anyone have any opinions? Am I duplicating any previous work?
>
