----- Original Message ----- From: "Brian Olsen" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 30, 2003 1:31 AM Subject: Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)
> Remy Maucherat wrote: > > Brian Olsen wrote: > > > >> Hey Guys, > >> > >> I just made a proposed patch for the enhancement request I made > >> regarding the SIP Servlet API > >> http://issues.apache.org/bugzilla/show_bug.cgi?id=21169 > >> > >> It adds a new interface org.apache.catalina.ServletSession that > >> contains the methods that HttpSession has in common with > >> SipSession and SipApplicationSession. > >> > >> The interface changes are non-intrusive meaning that it changes or > >> adds no functionality so if a class implements HttpSession it will also > >> implement all the methods in ServletSession. > >> > >> To make catalina support the new interface have have made the > >> following changes: > >> org.apache.catalina.Session - changed to return a ServletSession in > >> the getSession() method > >> org.apache.catalina.session.StandardSession - makes it implement > >> ServletSession and typecasts to HttpSession where needed. > >> org.apache.catalina.session.StandardSessionFacade - makes it implement > >> ServletSession > >> org.apache.coyote.tomcat5.CoyoteRequest - typecasts from > >> ServletSession to HttpSession in the getSession( boolean ) > > > > > > I'm not that thrilled by the patch, because we made the decision in TC 5 > > to work only with the HTTP protocol, for complexity reasons. Actually, > > it's merely the underlying protocol having to behave like HTTP (although > > the older TC 4.0 was supposedly protocol generic, it ended up being > > designed with HTTP in mind, so it wasn't much better). > > > > I know a bit the SIP spec, and that patch would sove the problem for > > sessions. How do you plan to solve it for the connector ? > > (the idea is that Coyote - supporting HTTP and JK - will remain the only > > supported connector in TC 5, the internal Catalina API being conserved > > for compatibility, or at least easy porting, of any old Catalina module) > I don't see how there should be a problem with the connector, besides > the fact that it has to also do outgoing connections. This only means > that it gets a little more complex than the ordinary connector but not > anything I have worries about. > > It is sad that you made that descision especially with the arrival of > SIP Servlets that is the first real specification for using servlets for > something other than HTTP. Before you could only guess as to how > servlets otherwise could be used. > But how will this decision affect the future of the internal Catalina > API??? Will you deprecate all of it, just parts, redesign it all from > scratch?? Like Remy, I'm -0 on the patch. As I read Remy's post, this means that neither of us will actually veto it if some other developer decides to post it. However, neither of us consider it to be a-good-idea, so we will be looking for implementation holes to veto ;-). The internal Catalina API (e.g. org.apache.catalina.*) is pretty stable. There are no current plans to change it. > > I also have another project further ahead in the process than this one > (It actually has running code), where I have implemented my own RTSP > Servlet API using Catalina and partly based on Coyote. It's my hope to > start making it into a proper Java specification later this year. > > So I'm very interested in what the future internals of Tomcat will look > like since two of my projects rely on them. > > - Brian > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
