tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harish Prabandham <Harish.Praband...@eng.sun.com>
Subject Re: Server to Container interface
Date Thu, 21 Oct 1999 16:43:04 GMT
Hi,



>
>
> 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.
>

Please mark it deprecated for a little while & provide an alternative way to get around
it before removing it.


>
> >
> > 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 the
> > 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
is
> > 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 can't
> > set
> > the fields - for example the case Craig mentioned where all data is get from a callback,
in
> > 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 setters
> > 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 needed
> -- you could build createRequest() and createResponse() methods into the basic Connector
> interface if you needed factory methods somewhere.
>
> >
> > What do you think ?
> >
> > Costin
> >
>
> Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message