tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mel Martinez <melaqu...@yahoo.com>
Subject Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SimpleSessionStore.java
Date Tue, 27 Mar 2001 15:31:20 GMT

--- cmanolache@yahoo.com 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

Mime
View raw message