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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
