I think it should be enough to change the javadoc. The method returns
true when the session was invalidated *during the current request*.
Without a request there is no way of telling whether the session is
invalidated or not. IMHO throwing an exception is fine, but this
behavior should be documented. If a default must be chosen, I'd opt
for false not true. Without a request there is no way the session can
be marked for invalidation, so it should not return true.

Best regards,
Emond

On Tue, Apr 3, 2018 at 5:42 PM, Martin Grigorov <mgrigo...@apache.org> wrote:
> On Tue, Apr 3, 2018 at 4:17 PM, Rakesh A <iamrakes...@rediffmail.com> wrote:
>
>> Actually, we've bit more complex scenario I should say; we've multiple
>> webapps running on tomcat with SSO valve configured; which means logout on
>> one application kills the session on other applications and we've session
>> implementation class with logout & session invalidation handling.
>> In both cases logout/invalidate, we try to do some cleanup (at a high level
>> both call one method), which has this check 'isSessionInvalidated()' before
>> proceeding with cleanup.
>>
>
> You didn't answer my question (or I didn't understand your answer).
> Why do you need to use "isSessionInvalidated()" in your cleanup method ?
> Is the cleanup method called in some other cases ? If it is just called by
> logout/onInvalidate then there is no need to check "isSessionInvalidated()".
>
> But I agree that isSessionInvalidated should be improved to return true if
> there is no RequestCycle. If there is no RequestCycle then there is no
> Request, so there is no Session. But then the name would be confusing - one
> cannot be sure whether there was no session on first place or it has been
> invalidated.
> In any case this method is public and there is nothing saying that it is an
> internal API, so there should not be any assumptions.
>
>
>>
>> Regards,
>> Rakesh.A
>>
>> --
>> Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-
>> f1842947.html
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to