tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <cmcclana...@mytownnet.com>
Subject Re: Server to Container interface
Date Thu, 21 Oct 1999 05:30:55 GMT
costin@eng.sun.com wrote:

> My personal opinion - we should use HttpServletRequest interface only,
> without the Request/Response and drop the Facade pattern.
> ( RequestImpl will be an abstract impl for HttpServletRequest).
> (and use Delegation for Session and other "high" level methods).
>
> Another way is to use a Request interface - i.e. a subset of HttpServletRequest
> plus some extra methods needed internally.  That solve one problem -
> HttpServletRequest have many "high" level methods ( session, etc),
> so it's more than a representation of a server request.
>

In JSERV1_1DEV, we used an approach very similar to RequestFacade, although Request
was an interface rather than an abstract class.  If I remember right, this was
actually Costin's idea, too .... :-)

I agree that Request should really be an interface, though, and RequestImpl should
implement it.  Internal components should pass around Request references.  One
additional property that will be needed is the Connector through which this request
was received.  Among other things, that will be necessary to implement callbacks
via the Apache connector.

Rather than making RequestImpl abstract, I would actually like to see it be
concrete, pretty much moving all of the implemented methods of the current Request
class.  Most Connectors will find it sufficient to have an object that is pretty
much a typical JavaBean (i.e. the get and set methods are one-liners referencing a
private instance variable).

Something fancier, like Costin's proposed lazy instantiation ("don't bother sending
the headers unless the servlet asks for them") could override RequestImpl and be
smarter about this, calling back through the connector on the first request for a
particular property.  An implementation that wanted to extend UnicastRemoteObject
would still implement Request, but would need to provide all the functionality
present in RequestImpl -- that's going to be true pretty much any way we factor
this, due to the single class inheritance rule in Java.

> Costin
>

Craig McClanahan



Mime
View raw message