On Mon, 14 May 2001, kevin seguin wrote:
> so, i'm looking at decoupling the Ajp13 java stuff from servlet
> container code.
>
> some background... in tomcat 3, the ajp code takes a core tomcat Request
> object and adds decoded information from the ajp request into the
> Request object. when i ported this code from tomcat 3 to tomcat 4, i
> used an object that extended a core tomcat 4 class, HttpBaseRequest.
>
> the dilemma is what to pass to the ajp code that accepts requests in the
> new world where this code could be used by any servlet container. the
> choices as i see them are:
>
> 1) a concrete object (say AjpRequest) that takes and stores information
> from the request
> 2) an interface that has a bunch of set methods.
I would go with (1).
The problem is not only the Request object, but the whole infrastructure
needed for efficient communication ( MessageBytes, Headers, etc ).
In both cases you'll need an adapter - if the connector defines an
interface with set methods, you still need a container-specific object
that implements that interface.
If you use concrete objects - you'll need a container-specific adapter,
that implements container-specific interfaces on top of the connector
objects.
In both cases you need an adapter - but in the first case you have much
more "power" and flexibility in doing "smart" optimizations ( like delay
the send of the headers or pre-processing more on the server side ).
The connector must deal with the communication between servlet
container and web server - and it must hide some of the complexity ( like
how buffers are managed ).
Costin
>
> presumably, any container in which the ajp connector is being used will
> already have some request object with a bunch of set methods, so the
> interface approach is probably less work. however, the concrete object
> approach is probably more efficient, as it's probably easier to delay
> conversion from bytes to strings in this case.
>
> anyway, i'm not really sure what the best approach is -- that's why it's
> a dilemma :) -- so, i'm looking for opinions, suggestions, etc. here.