The CDI project is part ofJakarta and uses GitHub issues as it's issue tracking system.
Therefore, all issues in CDI JIRA project are being bulk-closed as described in this GitHub issue.

If you feel like this particular issue deserves ongoing discussion, investigation or fixes in CDI/CDI TCK, please create a new issue under GitHub repository and include a link to this JIRA.

For specification related question/issues, please use - https://github.com/eclipse-ee4j/cdi/issues
For CDI TCK related questions/issues, please use - https://github.com/eclipse-ee4j/cdi-tck/issues

Yep, I think we should reject this issue because of undefined behavior and follow the session listener. On the other hand, if it's not reliable users should be very careful when using passivating scopes backed by an HttpSession.

Session invalidation != application shutdown.

I think this paragraph in the servlet spec exists because the containers are allowed to either persist the sessions and reuse them at a later restart OR to not use persistent sessions. In the later case the sessioncontexts need to get destroyed of course.

I asked myself the same question when working on this in OWB. And the conclusio (after discussing with many other people) was that we should strictly follow the Session listener. If he tells us to destroy the session then we also gonna kill this very sessioncontext. If not then nothing happens.

What is the impact of evicting the session anyway? The most important is that the @PreDestroy method on @SessionScoped beans get called. But what if the server is clustered? If a single node goes down this doesn't mean that the users session is dead. It could have been survived on a memcached (and get picked up from other nodes if required). Or there might be node-pairing and the shutdown might be part of a 'ripple-restart'. In this case the session survives as well as it got replicated to the paired node.

My conclusio of all those things was that @PreDestroy in any passivating bean is not reliable anyway. What if the cluster goes down and the new application version is not able to deserialize the bean again? What if the time spent during shut down is too long and the server doesn't even bother to reload the session from disk again (as he knows it is already timed out). Or think about @ViewScoped beans in case JSF is configured to use client-side state saving. And the user just closes his browser There are many similar cases where you cannot 100% rely on beans in passivating scopes to be cleaned up properly.

In Servlet 3.1 spec §11.3.4 Notifications At Shutdown

On application shutdown, listeners are notified in reverse order to their declarations with notifications to session listeners preceding notifications to context listeners. Session listeners must be notified of session invalidations prior to context listeners being notified of application shutdown.

Well, an HTTP session does not have to be destroyed after a container is shut down. This is not defined in the servlet spec and I did not find anything relevant in the Java EE spec. See also CDITCK-482 comments. However, if we redefine this and state that it's destroyed after an HTTP session is invalidated, we would probably break backward compatibility (see also CDI-497).