tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [jakarta-tomcat-connectors] a dilemma ...
Date Tue, 15 May 2001 16:50:45 GMT
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

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 ). 


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

View raw message