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
>
