>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 ) +1 for JkSet => JkSet LogFile "/var/log/httpd/mod_jk.log" JkSet LogLevel DEBUG JkSet LogStampFormat "%d/%m/%y" JkSet HTTPSIndicator HTTPS JkSet CERTSIndicator SSL_CLIENT_CERT JkSet CIPHERIndicator SSL_CIPHER JkSet SESSIONIndicator SSL_SESSION_ID JkSet KEYSIZEIndicator SSL_CIPHER_USEKEYSIZE JkSet ExtractSSL TRUE The forward options : ? JkSet Forward SSLKeySize JkSet Forward URICompat JkSet Forward URICompatUnparsed JkSet Forward URIEscaped >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. +1 >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 ). -1, I'd like to keep the JkMount as it's absolutly mandatory for fine tuning (ie all examples servlet/jsp handled by TC) but static by Apache. It could be renamed to JkURIMount for example. ><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. What's the planned use for this one ? >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. What about : Jk(2)EnvVar ? Jk(2)MountCopy ? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
