7 Replies Latest reply on Jul 1, 2003 12:59 AM by Jon Barnett

    Maintaining session across wars?

    nish_dce Newbie

      Hi All,
      I am new to JBoss and I have the following problem. When I try to access one jsp which is in a "war" file,from another jsp in another "war" file,a new httpsession is started.
      Is it possible to continue with the same session and how?

      Thanks in advance,
      Newbie.

        • 1. Re: Maintaining session across wars?
          clevanger Newbie

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

          • 2. Re: Maintaining session across wars?
            nish_dce Newbie

            Thanks a lot for ur help!
            It worked that way,but I had some further problems!
            But I want to pass the whole Session Object across the wars!
            Any help would be appreciated!

            Thanks a lot,
            Newbie.

            • 3. Re: Maintaining session across wars?
              nish_dce Newbie

              One more "important" thing!
              I think there should be some configuration parameter to enable the desired behavior of maintaining sessions across multiple wars.
              Because it may be possible that even if we pass the old "sessionID" to the other jsp in other war file, that "old" session might be garbage-collected by Servlet Container,as it has started a new session!
              So we should be able to specify in some xml file ,so that Servlet Container doesn't start a new session when the request comes from a jsp in another war file.

              Any help is greatly appreciated!!

              Thanks in advance,
              Newbie.

              • 4. Re: Maintaining session across wars?
                Jon Barnett Master

                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.

                • 5. Re: Maintaining session across wars?
                  Thomas Peuss Newbie

                  > 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

                  • 6. Re: Maintaining session across wars?
                    Bruce Wilson Newbie

                    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

                    • 7. Re: Maintaining session across wars?
                      Jon Barnett Master

                      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.