Vsevolod Golovanov I took a closer look into this and while I have to say you made your point here I am not sure I can see a realistic use for this.

Firstly, regarding the spec doc:

In the following cases, a propagated long-running conversation cannot be restored and reassociated with the request:

• When the HTTP servlet session is invalidated, all long-running conversation contexts created during the current session are destroyed, after the servlet service() method completes.
• The container is permitted to arbitrarily destroy any long-running conversation that is associated with no current Servlet request, in order to conserve resources.

This might be a bit misleading. When invoking session.invalidate I would expect all the conversations to drop and working with them after this call seems like a bit of a lottery to me. The spec states that the conversation should be destroyed after service method call while Weld does this forcibly asap. But then again, is it good idea to rely on method callback order here? By the way, regarding the latter sentence in the above quoted text - that would mean you can basically never be sure whether a long-running conversation is alive. Weld does not follow this bit either and does not destroy your conversations in such unexpected manner.

And second but all the more important - the use case. Would you be able to point me towards some realistic scenario where it would make sense to make it work literally as described in the spec? As mentioned before I cannot imagine a situation where it would be reasonable to rely on the order in which these methods get called once you invalidate the session.