Another silly reply to my own post...
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
