Jk2 config

[co...@covalent.net]

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.

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:

1. JkSet NAME VALUE
Will have exactly the same behavior as NAME=VALUE in a 
workers.properties file.
All settings that you can do in workers.properties today
could be done by JkSet, in httpd.conf. Or all settings
could be done in workers.properties. 

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 uri-workers.properties ( or a better named one ),
the same that we use for IIS. 

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

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


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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jk2 config

[co...@covalent.net]

On Sat, 23 Feb 2002, Bill Barker wrote:

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

To fine-tune - exactly the same tunning can be done by using a 
'JkLogLevel DEBUG' or 'JkSet logLevel DEBUG' or 'logLevel=DEBUG' in 
workers.properties ( same for all other options )

My proposal is to stick with the last 2 as 'default/recommended' in jk2.

A compatibility layer will be added when we deprecated jk1, it's 
not difficult ( so old configs will still work ). But at this 
moment is better to have 'old configs' work by using jk1.
Adding a fourth Jk2LogLevel doesn't get us anything.

Keeping all settings in the same map will simplify other servers as 
well, we'll not have to duplicate the code dealing with properties - it'll
be in common.

> > Set properties on a webapp level. Will be set
> > at <Location> level. An equivalent setting will be
> > in a uri-workers.properties ( 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
> VirtualHosts.

Using uri-workers.properties ( which is equivalent with JkMount ) will
work on all servers ( and is easy to generate ). That should be the 
default.

For performance or fine tunning - <Location> has several benefits,
and allow better integration into apache. And it works fine with
VirtualHosts :-). 

I believe iPlanet and IIS may have some equivalent 'native' mapping
rule - and it would be nice to support it as well, but the 
properties are going to work fine. 


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

If you're thinking about the uri properties file - we can improve this,
and hopefully you'll not have to touch this ever.

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

If we use <Location> style, we'll have a 
<Location /examples>
   JkWebapp worker ajp13
</Location>

<Location /examples/servlets/* >
  JkServlet name invoker
</Location>

<Location /examples/foo/* >
  JkServlet name myServlet
</Location>

Both JkWebapp and JkServlet are to be used with 'native' ( and probably
more performant and well 'integrated' ) mode. 


Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jk2 config

[Bill Barker <wb...@wilshire.com>]

I'm understandably fond of ApacheConfig, but I realize that we can do
better.  For the rest, see inline.
----- Original Message -----
From: <co...@covalent.net>
To: <to...@jakarta.apache.org>
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:
>
> 1. JkSet NAME VALUE
> Will have exactly the same behavior as NAME=VALUE in a
> workers.properties file.
> All settings that you can do in workers.properties today
> could be done by JkSet, in httpd.conf. Or all settings
> could be done in workers.properties.
>
> 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 uri-workers.properties ( 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
VirtualHosts.

>
> 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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>