> 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.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
