--- [EMAIL PROTECTED] wrote:
> > However, this does point to the need for default
> > behavior of tomcat session generation code (or any
> > interceptor or module code) in the absence of
> expected
> > configuration info in server.xml.
>
> That's a good point, but I'm wondering how could it
> be implemented.
> The whole idea of modules is that each can be
> replaced with a better
> version ( for example a more secure or more
> efficient scheme to generate
> the ids ), so we can't just check for specific
> modules.
>
> Well, there is a solution ( I'm not sure how can we
> code it ) - have an
> automated way to run watchdog and sanity to validate
> the config files. If
> watchdog/sanity are passing - then probably the
> config is valid :-)
>
I'm not sure exactly the best way to do it here, since
I have not had the time to follow all the code
involved with session management. However, I do know
that request.getSession() is a fundamental method of
the API that should NOT crash just because the
deployer has not specified a configuration option.
The implementation of a specification should ALWAYS
supply a default behavior that either works gracefully
with default options OR fails gracefully while
informing the deployment engineer or developer about
the missing/incorrect configuration settings.
If SimpleSessionManager/ServletSession can not work
with a 'null' value for the Session ID, then it needs
to fail gracefully or it needs to supply a default id
generator.
Mel
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/?.refer=text
