As Johan already pointed (or almost pointed ) out.
check the domain & path of the JSESSIONID cookie .
If those are different then that's why you get 2 of them.
Evgeny

On Wed, Dec 23, 2009 at 10:52 AM, Johan Thorselius <
johan.thorsel...@gmail.com> wrote:

> Hi Ron,
>
> Actually, there is an Apache in front of Tomcat when on Linux (sorry about
> that vital detail), can that create the problem ?
>
> I will check the configuration of Apache with other staff, can't be before
> x-mas.
>
> Thanks - Johan
>
>
> 2009/12/23 Ron McNulty <rmcnu...@xtra.co.nz>
>
> > Hi Johan
> >
> > Two JSESSIONID values does look odd. I've seen problems like this when
> > another server running a Java J2EE servlet container incorrectly had its
> > JSESSIONID cookie scope set to the whole domain, rather than scoped to
> the
> > server and application. In my case it was a SAP web server, and the
> session
> > ID value was readily recognisable, and quite different to Tomcat values.
> >
> > That may also explain the Linux/Windows difference if your development
> > boxes are on Windows and the production/test boxes are on Linux.
> >
> > Regards
> >
> > Ron
> >
> > ----- Original Message ----- From: "Johan Thorselius" <
> > johan.thorsel...@gmail.com>
> > To: "Tomcat Users List" <users@tomcat.apache.org>
> > Sent: Tuesday, December 22, 2009 11:38 PM
> > Subject: Re: Http session lost b/w struts actions on Linux but not in Win
> >
> >
> >
> >  I here add some info from Firebug which may be significant.
> >>
> >> 'GET localhost:8080/wap-app/start.action':
> >>
> >> CookieJSESSIONID=9726CDF4A527E3D98451140AB69EFA2C;
> >> JSESSIONID=BEED739340DDD4370C85A9D12917692A
> >>
> >> 'GET localhost:8080/webdav/images/.../1px.gif':
> >>
> >> Cookie    JSESSIONID=BEED739340DDD4370C85A9D12917692A
> >>
> >> Johan
> >>
> >>
> >>
> >> 2009/12/22 Johan Thorselius <johan.thorsel...@gmail.com>
> >>
> >>  The issue now boils down to the following a bit strange thing. Any idea
> >>> why
> >>> this happens ?
> >>>
> >>>
> >>> - request.getSession() returns an incorrect null on Linux, but on
> Windows
> >>> it's OK - under the following circumstances:
> >>>
> >>> When using Firebug on Firefox I noted that a corporate common .css
> >>> references a 1-pixel gif which is not present and visible, hence there
> is
> >>> a
> >>> '404 Not found' error for the 'GET
> >>> localhost:8080/webdav/images/.../1px.gif'. But the preceding 'GET
> >>> localhost:8080/wap-app/start.action' is fine.
> >>>
> >>> In my myValve-class on Linux:
> >>>
> >>> 'GET localhost:8080/wap-app/start.action' => myValve.invoke() ...
> >>> request.getSession() returns a correct session object
> >>>
> >>> 'GET localhost:8080/webdav/images/.../1px.gif' => myValve.invoke() ...
> >>> request.getSession() and request.getSession(true) both returns null
> >>>
> >>> Same code and same build, in my myValve-class on Windows:
> >>>
> >>> Both GET => myValve.invoke() ... request.getSession() returns a correct
> >>> session object
> >>>
> >>>
> >>> The webapp is built with Struts2/Spring.
> >>>
> >>> Both Linux and Windows uses Tomcat 6.0.20.
> >>>
> >>>
> >>> On Windows Java version 1.6.0_16 is used
> >>>
> >>> On RedHat Linux Java version 1.6.0_13 is used
> >>>
> >>> and..
> >>>
> >>>
> >>> >> In the "log incorrect event" code, do you return
> >>> >> from the valve, or do you continue processing?
> >>>
> >>> The execution continues down to the bottom with
> >>> 'getNext().invoke(req,resp)'
> >>>
> >>> Johan
> >>>
> >>>
> >>> 2009/12/17 Christopher Schultz <ch...@christopherschultz.net>
> >>>
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>
> >>>> Hash: SHA1
> >>>>
> >>>> Johan,
> >>>>
> >>>> On 12/17/2009 7:52 AM, Johan Thorselius wrote:
> >>>> > request.getSession() returns an incorrect null on Linux, but on >
> >>>> Windows
> >>>> it's
> >>>> > OK.
> >>>>
> >>>> That's odd... request.getSession() should never return null. This
> >>>> method:
> >>>>
> >>>> "
> >>>> Returns the current session associated with this request, or if the
> >>>> request does not have a session, creates one.
> >>>> "
> >>>>
> >>>> > I have an ordinary Struts2 web app deployed on Tomcat 6.0.20,
> together
> >>>> with
> >>>> > a JAAS-solution where I have my own Valve class.
> >>>> >
> >>>> > The Valve repeatedly executes invoke() with the following
> code-snippet
> >>>> (here
> >>>> > very much simplified):
> >>>> >   .
> >>>> >   .
> >>>> >   .
> >>>> >   if (LOGGER.isDebugEnabled()) {
> >>>> >     if (request.getSession() == null) {
> >>>> >       // Log incorrect event (1)
> >>>> >     } else {
> >>>> >       // Log OK (2)
> >>>> >     }
> >>>> >     if (request.getSession(true) == null) {
> >>>> >       // Log incorrect event (3)
> >>>> >     } else {
> >>>> >       // Log OK (4)
> >>>> >     }
> >>>> >   }
> >>>> >
> >>>> >   /*
> >>>> >    * Here a NullPointerException occurs
> >>>> >    */
> >>>> >   request.getSession().setAttribute("...",...);
> >>>>
> >>>> In the "log incorrect event" code, do you return from the valve, or do
> >>>> you continue processing?
> >>>>
> >>>> > In the first request the session is not lost, everything is fine
> with
> >>>> (2)
> >>>> > and (4). In the following requests getSession() returns null (1) and
> >>>> (3).
> >>>>
> >>>> Are you storing the request object anywhere and perhaps using it after
> >>>> it's been recycled?
> >>>>
> >>>> - -chris
> >>>> -----BEGIN PGP SIGNATURE-----
> >>>> Version: GnuPG v1.4.10 (MingW32)
> >>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >>>>
> >>>> iEYEARECAAYFAksqoSoACgkQ9CaO5/Lv0PDZ7QCfXwdUPAoU9EPxlEC64f11rlAa
> >>>> +0oAoJG3hjVFYbeCvkrXQ14bkvlq9bJZ
> >>>> =lF2t
> >>>> -----END PGP SIGNATURE-----
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >>>> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>

Reply via email to