I'm understandably fond of ApacheConfig, but I realize that we can do better. For the rest, see inline. ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
