En réponse à [EMAIL PROTECTED]: > 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 ).
Excellent. > 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 ? Very good ideas, everything which make mod_jk more modular should be included. I love the callback and abstract concept. Let's go with it, my +100 - Henri Gomez ___[_]____ EMAIL : [EMAIL PROTECTED] (. .) PGP KEY : 697ECEDD ...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
