tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: Server to Container interface
Date Thu, 21 Oct 1999 19:55:27 GMT
James Todd wrote:

> i'm game for this. i must admit that to date i've only
> had a single/tomcat server perspective of this code and
> till now felt that extra levels of abstraction where in
> place to help with the anticipated server portability
> task. that said, i've personally struggled with the multiple
> Request constructs from time to time and as such would
> not be opposed to simplifying/flattening these (request,
> response) structures down a bit.

Yah, it's harder to anticipate what people *might* need in the future when you can
clearly see what they need now.  I think what makes sense is:

public interface Request extends HttpServletRequest - similar method signatures to the
existing Request abstract class.  (The facade thing is not a big deal to me -- I haven't
yet thought up a case where I would really prefer the HttpServletRequest implementation
object to be different than the Request implementation object).

public class RequestImpl implements Request - Concrete implementation of Request,
suitable for all cases where HTTP headers are parsed directly from an input stream.

Customized subclasses of RequestImpl, or implementations of Request, for special

> long ago i created a high-level uml diagram and noticed
> a couple cases of cyclical references that caused me to
> ponder ... then i had to deep dive on servlet 2.2/ri.
> that said, i seem to recall that some of these cyclical
> references where in the request/response constructs.

I ran into the same thing when implementing session support for JSERV1_1DEV.  I could not
figure out a way to pass all of the required stuff back and forth without ensuring that
the request/response pair knew who each other was.  I made it the connector's
responsibility to establish the linkages as it was populating the other properties of the
two objects before handing them off to a service() method.

> - james


View raw message