Thanks Mel,
I had a brief look at the server.xml file and the SessionIdGenerator is
there. Actually I just copied the new jars over from the build (maybe
that screwed me up after all :-)
Does the order matter? I diffed my file against the file that comes with
Tomcat 3.3 CVS and there are no significant differences. The
SessionIdGenerator doesn't appear as an interceptor in the log files...
The line in server.xml is:
<SessionIdGenerator randomClass="java.security.SecureRandom" />
Could it be that the SessionIdGenerator class from util is found first
and since it doesn't extend BaseInterceptor it never gets loaded?
Bojan
Mel Martinez wrote:
>
> Bojan,
>
> This sounds like the same error I ran into a couple of
> weeks ago. Do you have SessionIdGenerator enabled in
> your server.xml file? Unfortunately, if you don't the
> default behavior is to barf because it (the sid
> generator) never gets started and so the first time a
> jsp page or servlet tries to getSession(), a null
> pointer exception occurs. We need to figure out some
> way to have a default sid generator get instantiated
> in the absence of an explicit server.xml entry (or at
> least a decent error message).
>
> Mel
> --- Bojan Smojver <[EMAIL PROTECTED]> 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
>
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
