You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Brian Olsen <gr...@maven-group.org> on 2003/06/30 10:31:01 UTC
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??
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
Re: [PATCH] Change getSession() in org.apache.catalina.Session from
HttpSession to a more general interface (enhancement request 21169)
Posted by Remy Maucherat <re...@apache.org>.
Brian Olsen wrote:
> Remy Maucherat wrote:
>
>> It's not that I do think it's a bad idea, it's just I think there are
>> other problems. I would be willing to consider including the patch
>> (but I need to look into possible side effects first).
>
> What could those side effects be???
You're changing the core API, so you could affect existing components. I
will commit your patch if I find it is safe, and nobody vetoes it.
>> Note: We're talking about 5.0.x here, I think. -1 for inclusion in 4.1.x.
>
> I never thought for it to be in 4.1.x, and the patch is also based on
> the catalina CVS HEAD yesterday.
The diff was against TC 5, so I didn't even consider including your
patch in TC 4.1.x.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PATCH] Change getSession() in org.apache.catalina.Session from
HttpSession to a more general interface (enhancement request 21169)
Posted by Brian Olsen <gr...@maven-group.org>.
Remy Maucherat wrote:
> Bill Barker wrote:
>
>> 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.
>
>
> It's not that I do think it's a bad idea, it's just I think there are
> other problems. I would be willing to consider including the patch (but
> I need to look into possible side effects first).
What could those side effects be???
>
> Note: We're talking about 5.0.x here, I think. -1 for inclusion in 4.1.x.
I never thought for it to be in 4.1.x, and the patch is also based on
the catalina CVS HEAD yesterday.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PATCH] Change getSession() in org.apache.catalina.Session from
HttpSession to a more general interface (enhancement request 21169)
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
> 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.
It's not that I do think it's a bad idea, it's just I think there are
other problems. I would be willing to consider including the patch (but
I need to look into possible side effects first).
Note: We're talking about 5.0.x here, I think. -1 for inclusion in 4.1.x.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PATCH] Change getSession() in org.apache.catalina.Session from
HttpSession to a more general interface (enhancement request 21169)
Posted by Brian Olsen <gr...@maven-group.org>.
Bill Barker wrote:
> ----- Original Message -----
> From: "Brian Olsen" <gr...@maven-group.org>
> To: <to...@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 ;-).
Just try and find any holes ;-) It doesn't add a line of active code
only interface change and typecasts.
But what other reasons is there against the change other than the
principal decision of only supporting HTTP in Tomcat 5??? And Remy
himself says earlier in this thread "Actually, it's merely the
underlying protocol having to behave like HTTP." And both SIP and RTSP
behave much like HTTP given they both are designed with basis in HTTP.
The problem is really that HttpSession and SipSession doesn't have any
common interface, like say ServletRequest, so there is really no way to
design a good interface in the container. I admit that the patch I sent
is not that pretty. To call it a hack would more be the right term, but
since the Servlet specification doesn't define a ServletSession
interface how could it otherwise be done?
I would really like to keep baseing my servlet containers on tomcat,
since (for the most part ;-)) the interfaces are very well thought and
designed. And I would really hate to have to start from scratch and make
my very own container when a great deal of the foundation has allready
been laid by you.
> The internal Catalina API (e.g. org.apache.catalina.*) is pretty stable.
> There are no current plans to change it.
Pu eh! You had me worried there for a moment.
- Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)
Posted by Yoav Shapira <yo...@yahoo.com>.
Howdy,
I'm also not a fan of this patch. I don't think it's a particularly good idea
to modify the session interface for 4.1.x at this point.
Yoav Shapira
--- Bill Barker <wb...@wilshire.com> wrote:
>
> ----- Original Message -----
> From: "Brian Olsen" <gr...@maven-group.org>
> To: <to...@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
>
=====
Yoav Shapira
yoavs@computer.org
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Brian Olsen" <gr...@maven-group.org>
To: <to...@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