Just to put this one to bed,
I never did get to the bottom of what was causing this (although my #1
suspect is
the Acegi Security framework Roller uses). Since there's so little in
the Roller
session anyway (and HA was already flakiy thanks to multicast being unreliable
on the network the cluster lives on), I just decided to deploy without
--availiabilityenabled.
That way, Glassfish no longer sends a JSESSIONIDVERSION, and the
problem goes away :)
On Wed, Nov 5, 2008 at 9:41 PM, Dick Davies <rasputnik_at_hellooperator.net> wrote:
> Hi Jan, thanks for the response. See replies inline:
>
> On Wed, Nov 5, 2008 at 12:09 AM, Jan Luehe <Jan.Luehe_at_sun.com> wrote:
>
>> On 11/ 4/08 02:04 PM, Dick Davies wrote:
>
>> So to clarify, this is something Glassfish (the appserver) is managing,
>> rather than Roller (the webapp), am I right?
>>
>> Correct. Both the JSESSIONID and JSESSIONIDVERSION cookies
>> are container-managed.
>
>> Once I've logged in, Safari has 2 cookies
>>
>> JSESSIONID = <the session id>, path = /
>> JSESSIONIDVERSION cookie , path = / , contents = /:43
>>
>> as i click around the webapp, the contents increments: /:44 , /:45 , etc.
>> and the path remains as /.
>
>> From your cookies, it seems that you've deployed Roller at the root context,
>> i.e., "/". Can you please confirm?
>
> That's right, yes.
>
>> But logging in with Firefox 3
>
>> JSESSIONID = <the session id>, path = / , (only send for encrypted
>> connections)
>> JSESSIONIDVERSION cookie , path = / , contents = /:1
>> JSESSIONIDVERSION cookie , path = /default/resource/images/ , contents = /:2
>> JSESSIONIDVERSION cookie , path = /roller-ui/, contents = /:1
>> JSESSIONIDVERSION cookie , path = /roller-ui/styles/ , contents = /:4
>> JSESSIONIDVERSION cookie , path = /roller-ui/theme/tan/ , contents = /:5
>
>> What I don't understand is that you seem to be getting different cookies
>> depending on what browser you are using. As mentioned above, the cookies
>> in question are created and managed by the container, so they should not be
>> affected by the browser in use.
>
> I think the same headers are being sent to both browsers, they are
> just interpreting
> them differently.
>
>> The container uses the webapp's context root as the cookie path, so I'm not
>> sure I understand how you could end up with a cookie path equal to
>> "/default/resource/images/" or "/roller-ui/theme/tan/". It looks like
>> Firefox 3 is
>> somehow manipulating your cookie paths, but I don't see how.
>
> I need to look into this in more detail. It may be just a quirk of the way
> Firefoxes (2 and 3) store/display their cookies and not the cause of
> my problem at all.
>
> It'd be good if someone could log into another roller/glassfish
> installation with Firefox
> and see what their cookies look like.
>
> if anyone could log into blogs.sun.com and mail me the output maybe?
> Or just a 'I get N JSESSIONIDVERSION cookies'?
>
>
>> What you show as "contents" of the JSESSIONIDVERSION cookies
>> is a concatenation of context-root and session-version pairings (in your
>> case, there is only one such pair per cookie). ... version
>> info for each of these sessions must be maintained as a separate
>> context-root/session-version pairing.
>
>> In this case, the cookie path would be configured to be equal to "/", so
>> that each session may be resumed independently, and the context-root in each
>> of the pairings will show the associated context's context root.
>>
>> Give the above, I'm not sure how you could end up with a cookie of this
>> form:
>>
>> JSESSIONIDVERSION cookie , path = /roller-ui/, contents = /:1
>
> Nor me - it seems that the path= part may be inserted by Firefox,
> which just makes
> it up from the request URL.
>
> A simple action like logging in and clicking a few links produces a
> silly amount of
> LiveHTTPHeaders output, so I could be wrong....
>
>> You may have already mentioned this earlier, but what version of GlassFish
>> are you using?
>
> Headers (which I'll be seeing in my dreams tonight I expect) say:
>
> X-Powered-By: Servlet/2.5
> Server: Sun Java System Application Server 9.1_02
>
> Thanks again.
>