tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)
Date Mon, 30 Jun 2003 09:30:25 GMT

----- Original Message -----
From: "Brian Olsen" <griff@maven-group.org>
To: <tomcat-dev@jakarta.apache.org>
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: 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


Mime
View raw message