[jakarta-tomcat-connectors] a dilemma ...

[kevin seguin <se...@motive.com>]

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.

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.

-kevin.

Re: [jakarta-tomcat-connectors] a dilemma ...

[kevin seguin <se...@motive.com>]

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

i've started down this path (1).  there's a bunch of stuff in tomcat 3
(like MessageBytes) that would be useful...  i posted a message a couple
days ago about putting these kinds of things in a common place, but got
no response.  so, i started using a way scaled down version of my own
MessageBytes as a placeholder.

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

Re: [jakarta-tomcat-connectors] a dilemma ...

[cm...@yahoo.com]

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.