mod_jk provides the communication between the web server and tomcat. It does so by using a number of abstractions:
jk_service: represents the request and the callbacks supported by the web server. jk_endpoint: abstracts the callbacks supported by tomcat. The communication is done by passing messages. Each side has a dispatcher that receive message and calls the right method. AJP13 supports a minimal set of callbacks - only what's required to forward the request and get the response. AJP14 adds more - authenticating the connection and a discovery mechanism allowing auto-configuration of jk. There are more callbacks that were discussed, and a number of possible optimizations and features could be added. My proposal is to abstract the callback using jk_handle ( on the C side ), AjpHandler ( Java side ). The java side was already implemented for Ajp14 ( not perfect yet, just a start ). I would like to change the current Ajp13 connector to use the same model and callbacks ( Ajp14 is backward compatible, we now duplicate some code ). On C side, the handlers will implement a similar interface. The current object factory ( used to create workers, channels ) will also be used to register handlers. The 3 callbacks in jk_service and the discovery callback in ajp14 will implement the jk_handler interface. Right now the server adapter is implementing the jk_service interface - the change is quite small, the same methods will be used, just with a different initialization. The main benefit is that we'll be able to easily add more callbacks with minimal code changes. A second benefit will be that the code will be easier to understand, and the same abstractions will be used in both java and C side. I'm ( reasonably ) confident this change will have minimal impact on code stability. What do you think ? Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>