Hi Costin, What about modifying mod_jk so that it can dynamically load .so files (or .dll on windows) that export well-known method names, so that one doesn't need to recompile mod_jk to add different functionality/protocols etc. ? -Mike
----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, November 21, 2001 9:29 AM Subject: jk_handler > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
