Re: Container <-> protocol dependancy

["Krzysztof Rzymkowski" <rzymek@gmail.com>]

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?
2. HttpServletRequest extends the functionality of ServletRequest. It should
only inherit from ServletRequest. It's not supposed to be a wrapper on
ServletRequest.
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.
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.