Re: jk2: config
[EMAIL PROTECTED] wrote: I just commited a big chunk of config changes to support dynamic configuration of jk2. I'm pretty happy with the new model - many new things will become possible. As you know, I'm usually a bit extreme regarding backward compatibility. Preserving it is still possible - but I'm now convinced it would be much better to not do so. We could write a converter from old format to new format if too many people complain. The current code follows a single pattern: [OBJECT_NAME].[PROPERTY]=value OBJECT_NAME can be either a previously defined object ( like 'logger', 'workerEnv', 'config' ) or a new object that is created when the name is first reached. The object is created using a factory that matches the prefix. Ex: worker.ajp13.8009.channel=socket In this case, channel is the property, and worker.ajp13.8009 is the object name. It'll match the factory for 'worker.ajp13'. No need to specify 'type' or 'worker_list' or to use any other constructs. The property can be set at any time - but not all objects and all properties support run-time config ( at this moment - we'll add this in time ). The whole idea is that the config is intended for config tools or other frontends - or at least that's the goal. We want to allow user configuration, but in order to support ajp14 and dynamic config ( like deployment of webapps, etc ) we need to let mod_jk write the config file. Axis does the same thing with the wsdl, same for kde, gnome, etc. The config is editable, but when the program runs it will manage it and save it. The main problem is that the comments may be lost, and any manual change done while the server is running will probably have the same fate. A warning in the first lines of the file like: +++ # # NOTE: This file is automatically updated by the autoconfigure. # Any changes will be lost! # +++ is probably enough. Again, this is not for the first release of jk2, but IMHO it should follow soon. One idea I'm considering is to use the ini style for URIs. That is: [object_name] propery=value ... This will make the syntax much cleaner for URIs. It's a well-known format, used in many cases and programs - far better than inventing our own ( and better than hacking the name/value ). Of course, XML may be a better choice - but I won't volunteer to do xml processing in C :-) If the file is handled by program it does not need to be nice: for me the property format is enough. And -0 for using xerces C to do that... I want to run mod_jk on EBCDIC machines and porting xerces C is some work. What about parsing the xml file in Java? ;-) 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]
RE: jk2: config
If the file is handled by program it does not need to be nice: for me the property format is enough. And -0 for using xerces C to do that... I want to run mod_jk on EBCDIC machines and porting xerces C is some work. What about parsing the xml file in Java? ;-) Hi Jf, Did you have expat ready on your boxes ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk2: Config changes ( again )
[EMAIL PROTECTED] wrote: On Tue, 12 Mar 2002, jean-frederic clere wrote: myworker1= Would be the same as: myworker1=ajp13://localhost:8009?lbfactor=0debug=ERROR (no load balancing and only log error messages). How to describe AF_UNIX or shared memory (as transport but not protocol)? myworker1=ajp13://file_name:afsocket?lbfactor=0debug=ERROR myworker1=ajp13://key_file:shm?lbfactor=0debug=ERROR Good question... ajp13:aprChannel:/tmp/tomcat.socket? or apj13:channel.apr:/tmp/tomcat.socket?lbfactor=0... ajp13:jniChannel?lbfactor=0debug=0 If no channel is specified, default to the socket channel. ajp13:channel.socket://localhost:8009 ajp13://localhost:8009 Ok, so the question is: which form ? The goal is to be intuitive, easy to type, easy to explain. It seems some hierarchical naming is the best way ( but which form ? ). So far we have the following: - separators do not matter ( syntactical sugar ) - . : / _ - - each 'name' is hierarchical - a name with a single component ( myworker1 ) defines an alias, for easier typing. The RHS will be the real name. Question: should it be alias.myworker1=ajp13:// ? Why do we alias? - The first part of the hierarchical name will identify the type. - The second part of the hierarchical name be used by the constructor. For example, the ajp13 constructor will take the local part and interpret the first component as a channel name, then what's after ? as parameters. What do we do about properties ? Are we going with 2 styles - a URL style and a workers.properties style ? No... We should choose one. In workers.properties style: ajp13.[LOCAL_PART].port=8009 ajp13.[LOCAL_PART].debug=0 ajp13.[LOCAL_PART].lbfactor=1 More ideas ? Implementing this is not trivial, but I would hate to have to do it again. 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]
Re: jk2: Config changes ( again )
[EMAIL PROTECTED] wrote: On Tue, 12 Mar 2002, jean-frederic clere wrote: What to do when myvhost is www.apache.org for example... uri.www.apache.org:/examples.worker? Using ':' instead of '.' does not solve the problem. Sounds good. If we use a hierarchical name we also solve the 'type' restriction: worker.ajp13_9009.port=9009 or worker.ajp13.9009.port=9009 Each name must start with the type. Quotes can be used for the local part, and will be ignored. The local part can be used in the constructor ( I mean factory :-) for additional heuristics, to reduce the amount of configuration. worker.ajp13.host2.foo:8009 or worker.ajp13.host2.foo:8009 I would still like to have : and uri-style names at least as an option. What about using URI for name: ajp13://host.foo:8009/?lbfactor=1 or ajp13://host.foo:8009/;lbfactor=1 Even better - .:/_- are delimiters, the prefix is used to locate the type ( it can have one or more components ), the last component is used as property. And the property and =value are optional - so ajp13://host.foo:8009 will be a valid construct in workers.properties, the name used in constructor and all properties with default values. If we do that we can simplify the config even more - and eliminate the requirement for a worker to be declared in workers.properties. You just use a uri for the name, in the JkMount equivalent - and we'll know what to do. Even more extreme - use full uri, with query strings. We're in a http server, we should know how to parse this kind of stuff :-) Location /examples JkUriSet worker ajp13://tomcat_host.my.com:8009?lbfactor=10debug=INFO /Location And another idea for workers.properties: myworker1=ajp13://host.name.com:8009?lbfactor=10debug=INFO In this case the name ( without any delimiter ) will act as a shortcut or alias, the RHS will be a URI that will be used in constructor. Both alias or the uri can be used in JkMount/JkUriSet/uri properties. myworker1= Would be the same as: myworker1=ajp13://localhost:8009?lbfactor=0debug=ERROR (no load balancing and only log error messages). How to describe AF_UNIX or shared memory (as transport but not protocol)? myworker1=ajp13://file_name:afsocket?lbfactor=0debug=ERROR myworker1=ajp13://key_file:shm?lbfactor=0debug=ERROR More brainstorming ? Should we post this on tomcat-users, to get more feedback ? 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]
Re: jk2: Config changes ( again )
On Tue, 12 Mar 2002, jean-frederic clere wrote: myworker1= Would be the same as: myworker1=ajp13://localhost:8009?lbfactor=0debug=ERROR (no load balancing and only log error messages). How to describe AF_UNIX or shared memory (as transport but not protocol)? myworker1=ajp13://file_name:afsocket?lbfactor=0debug=ERROR myworker1=ajp13://key_file:shm?lbfactor=0debug=ERROR Good question... ajp13:aprChannel:/tmp/tomcat.socket? or apj13:channel.apr:/tmp/tomcat.socket?lbfactor=0... ajp13:jniChannel?lbfactor=0debug=0 If no channel is specified, default to the socket channel. ajp13:channel.socket://localhost:8009 ajp13://localhost:8009 Ok, so the question is: which form ? The goal is to be intuitive, easy to type, easy to explain. It seems some hierarchical naming is the best way ( but which form ? ). So far we have the following: - separators do not matter ( syntactical sugar ) - . : / _ - - each 'name' is hierarchical - a name with a single component ( myworker1 ) defines an alias, for easier typing. The RHS will be the real name. Question: should it be alias.myworker1=ajp13:// ? - The first part of the hierarchical name will identify the type. - The second part of the hierarchical name be used by the constructor. For example, the ajp13 constructor will take the local part and interpret the first component as a channel name, then what's after ? as parameters. What do we do about properties ? Are we going with 2 styles - a URL style and a workers.properties style ? In workers.properties style: ajp13.[LOCAL_PART].port=8009 ajp13.[LOCAL_PART].debug=0 ajp13.[LOCAL_PART].lbfactor=1 More ideas ? Implementing this is not trivial, but I would hate to have to do it again. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: jk2: Config changes ( again )
Even more extreme - use full uri, with query strings. We're in a http server, we should know how to parse this kind of stuff :-) Location /examples JkUriSet worker ajp13://tomcat_host.my.com:8009?lbfactor=10debug=INFO /Location Good, but Apache oriented And another idea for workers.properties: myworker1=ajp13://host.name.com:8009?lbfactor=10debug=INFO Better since it should be easier to port on non Apache WebServer like IIS/iPlanet, a common synthax In this case the name ( without any delimiter ) will act as a shortcut or alias, the RHS will be a URI that will be used in constructor. Both alias or the uri can be used in JkMount/JkUriSet/uri properties. More brainstorming ? Should we post this on tomcat-users, to get more feedback ? Yes, there is many tomcat/apache admins at tomcat-users... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk2: Config changes ( again )
[EMAIL PROTECTED] wrote: Yes, it's happening again... I feel I'm really close to what I want - so please send feedback ! The goal - improve mod_jk2 configuration. Subgoals: - make it more intuitive / simpler / cleaner - allow runtime changes ( and query ) The proposed solution: Same config model that is used in Java beans. All jk components will have a setProperty() and the config will be 'pushed' by a config module. A component can react at runtime to some config changes ( most don't - but that can change in time, it's the model that matter ). That means no code in mod_jk2 will use things like: jk_map_getStringProperty(worker.ajp13.port ), but the config module will locate 'worker.ajp13' and call setProperty(port, 8009 ). The config module can be pluggable itself - it can read the config from the properties file or from registry, XML, wire protocol ( ajp14 or something else ), LDAP, NDS, whatever :-) Most likely properties file for the first release, of course. Again, we'll deal with named components and properties - I'll not call it jk_mbean, but it'll be close. The syntax for the properties file will be slightly changed ( again ). There are 2 ways to do it: [property]:[object_name]=value [object_name].[property]=value The first property for each object must be 'type' ( with a special exception for URIs ). The type will be used to construct the object, like className in java side. ( I can eliminate this requirement, but later, I want to keep first version simpler ). It is possible ( probably not in the first release ) to get a message if a property name is not recognized ( right now this is siltenly ignored in jk1), or if the value is wrong ( and stop ). The first form is usefull for URIs or names that are 'stranger', the second is good for backward compat. Each object will be created and registered in the jk_env. A getProperty will allow read access to various properties, including dynamically-constructed. Comments please, after I'm done with that I would like to freeze and prepare for an alpha/beta, and it will be harder to change too much. I prefer the form [object_name].[property]=value. That way the file could be handled in Java via ExtendedProperties. 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]
RE: jk2: Config changes ( again )
Yes, it's happening again... I feel I'm really close to what I want - so please send feedback ! Let's go The goal - improve mod_jk2 configuration. Subgoals: - make it more intuitive / simpler / cleaner - allow runtime changes ( and query ) good The proposed solution: Same config model that is used in Java beans. All jk components will have a setProperty() and the config will be 'pushed' by a config module. ok A component can react at runtime to some config changes ( most don't - but that can change in time, it's the model that matter ). ok That means no code in mod_jk2 will use things like: jk_map_getStringProperty(worker.ajp13.port ), but the config module will locate 'worker.ajp13' and call setProperty(port, 8009 ). You mean the config module will locate 'worker.ajp13' call getProperty(port, 8009 ) The config module can be pluggable itself - it can read the config from the properties file or from registry, XML, wire protocol ( ajp14 or something else ), LDAP, NDS, whatever :-) Most likely properties file for the first release, of course. ok Again, we'll deal with named components and properties - I'll not call it jk_mbean, but it'll be close. ;) The syntax for the properties file will be slightly changed ( again ). There are 2 ways to do it: [property]:[object_name]=value [object_name].[property]=value [object_name].[property]=value will help make blocks The first property for each object must be 'type' ( with a special exception for URIs ). The type will be used to construct the object, like className in java side. ( I can eliminate this requirement, but later, I want to keep first version simpler ). It is possible ( probably not in the first release ) to get a message if a property name is not recognized ( right now this is siltenly ignored in jk1), or if the value is wrong ( and stop ). The first form is usefull for URIs or names that are 'stranger', the second is good for backward compat. Each object will be created and registered in the jk_env. A getProperty will allow read access to various properties, including dynamically-constructed. Comments please, after I'm done with that I would like to freeze and prepare for an alpha/beta, and it will be harder to change too much. I agree, let's go -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: jk2: Config changes ( again )
On Tue, 12 Mar 2002, GOMEZ Henri wrote:
but the config module will locate 'worker.ajp13' and
call setProperty(port, 8009 ).
You mean
the config module will locate 'worker.ajp13'
call getProperty(port, 8009 )
setProperty, yes.
The current impl ( not checked in ) adds a new struct,
jk_bean {}, with the set/getAttribute method ( the
attribute doesn't have to be string in the general case,
and I used the naming from jmx ).
All objects are created by jk_env-createIntance(), with a
type and a name - and will have an associated mbean with
the 2 methods.
The name can be used to get the object, env-getByName(),
or the mbean, env-getMBean().
I tried to mirror closely the dynamic mbean model for
configuration - but just the basic setAttribute is
implemented ( more can be added, or implemented in a
java-side wrapper ).
You can set object properties from a normal worker ( like status ),
with a protocol extension ( ajp14 ), or in any other way,
this is independent of the object's implementation.
The syntax for the properties file will be slightly changed
( again ). There are 2 ways to do it:
[property]:[object_name]=value
[object_name].[property]=value
[object_name].[property]=value will help make blocks
The only problem is the URI.
uri:myvhost:8080/examples.worker=ajp13
uri:myvhost:8080/examples.logRequest=true
The alternative:
worker:uri:myvhost:8080/examples=ajp13
( in this example, uri:HOST:PORT/PATH is the name that will be used
for that particular jk_uriEnv_t object ).
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 config
JkSet LogFile/var/log/httpd/mod_jk.log I would use logFile, logLevel - current options in workers.properties start will small caps, and this can go in either w.properties and httpd.conf. ok for logfile, logLevel instead of Logfile/LogLevel. BTW, may be good to UsE aNY CaSE ? The forward options : ? JkSet Forward SSLKeySize JkSet Forward URICompat JkSet Forward URICompatUnparsed JkSet Forward URIEscaped JkSet forward.SSLKeySize true JkSet uriCompat true JkSet uriCompatUnparsed true Or even better: JkSet sslKeySizeForward true JkSet uriForward compat/compatUnparsed/escaped Ok for JkSet sslKeySizeForward true and JkSet uriForward compat/compatUnparsed/escaped 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. JkMount is replaced by: urimap.properties Examples ? I never used urimap.properties since I'm using only Apache 1.3/2.0 user. or ( apache style ) Location /examples JkWebapp worker ajp13 /Location Location /examples/*.jsl JkHandler jakarta/jk2-servlet /Location or JkSet /examples/*.jsp ajp13 We can add a JkUriSet /examples/*.jsp ajp13 Did these are available by Virtual ? If so we could use whatever, even if I prefer : JkUriSet /examples/*.jsp ajp13 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 ? Set properties per/uri - fine tunning, including setting the servlet name - the URI is mapped once by apache, there's no need for a second mapping in tomcat. What about: JkUriSet /uri name value to replace both JkWebapp and JkServlet ? Both are used to set properties associated with a uri - the worker name for the webapp, fine tunning for uris. Example ? JkUriSet /examples name? value? What about : Jk(2)EnvVar ? Jk(2)MountCopy ? JkSet mountCopy true ok JkSet env.NAME DEFAULT_FALUE ok We could also use it in a Location context later JkUriSet env.NAME VALUE In this particular case it may be worth adding a JkEnv directive, but it _must_ have an equivalent in workers.properties and that means a JkSet equivalent too. Could we have with Apache expat parser ? JkUriSet Mount /examples/*.jsp ajp13 EnvVar NAME VALUE /JkUriSet And what about XML parsing like this in IIS/iPlanet/Domino ? Finally how did we use ajp14 autoconf features ? May be via : JkAutoUriSet /examples ajp13 which will return from web.xml via ajp14 protocol /examples/*.jsp /examples/servlet/* /examples/*.xml autoconf is really something nice for the average user -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 config
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]
RE: Jk2 config
On Mon, 25 Feb 2002, GOMEZ Henri wrote: JkSet LogFile /var/log/httpd/mod_jk.log I would use logFile, logLevel - current options in workers.properties start will small caps, and this can go in either w.properties and httpd.conf. The forward options : ? JkSet Forward SSLKeySize JkSet Forward URICompat JkSet Forward URICompatUnparsed JkSet Forward URIEscaped JkSet forward.SSLKeySize true JkSet uriCompat true JkSet uriCompatUnparsed true Or even better: JkSet sslKeySizeForward true JkSet uriForward compat/compatUnparsed/escaped 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. JkMount is replaced by: urimap.properties or ( apache style ) Location /examples JkWebapp worker ajp13 /Location Location /examples/*.jsl JkHandler jakarta/jk2-servlet /Location or JkSet /examples/*.jsp ajp13 We can add a JkUriSet /examples/*.jsp ajp13 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 ? Set properties per/uri - fine tunning, including setting the servlet name - the URI is mapped once by apache, there's no need for a second mapping in tomcat. What about: JkUriSet /uri name value to replace both JkWebapp and JkServlet ? Both are used to set properties associated with a uri - the worker name for the webapp, fine tunning for uris. What about : Jk(2)EnvVar ? Jk(2)MountCopy ? JkSet mountCopy true JkSet env.NAME DEFAULT_FALUE We could also use it in a Location context later JkUriSet env.NAME VALUE In this particular case it may be worth adding a JkEnv directive, but it _must_ have an equivalent in workers.properties and that means a JkSet equivalent too. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jk2 config
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]
RE: Jk2 config
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. +1 - i really like the idea of being able to configure the different web servers +(apache/iis/netscape) in a similar fashion. 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. +1 for the same reasons as above. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jk2 config
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]
