Before you direct to the other war file, grab the sessionid and pass it throught the url.

Have a look at the cookie specs. They define the domain and path to which the cookie applies.

With Jetty at least, you can override both of these parameters - have a look at server/default/deploy/jbossweb-jetty.sar/webdefault.xml fro SessionPath and SessionDomain. If you look at the source for org.mortbay.jetty.servlet.ServletHttpRequest normally uses the context for the cookie path. If you override that value, you can make the cookie with the session id work across multiple WARs, as I read it.

Hope that helps.

> Have a look at the cookie specs. They define the
> domain and path to which the cookie applies.

Sorry that does not help! It is required by the specs that every deployment-unit has its own sessions.

You should think about the structure of your webapps. If you really need the session to be equal over several webapps - well maybe you should package them in one war (with subdirs).

CU
Thomas

Just my problem...I work with a team of people on a
web app that is HUGE...about 600 JSPs. I'd love to be
able to touch web.xml and have the web app redeploy,
getting my latest changes in...but it takes so long to
redeploy ! (a lot of this is due to some app-specific
initialization that occurs in some servlets, not a JBoss
problem).

I'd really like to divide this one web app into several
smaller web apps. Not only would this be a help at
development time, but it would help in packaging
parts of the overall app as separate, optional features
which could be selectively installed. But I have to have "single sign on" - once a user is logged into one app,
they're logged in to all. So saying "put everything into
one web app" isn't practical in my case -- I want to
move in the exact opposite direction !

Haven't studied it in detail, but I noticed a while back
that Tomcat 4.1 has a "single sign-on valve" (a "valve"
being like a servlet filter, as far as I can tell) that might
do what's required here; I believe it does rely on a
cookie to share the session ID across web apps.
Perhaps a look at that would help the original poster.

- Bruce

Played around with the Jetty settings for the domain cookie overrides. If I set the path, every access generates a new session ID (even if a session ID existed beforehand for the WAR context, and even if remaining in the same context).

Turning this off changes the operation so the cookie does not change when in the same WAR or returning to the WAR (cookies still different between WARs). I don't have time at the moment to really study this, but I am intrigued by these overrides, if they don't allow changing the session domain and context to extend coverage - what purpose do these settings serve?

Other servlet containers are starting to ignore the spec - the spec is anti-J2EE in the fact that it enforces a potentially large and monolithic application. WebLogic allows sessions to span WARs so the Apache thing might work.

One way to get around the problem is to build your own MBean with a repository of your information. You can index it by a hash or session ID and make sure that the session ID is somehow maintained between contexts (perhaps use a cookie for this?). Look at the pool code in the JBoss source for some pointers.

Of course, there is always the other side of the coin that says that you should build small, tight web applications and the context session management is there to ensure security constraints are maintained.

Whatever your needs, you have to decide the architecture of your application and whether the rules should be broken. There are no absolutes and you trade off this for that - as long as you know the consequences. At least with all this open-source, you can adapt things to meet your requirements.