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]>

Reply via email to