Re: Container <-> protocol dependancy

["Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>]

Krzysztof Rzymkowski wrote:

>Here are my point on why not to do
>   HttpServletRequest  request (req);
>
>1. ServletRequest's methods (as in JavaServlet API) do not provide enought
>information to allow the creation of HttpServletRequst. For example how can
>I create a RequestDispather having only a ServletRequest?
>  
>
Bad example - RequestDispatcher is part of javax.servlet package,
not javax.servlet.http, and theoretically servlet might request
non-HTTP resource through getRequestDispatcher() interface
(presuming different kinds of servlet can live within same
ServletContext, which is something that isn't clear to me).

>2. HttpServletRequest extends the functionality of ServletRequest. It should
>only inherit from ServletRequest. It's not supposed to be a wrapper on
>ServletRequest.
>  
>
"Not supposed to be"? ;-)
There is nothing wrong with providing extended object that wraps
around some other object of base class. It isn't used often, and it
doesn't make sense often, but is reasonable under certain
circumstances.

>3. If the container creates internally HttpServletRequest object
>implementation it can provide a more optimized one. For example I can use
>internal Apache methods to get information about the request. Something
>imposible when creating HttpServletRequest just from ServletRequest.
>  
>
Now, _this_ is the argument ;-)

>4. And finally this is how Tomcat does it.
>  HttpServletRequest request = (HttpServletReques)req;
>
>Cheers
>  Chris Rzymkowski
>
>2006/2/27, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
>
>  
>
>>Question: should servlet container actually know
>>what kind of servlet it is calling now. i.e. Should it
>>know exactly that this particular request will be
>>handled by HttpServletRequest derivative
>>(and thus pass HttpServletRequest and HttpServletResponse
>>to service() method).
>>
>>Another option would be for container to create
>>ServletRequest and ServletResponse objects,
>>which would only describe and pass data of the request,
>>while servlet itself figures out if that data is in fact
>>adequate for its protocol.
>>
>>First approach simplifies implementing servlet
>>containers that only support single protocol (i.e. HTTP).
>>Second one allows container to handle multiple
>>protocols in clean manner.
>>
>>Why was it brought up?
>>I am looking at Krzysztof's public API, and
>>HttpServlet::service(ServletRequest&, ServletResponse&)
>>is implemented as follows:
>>
>>void  HttpServlet::service(ServletRequest& req, ServletResponse& res) {
>>    HttpServletRequest &request =
>>        dynamic_cast<HttpServletRequest&>(req);
>>    HttpServletResponse &response =
>>        dynamic_cast<HttpServletResponse&>(res);
>>    service(request, response);
>>}
>>
>>Last time I wanted to do API separation, and was discussing it with
>>Alex Shor, idea was to do something along the lines of:
>>
>>void  HttpServlet::service(ServletRequest& req, ServletResponse& res) {
>>    HttpServletRequest  request (req);
>>    HttpServletResponse response(res);
>>    service(request, response);
>>}
>>
>>In this case HttpServletRequest/Response constructor would use
>>wrapped object to extract HTTP-specific data, and implement non-HTTP
>>specific functions by delegating them to wrapped object.
>>
>>In the latter case, there would be single data transfer and servlet
>>mapping
>>code, but actual protocol interpretation would be left to mid-layer
>>that would sit on top of base API.
>>    
>>
>
>  
>

-- 
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com