On Thu, May 29, 2014 at 6:16 PM, David Rees wrote:
> I'll open a ticket with these details, too.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56578
-Dave
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For a
On Thu, May 29, 2014 at 12:39 PM, David Rees wrote:
>
> Yes. Specifics to make this happen seem to be:
>
> TC 7.0.54 in a cluster, Tapestry 5.2.6 + Tapestry Spring Security.
OK, I was wrong, no Tapestry or Spring Security is required, just a
couple JSPs are required to reproduce. Key is that clus
On Thu, May 29, 2014 at 12:16 PM, Christopher Schultz
wrote:
> Do you mean that you have a web application that does this:
>
> session.invalidate();
> session = request.getSession(true);
>
> ... and the old session is in fact not invalidated?
Yes. Specifics to make this happen seem to be:
TC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
On 5/29/14, 3:12 PM, David Rees wrote:
> On Thu, May 29, 2014 at 8:51 AM, Konstantin Kolinko
> wrote:
>> 2014-05-29 11:58 GMT+04:00 David Rees :
>>> I've found that certain applications will no longer invalidate
>>> sessions after upgradin
On Thu, May 29, 2014 at 8:51 AM, Konstantin Kolinko
wrote:
> 2014-05-29 11:58 GMT+04:00 David Rees :
>> I've found that certain applications will no longer invalidate
>> sessions after upgrading from 7.0.53 to 7.0.54.
>>
>> It seems to require clustering to be set up in Tomcat. If it's not set
>>
2014-05-29 11:58 GMT+04:00 David Rees :
> I've found that certain applications will no longer invalidate
> sessions after upgrading from 7.0.53 to 7.0.54.
>
> It seems to require clustering to be set up in Tomcat. If it's not set
> up, session invalidation works fine.
>
> So far, I can only trigger
