Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)

2003-06-30 Thread Brian Olsen
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)

2003-06-30 Thread Bill Barker

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



Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)

2003-06-30 Thread Yoav Shapira
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 [EMAIL PROTECTED] wrote:
 
 - 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]
 


=
Yoav Shapira
[EMAIL PROTECTED]

__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)

2003-06-30 Thread Remy Maucherat
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)

2003-06-30 Thread Brian Olsen
Bill Barker wrote:
- 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 ;-).
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)

2003-06-30 Thread Brian Olsen
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)

2003-06-30 Thread Remy Maucherat
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]