tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GOMEZ Henri <>
Subject RE: [jakarta-tomcat-connectors] a dilemma ...
Date Thu, 17 May 2001 14:43:56 GMT
>> The problem is not only the Request object, but the whole 
>> 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.

I asked for that one or two weeks ago , at the time I asked 
for jakarta-tomcat-connector). I asked then for a jakarta-tomcat-commons 
sub-project, but there was no usefull answer (only flams and polemics).

We asked also last week for a new CVS, jakarta-tomcat-realms but there is
still no answers ? 

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

View raw message