RE: [jakarta-tomcat-connectors] a dilemma ...
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. 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.
Re: [jakarta-tomcat-connectors] a dilemma ...
i actually decided to copy a bunch of low-level utility classes from tc 3 to jtc/util until something like a jakarta-tomcat-commons exists... GOMEZ Henri wrote: 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. 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.
RE: [jakarta-tomcat-connectors] a dilemma ...
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: A study of common interface to this specialized ORB/HTTP could be conducted now. Tomcat has no more than 3 differents implementations (3.2/3.3/4.0)... It will be profitable to all tomcat community to have people from differents teams 3.2/3.3/4.0 speak of this subject... 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. The best solution will came from discussion in tomcat-dev. And if there is no discussion here, I suggest you ask the question to others communities, for example the one from jetty.org
Re: [jakarta-tomcat-connectors] a dilemma ...
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.
Re: [jakarta-tomcat-connectors] a dilemma ...
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.
[jakarta-tomcat-connectors] a dilemma ...
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.
