Hi Bobby,
I have a second thought on the issue.
Actually, you can workaround this by changing the "name" of the cookie
by adding <name> element under <cookie-config> in the web.xml as follows:
<session-config>
<cookie-config>
<name>MYJSESSIONID</name>
</cookie-config>
</session-config>
I have verified that it works.
Shing Wai Chan
On 4/19/12 1:27 PM, Shing Wai Chan wrote:
> Hi Bobby,
> You are correct.
> In this case, the cookies have the same domain and path.
> The port info (as mentioned in rfc 2965) is not there as it may not be
> followed by browsers.
> Hence, the cookies will overwrite each other.
> One may like to use a different browser for admingui and context root
> / app in this case.
>
> Shing Wai Chan
>
> On 4/15/12 12:28 PM, Bobby Bissett wrote:
>> Hi all,
>>
>> This is something I've seen intermittently, but never bothered to
>> track down until now. It's very simple to recreate using a new 3.1.2
>> GF installation. If I deploy an application at / and use it, then if I
>> load the admin console as well the session gets lost for my
>> application. If I start over there, then the admin console session is
>> lost. Am guessing it's just a side effect of two applications setting
>> cookies at /, but it's not a good user experience to have everyone
>> effective logged out if I need to use the admin console (not to
>> mention that the admin console is unusable with users constantly
>> logging in). Is this a bug in GF or something unavoidable if I'm
>> deploying apps to the DAS? FWIW, I don't remember this in GF 2.X.
>>
>> To recreate, use the attached app (zip has one class and pom.xml).
>> Start GF, deploy app to / and go to http://localhost:8080 in a
>> browser. Click the button a couple times to increment the counter.
>> Then load the admin console in another tab and go back to app. When
>> you click the button, you'll see an error message and have to reload
>> the page, which starts a new session and starts the counter over at 0
>> again. Then if you go back to the admin console you will have lost
>> that session too.
>>
>> I know I could work around this by running the app on a standalone
>> instance instead of the DAS, or by deploying to something other than
>> /; am just curious if there's another option instead. Should I just
>> change the context root for the __admingui app (or would that cause
>> even more trouble for me).
>>
>> Thanks,
>> Bobby
>