One of the major goals of mod_jk2 is simpler configuration. This proposal will cover the 'workers'.
1. The 'worker' name is deprecated. It refers to too many things in mod_jk, and causes too much confusion ( i.e. it is a 'handler', coresponds to a jvmRoute, a protocol, a channel ). 2. We'll use the term 'channel' to define the connections between jk and tomcat. Each channel will follow a standard naming syntax: channel.socket:HOST:PORT channel.unix:/PATH channel.jni:jni Altenatively, the local part can be used as a shortcut. Each channel will use Ajp13 protocol by default ( or whatever is specific to the transport, or overriden ). 3. We'll use the term 'instance' ( XXX or a better name if you can sugest one ) to refer to a single tomcat VM. That's what will be used in the jvmRoute. A tomcat instance can be reached by multiple channels. By default, each instance will have one socket channel and will be named by the local part ( i.e. HOST:port ). That's the name that'll identify the VM. 4. We'll use the term 'group' to reffer to a set of tomcat 'instances' that share a number of applications. The default group will be called 'lb'. One 'instance' can be part of one or many groups. 5. Each URI will be associated with a 'group'. In what used to be: JkMount /examples ajp13 the 'group' will replace ajp13. As I said, the default group is called 'lb' and includes all tomcat instances that are defined. For each application that is installed on all instances, the 'lb' group must be used. If you have a sophisticated setup - and an app is installed only on some instances, you can use names like "lb_examples", and explicitely define what tomcat instances belong to the group. 6. The webapps will be defined by a hierarchy of directories ( host/webapp_name ) ( see previous mail ). Each webapp is obviously mapped consistently to one group, which will be defined inside the WEB-INF/jk2/map.properties. 7. Each channel will have an associated 'instance' ( it can't go to 2 tomcats ) and groups. The lb configuration is done automatically based on those attributes. The mappings are done automatically based on the hierarchy. If no map.properties is found, the whole webapp will be forwarded to the default group ( the common case ). I believe this model covers all current use cases. Please, please, send feedback and let me know if you can help ( implementation, documentation, testing ), but feedback is the first step. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
