On Fri, 11 May 2001, Antony Bowesman wrote:
> Hi,
>
> Is it correct behaviour for Tomcat to create a different session when a
> call is made to request.getSession(true) if the context is different.
>
Yes. That's required by the servlet spec. It also makes sense when you
think about the class loading aspect: each web application has its own
class loader that provides access (for that app) to the contents of
WEB-INF/classes and WEB-INF/lib. If you create a session attribute based
on one of these classes, that class itself cannot be loaded from any other
web app.
> I ask because I have a realm implementation that caches stuff in session
> relating to authentication. I have two contexts in server.xml and each
> context defines its own JAAS authentication parameters in web.xml. My
> realm can then determine if a user is authenticated in a particular
> context. To do this I am using session in the realm and noticed that
> each context has a different session.
>
You might want to look at how Tomcat 4.0 addresses the "single sign
on" feature of the servlet spec, which requires user authentication to be
global across the web apps in a virtual host (even though the
sessions are unique). It's done by maintaining a separate cookie, and a
separate collection of available "authentications", that intervenes before
the usual per-web-app authentication takes place. The class you want to
look at is org.apache.catalina.authenticator.SingleSignOn -- plus you will
want to examine the other classes in the same package to see how the
interactions work.
> Can someone please explain how Tomcat determines if a session should be
> created when getSession(true) is called.
>
As above, sessions are required to be per-webapp. You'll need to use some
different mechanism to cache stuff across webapps.
> Rgds
> Antony
> --
> Antony Bowesman
> Teamware Group
> [EMAIL PROTECTED]
> tel: +358 9 5128 2562
> fax: +358 9 5128 2705
>
Craig McClanahan
