Home Projects Jobs Clientele Contact


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Container <-> protocol dependancy

Krzysztof Rzymkowski wrote:

>2006/3/1, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
>>Krzysztof Rzymkowski wrote:
>>2. HttpServletRequest extends the functionality of ServletRequest. It
>>>only inherit from ServletRequest. It's not supposed to be a wrapper on
>>"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
>Saying "not supposed to be" I mean that creators of the JavaServlet API
>meant HttpServletRequest to extend ServletRequest, not wrap it.
>HttpServletRequest does not have a constructor  taking a ServletRequest.
Technically, HttpServletRequest is an interface, so does not have
_any_ constructors ;-)

Now, does it mean that implementation of said request should be
provided by container? Maybe.

I.E. instead of saying "container is completely abstracted from protocol",
say "there are two parts for each protocol handler: public API on top
of Servlet/GenericServlet, etc, and implementation on the side of

That seems logical, and on my side, I might create some sort of internal
CPPSERV API for making implementation of different protocol easy.

Now, last issue with your
HttpServletRequest::service(ServletRequest&, ServletResponse&).
It uses dynamic_cast, which in turn means we'll have to use RTTI for
whole servlet container, and all servlets. Not something I'm too happy
about. If we could get around it somehow (while preserving this specific
type check preferably), it would be nice.

Ilya A. Volynets-Evenbakh
Total Knowledge. CTO

Authoright © Total Knowledge: 2001-2008