jk_handler

[cm...@yahoo.com]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: jk_handler

[Michael Jennings <mi...@southgatesoftware.com>]

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: <cm...@yahoo.com>
To: <to...@jakarta.apache.org>
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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: jk_handler

[Gomez Henri <hg...@slib.fr>]

En réponse à cmanolache@yahoo.com:

> 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 : hgomez@slib.fr        (. .)                     
PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>