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 21:58:41 GMT wrote:

> > 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
> > yet thought up a case where I would really prefer the HttpServletRequest implementation
> > object to be different than the Request implementation object).
> Great. What about waiting one more day for feedback, and I'll make the change this weekend?

Sounds good to me.

> The only argument I see for keeping the Facade is somehow security-related: right now
> we assume a servlet can't change the request fields.
> If the user gets an object with public set methods, he might cast and do bad hacking.
> ( for example set authentication and do a forward ).

I'm pretty sure that if the underlying implementation class is not public, then you'd have
to be
in the org.apache.tomcat package to be able to do the cast (to RequestImpl) without an
IllegalAccessError exception.  Unfortunately, though, that would also mean that subclasses
RequestImpl would also have to be in the package if RequestImpl was not public.

Sounds like security is a pretty good reason to keep the facade.

> ( same is possible today - RequestFacade has a public  getRealRequest() - need to figure
> out where it is used ).

If it's not used, or current use can be replaced with something different, I'd vote for getting
rid of this.

> If this is a concern - we can keep the Facade with only get methods, make getRealRequest()
> a "package" method ( accessible only inside core ). Creating a Facade in addition to
> real
> object is not too expensive - both objects can be reused, so we don't have too much garbage.
> If we keep the Facade: in Request I would like to have only get methods ( plus whatever
> needed
> internally). RequestImpl will be non-abstract ( i.e. concrete :-), and will have all
the set
> methods.
> The reason: ServletAPI doesn't require setting. We may have a valid Request which just
> set
> the fields - for example the case Craig mentioned where all data is get from a callback,
> which case
> we don't implement setters.

If you don't have setters, how do you deal with some of the RequestDispatcher semantics where
the existing request is modified?

> Adding setters to the interface means our API assume set to work. We can have a
> "SettableRequest",
> but again - if the concrete object has local storage, it can just be RequestImpl.
> RemoteRequest or ApacheRequestWithCallbacks may have no local storage.
> That means 3 ways to create a request: either implement the get methods from Request,
> or use RequestImpl + setters, or extend RequestImpl and override few getters and use
> for the rest.
> Regarding "RequestFactory" - we know a bit too little about that, is it needed?
> My view of a "Server Connector" is:  a communication protocol that use
> RequestImpl/ResponseImpl
> ( or implements Request/Response interfaces). It's up to the connector to
> create/reuse/manage
> Request objects.

I agree ... only the connector knows what Request and Response implementation classes to use,
and it will probably want to recycle them anyway.  A separate RequestFactory doesn't seem
-- you could build createRequest() and createResponse() methods into the basic Connector
interface if you needed factory methods somewhere.

> What do you think ?
> Costin


View raw message