tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kevin seguin <seg...@motive.com>
Subject Re: [jakarta-tomcat-connectors] a dilemma ...
Date Tue, 15 May 2001 19:43:54 GMT
> > 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.

Mime
View raw message