Good morning Costin. Apologies for the silence. I had hoped there might have been a little more input from others on this topic.
Same here :-)
However the most common case is to have at least one tomcat, and there is no real benefit in supporting an arbitrary name for the worker ( lb:lb ) or in mapping the request directly to the protocol. I think the goal should be to have the protocol ( ajp worker ) register itself automatically with the lb:lb.
That mapping only exists now because it is implemented by the worker. The worker is the logical recipient if the functionality offered by the lb worker was not required. (There is enough for a worker to manage, even without the protocol, to justify its existence as an object.). All that is missing from the scenario is the protocol to be a part of the channel or perhaps an intermediate layer.
Not sure what you mean - the "worker" name is very overloaded, there are many ways to interpret.
My point was that the mapping is done between a URI and a tomcat ( either a standalone instance or a group ). This is represented by "lb" - which should be the only target for the mapping.
The lb will then use a channel ( ajp object ) to connect to the tomcat. The role of "lb" is to implement the forwarding of the request via the "ajp" object, with load balancing or failover ( if multiple channel/ajp objects exist ).
The fact that both the channel ( ajp ) and the lb are implementing the "worker" interface is IMO confusing. I think it's better to have an "lb" that can dynamically be configured with more channels, does retry, balancing and failover - as a separate entity- separated from the channel ( that just forwards a request ).
IMO getting to this point requires removing some of the (arbitrary ) flexibility in naming workers or bypassing the lb.
From an 'objects' perspective, it is inconsistent with current practice to'parse' object names (CN in ldap parlence) for properties of the object, when those properties have unique identifiers such as port and host. Hence I support arbitrary naming.... ;-(
CN ( and distinguished names in JNDI as well as jmx object names ) is the source for the object names in jk2.
I know it's a religious issue if the name should mean something or not - and probably that's a reason we'll have to keep supporting the arbitrary names.
IMO we should deprecate the arbitrary names and only support JMX-like object names, with using the properties to extract information like host, etc.
In any case - it's Henri and the other people actively involved in this release you need to convince :-)
Costin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
