Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SimpleSessionStore.java
--- [EMAIL PROTECTED] wrote: > > Temporary(?) fix to stop crashes when creating a > new Session in > > embedded use of Jasper (i.e. as standalone > JspServlet ). Problem may > > occur in other situations as well, I'm not sure. > > > I looked at that and I couldn't reproduce it - are > you sure you have the > right configuration ( i.e. SessionIdGenerator > included in server.xml ) ? > No, SessionIdGenerator was not included, I have a customized server.xml because I need to test both jasper with tomcat and then jasper in weblogic (as well as other reasons). I'll update my server.xml and I predict that will fix the problem. I now see that server.xml was beeing updated in my cvs logs, but failed to account for the change in my own version. 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. Mel > getNewSession is calling setState( STATE_NEW ), that > calls the > sessionState callback that allows modules to > initialize the new session > object - and SessionIdGenerator is setting the id ( > using whatever > random). > > I can't understand what's wrong - my only guess is > that SessionIdGenerator > is not included. > > I didn't had too much time this weekend ( to restart > the nightly tests ), > but I hope to resolve those issues soon. > > Costin > > > > > object, the .toString() method to get a string > representation of the > > session id returns null. When getNewSession() > tries to use this value > > as a key into the sessions hashtable, a > NullPointerException is thrown. > > > > > __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SimpleSessionStore.java
--- [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
