[EMAIL PROTECTED] wrote:
> 
> > I started to look at this one, and noticed that there are two interceptors
> > that deal with sessions:
> > * SessionInterceptor, seems to deal with session IDs in the URL but
> >   doesn't care about cookies. This one is invoked first.
> > * StandardSessionInterceptor, seems to deal with session IDs received
> >   as cookies but doesn't care about session IDs in the URL.
> >
> > Before I start hacking here, can someone tell me why there are two
> > interceptors and what the intention with the two are?
> 
> The intention was to separate the module that extract the session id from
> a request from the module that provides the storage of session data.
> 
> StandardSessionInterceptor was the original module, resulted from
> refactoring of session-related code.
> 
> AFAIK ( or at least the intention was ) that StandardSessionInterceptor
> shouldn't deal in any way with finding the session id - it'll just store,
> find and create HttpSession and session attributes.
> 
> The SessionInterceptor is ( possibly one of the ) modules that extract the
> session ID - it should be possible to add a SSLSessionIdInterceptor that
> implements SSL-based sessions, etc.
> 
> The names are really bad - I know. StandardSessionInterceptor should be
> called "SimpleSessionStorageInterceptor" and the other one
> "StandardSessionIdInterceptor". I guess it's too late to change it.
> 
> For 3.3 we can spend more time improving the interceptors.

Okay, thanks for the info. I have found a fix to the problem that I'll
post for review to the list in a second. If no one objects before tonight
I'm going to commit it to the tomcat_32 branch.

Hans
-- 
Hans Bergsten           [EMAIL PROTECTED]
Gefion Software         http://www.gefionsoftware.com

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

Reply via email to