tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: Jk2 config
Date Sat, 23 Feb 2002 09:10:30 GMT
I'm understandably fond of ApacheConfig, but I realize that we can do
better.  For the rest, see inline.
----- Original Message -----
From: <>
To: <>
Sent: Friday, February 22, 2002 11:02 PM
Subject: Jk2 config

> I'm going to do few more changes to jk2 config ( unless anyone has a
> better idea ).
> Instead of renaming all config directives with Jk2, I would
> like to just _remove_ them all. If the old directives are
> used in a config, mod_jk1 will do what's expected.

>From what I've read, I'd still like a 'compatibility mode', to allow for
webmasters to fine-tune.  The fatal flaw of mod_webapp was to promise more
than it could deliver (and, no, Pier, I don't want to start a flame-war.
warp could have been very good if it hadn't been orphaned).  But I suspect
that I'm just not fully understanding the proposal.

> I would like to minimze the number of directives to 2-3, and
> keep most of the code common for all servers.
> I'm thinking about:
> Will have exactly the same behavior as NAME=VALUE in a
> file.
> All settings that you can do in today
> could be done by JkSet, in httpd.conf. Or all settings
> could be done in
> For example JkLogLevel DEBUG will be now:
> JkSet logLevel DEBUG ( in httpd.conf )
> or
> logLevel=DEBUG ( in workers.propertes )
> The first style is for people who prefer working with
> httpd.conf, the other one will be easier for IIS/iPlanet
> and may be easier to generate/edit.
> 2. JkWebapp NAME VALUE
> Set properties on a webapp level. Will be set
> at <Location> level. An equivalent setting will be
> in a ( or a better named one ),
> the same that we use for IIS.

AFAIK, the <Location> is unique to Apache and has no equivalent in IIS or
iPlanet.  Even with Apache it is problematic in the presence of

> JkMount is not doing anything special - it's the same
> efect as the properties file we use on IIS. Except that
> properties are easier to generate and will be consistent
> for all servers ( no longer need to generate 3 different
> styles ).

As much as I hate the IIS syntax, I suppose I'll have to hold my nose and
vote +1.

> <Location> will be used for performance, it uses
> the apache mapper instead of jk's.
> 3. JkServlet NAME VALUE
> Set properties per/servlet. I'm not yet finished with
> this one, we may not need it.

-1.  This should be handled by Tomcat (via web.xml), not Apache/IIS/iPlanet.

> After jk2 is finalized and we're ready to drop jk1
> we'll just implement a compat layer - the old options
> in jk1. That's what I did so far, but I think it's
> better to make the switch to a better model and
> keep that only for migration.
> Opinions ?
> Costin
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message