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
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 it in a webapp that uses Tapestry Spring Security.
