tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@binarix.com>
Subject Re: SimpleSessionStore: NullPointerException
Date Wed, 11 Apr 2001 00:17:49 GMT
You were right on the money there. The SessionIdGenerator's method
sessionState never gets called... I'll have to look more closely into my
configuration.

Bojan

cmanolache@yahoo.com wrote:
> 
> Thanks Bojan,
> 
> I'll try to find the problem.
> 
> The SessionIdGenerator ( or another module that generates random ids
> ) should fill the id with random during ServerSession initialization.
> 
> session.setState( ... )  should notify all modules that a session object
> was created ( or recycled ) and needs initialization - and session id
> generator shuld set the id.
> 
> I can't reproduce the problem, and probably it would be simpler if you
> could add few println() and check if SessionIdGenerator got called and why
> is it not generating the random id.
> 
> Costin
> 
> On Wed, 11 Apr 2001, Bojan Smojver wrote:
> 
> > I went a bit further with debugging and it seems that getNewSession()
> > method in SimpleSessionManager calls 'new ServerSession()' when this
> > happens. This is all fine. The id within ServerSession is 'new
> > MessageBytes()', which is also OK. That's why session.getId() returns a
> > non-null. But when toString() is called on getId() (which is empty
> > MessageBytes), it returns null due to the fact that the type (inside
> > MessagesBytes) is initially set to T_NULL and toString() handles that by
> > returning null.
> >
> > That's the answer to the comment in SimpleSessionManager 'Why is
> > newId==null'.
> >
> > As for the fix... huh, not sure, really. I don't really understand the
> > underlying processes to be able to tell. Is session supposed to have a
> > random but valid id at this point? I'd say yes. If so, we should make
> > sure in ServerSession that when getId() is called, it returns
> > MessageBytes that are actually a string, so that toString() from it
> > returns something meaningful.
> >
> > Bojan
> >
> > Bojan Smojver wrote:
> > >
> > > I'm not sure if this is something I'm doing... Anyway, latest Tomcat 3.3
> > > from CVS gives me this:
> > >
> > > 2001-04-10 20:23:06 - JspFactoryImpl: Exception initializing page
> > > context - java.lang.NullPointerException
> > >         at java.util.Hashtable.remove(Hashtable.java:421)
> > >         at
> > > org.apache.tomcat.modules.session.SimpleSessionStore$SimpleSessionManager.removeSession(SimpleSessionStore.java:329)
> > >
> > > Basically, session remove around line 319 (don't worry about 421, I've
> > > been mucking around with it) attempts to stuff a null into
> > > sessions.remove and Hashtable goes nuts...
> > >
> > > I've changed the code of the method to this:
> > >
> > > if(session != null){
> > >   String sessionId=session.getId().toString();
> > >   if(sessionId != null)
> > >     sessions.remove(sessionId);
> > >   recycled.put(session);
> > >   session.setValid(false);
> > >   session.recycle();
> > > //      session.removeAllAttributes();
> > > }
> > >
> > > but that doesn't work either (although it avoids the null problem). The
> > > code from AccessInterceptor, class FormSecurityCheckHandler, method
> > > doService, reports 'Form login without a session' (by the way this is
> > > misspelt in the source, it says: 'From login without a session') because
> > > the session is null (actually the URL gets appended with jsessionid=null
> > > when I hit the login form).
> > >
> > > The behaviour seems to be there even if cookies are enabled.
> > >
> > > Any ideas there?
> > >
> > > Bojan
> >

Mime
View raw message