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
[EMAIL PROTECTED] 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
> >
