Resteasy can be configured to destroy the websession right after the request (default behaviour). In few circumstances the session can't be destroyed anymore. Example is if using basic authentication you can access the previous authenticated session even if giving wrong credentials in request. This can end up in serious security issues.

Take in account that destroying the session is not placed in finally block.

Scenario:1. You miss giving the credentials on first service call. AuthenticationFilter throws an exception. From this point, the session.isNew() will always return false but the code in ResteasyResourceAdapter to destroy the session was never reached. Looking at the condition if destroying the session shows, the session will never be destroyed due to the NOT NEW session.

2. Authentication succeeded or even no authentication required. The service throws an exception and the code to invalidate the session is skipped. From now on the old story: the session is not new anymore, never entering the responsible code block.

Personal intepretation:If resteasy is configured to destroy the session, the session should be invalidated in any case, coming to following code and workaround:

override the Adapter by your own implementation. Unfortunately you have to mention: @Install(precedence = Install.DEPLOYMENT) due the default implementation is already Install.APPLICATION and not Install.FRAMEWORK

2.2.1 CR2 was fine. In 2.2.1 Final if you browse to a page which makes a request to resteasy after loading (in my case for a chart) the session is destroyed. If the user submits any forms on that page they will then get an exception because the view has expired. If they browse anywhere else they will find they have also been logged out.

Adding:

<resteasy:application destroy-session-after-request="false"/>

isn't an option because then all rest requests will cause sessions to be created.

Is there a problem with the code that detects whether there is an existing session?

David, you are right. Using resteasy with authenticated user will not work. In the ResourceAdapter it is essential to test on session.isNew(). Inside the try finally block it will at least work for exceptions thrown by the resteasy service itself. But there is one problem left: session.isNew() will not work if resteasy service is authentication restricted and there are no or wrong credentials on first call. This means the ResteasyResourceAdapter will never be invoked to be able to destroy the session. So there must be another way to know if session must be destroyed directly on first failing call. This might be a flag in session scope who the session created, probabely if resteasy with destroy-session was the creator.There should be a third option for destroy-session-after-request : always, never, ifCreated .