tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cmanola...@yahoo.com
Subject Re: TC3: Request/RequestImpl
Date Tue, 15 Aug 2000 19:02:45 GMT
> After looking some more at our implementation, perhaps I could
> do a little rearchitecting and extend the Request/Response objects
> in Tomcat, if no one else needs the interfaces and it makes a big
> difference in the simplicity and performance of the Tomcat internals.

I'm fine with using interfaces if at least someone needs them.
( I do enjoy having 12 files in core instead of 14 :-)

After the old code is removed and we finish the charset conversion ( the
MessageBytes and lazy Strings ) we can open this again - you might find
it's easier and cleaner without the interfaces. It's your call.

> As for MessageBytes instead of Strings, that is a great idea.
> Also, on removing deprecated methods that is good too, since
> there seems to be a lot of stuff left hanging around in Request/Response.

Would anoyone have a problem with using the same method names with
different return type ? 
MessageBytes getUri() instead of String getUri() ?

All existing code can be easily converted with getUri().toString(),
and setters will be getUri().setString(" ")

The alternative is to add new method getUriMessageBytes or getUriMB.


Costin
> 
> So maybe it's not necessary to roll back to interfaces.
> I will do some experiments with tomcat 3.3 and see if it's ok.
> If no one else is using the interfaces then maybe it doesn't need
> to go back in.
> 
> Thanks.
> Shawn
> 
> cmanolache@yahoo.com wrote:
> 
> > Hi Shawn,
> >
> > That's why I asked - I couldn't guess if anyone is using the interfaces.
> >
> > I will add back the interfaces. I'm removing deprecated methods that are
> > not used ( some I don't even know what they originally did - some used in
> > mapping ). I also want to add methods that will use MessageBytes to get
> > the fields ( uri, queryString, path components).
> >
> > Using MessageBytes instead of String in request is vital for supporting
> > different charsets ( the encoding will be known _after_ all headers are
> > read, or even in 2.3 when the user sets it ). It is also vital for
> > performance ( most servlets don't call getProtocol, getMethod, etc - so
> > there is no need to create the objects )
> >
> > All that means there will be new methods in Request and methods will be
> > deprecated. At least until the encoding is known all String methods will
> > return a  wrong value.
> >
> > It is much easier for me to do that on Request as a class, but I'll move
> > back to interface.
> >
> > BTW, if your use of Request/Response is as an "adapter", it may be easier
> > to just use the classes instead of interfaces. Request/Response are an
> > adapter in the first place ( between a server using a different
> > representation and tomcat ) - you can extend the class and override some
> > or all of the methods, but still keep the ones you don't override.
> >
> > Let me know how urgent it is to put back the interfaces ( I did the change
> > since I received no comment so far, but it's trivial to move back )
> >
> > Costin
> >
> > On Tue, 15 Aug 2000, Shawn McMurdo wrote:
> >
> > > Hi Costin,
> > > Although the Tomcat server adapters don't use the
> > > Request/Response interfaces that does not mean that
> > > others who are embedding Tomcat (like Enhydra) are
> > > not using these interfaces.
> > > In any embedding environment where the external connections
> > > create their own Request/Response objects it is necessary to
> > > have these interfaces.
> > > Tomcat started out with Adapters in 3.0, went to interfaces in 3.1,
> > > extended the interfaces in 3.2 and now (if I understand the proposal)
> > > you want to remove all capability for non Tomcat Request/Response
> > > objects to be used.
> > > I thought the ability for Tomcat to be embedded into other applications
> > > and architectures was a goal of the project.
> > > I don't see a compelling reason to remove this ability and I don't
> > > understand why removing the interfaces is of any real benefit.
> > > Shawn
> > >
> > > Costin Manolache wrote:
> > >
> > > > Hi,
> > > >
> > > > Some time ago ( 4-5 months) I made a proposal to transform Request (
> > > > then a normal
> > > > class) into an interface, with RequestImpl as a default implementation.
> > > >
> > > > The idea was that Apache, IIS, etc will implement the interface with
> > > > specific code. A bigger goal was to keep the interfaces as a common
> > > > ground for different architectures,
> > > > with only the core difference beeing ... different.
> > > >
> > > > What happened is that all server adapters are extending RequestImpl and
> > > > overriding
> > > > 2-3 methods.
> > > >
> > > > I think the original assumption was wrong and I would like to go back.
> > > >
> > > > There is almost no changes in user code - you can use Request the same
> > > > way
> > > >  as before in Interceptors, and server adapters need 1-line change.
> > > >
> > > > Note that in the next few weeks we will remove a number of fields and
> > > > methods from
> > > > Request ( all deprecated ), and will add slowly MessageByte-based
> > > > getters instead
> > > > of String. This will allow us to ( finnaly ) reach ( almost ) GC-free
> > > > operation and will have a big impact on performance.
> > > >
> > > > ( and same for Response - it's Request/Response ).
> > > >
> > > > Costin
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> > >
> > > --
> > > Shawn McMurdo              mailto:shawn@lutris.com
> > > Lutris Technologies        http://www.lutris.com
> > > Enhydra.Org                http://www.enhydra.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> --
> Shawn McMurdo              mailto:shawn@lutris.com
> Lutris Technologies        http://www.lutris.com
> Enhydra.Org                http://www.enhydra.org
> 
> 
> 
> ---------------------------------------------------------------------
> 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