[ https://issues.jboss.org/browse/WFLY-12815?page=com.atlassian.jira.plugin... ] Matěj Novotný edited comment on WFLY-12815 at 11/27/19 10:00 AM: ----------------------------------------------------------------- Quickly reading this issue (going to read it some more for sure), I'd like to comment on your second point. {quote}(2) Program in your WAR application a sessionDestroyed listener that will be broken. In our case whenever the session is timing out, we have some code that explodes in wildfly and not in weblogic because it expected for the RequestScope context to be active, but apparently in wildfly when Undertow to start killing of a session the request scope context is not made active so that caused our session destroyed handling to break{quote} CDI spec is not clear on the order in which these are destroyed, or more precisely on whether you can rely on certain scope being active during destruction of another scope. Weld (at least in WildFly) tries to destroy scopes with "shorter life span" first meaning request scope gets destroyed before session scope which in turn goes before application scope (if you are shutting down app). Hence the behavior you see; it's actually inteded. I am not sure if weblogic added some manual scope activation, but to me it seems logical the way I described it above so that req. context cannot "outlive" session context. Since you already played with this quite a lot, do you happen to have a reproducer project to share? I also find it weird that there are two session contexts active because the way {{HttpSessionDestructionContext}} gets activated is visible [here|https://github.com/weld/core/blob/master/modules/web/src/main/java/o...]. It should only happen in case there is no session context already. Also take a glance at the javadoc of this class which explains how and why its done. The actual on/off toggling of http contexts is done via [WeldInitialListener|https://github.com/weld/core/blob/master/modules/web/...] which delegates most logic to [HttpContextLifecycle|https://github.com/weld/core/blob/master/modules/web/src/main/java/org/jboss/weld/module/web/servlet/HttpContextLifecycle.java]. Now, if I understood the problem, then the situation will only happen if you deliberately try and "corrupt" all the threads by using inactive scopes on them and them you try and start new session on one of those threads. That's pretty fishy code in the first place, but we should still look into why this happens. If you have the reproducer, then [this is where {{HttpSessionDestructionContext}} gets destroyed|https://github.com/weld/core/blob/master/modules/web/src/main/j...]. The possible issue could be the ordering of {{WeldInitialListener}} and {{WeldTerminalListener}} - basically you need {{WeldTerminalListener}} to be the last registered and hence first invoked; this will get you the special context activated. Then, after some other optional listeners, comes {{WeldInitialListener}} (registered first, called last) that will attempt to terminate this special context. At least that's how I understand it from a glance into the code, if you toss me a reproducer, I'll try and go deeper. Meanwhile, I'll try to dig up where WFLY registers those listeners. EDIT: In WFLY, those listeners are register in [{{WebIntegrationProcessor}}|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/WebIntegrationProcessor.java] and that seems to be done in correct way. was (Author: manovotn): Quickly reading this issue (going to read it some more for sure), I'd like to comment on your second point. {quote}(2) Program in your WAR application a sessionDestroyed listener that will be broken. In our case whenever the session is timing out, we have some code that explodes in wildfly and not in weblogic because it expected for the RequestScope context to be active, but apparently in wildfly when Undertow to start killing of a session the request scope context is not made active so that caused our session destroyed handling to break{quote} CDI spec is not clear on the order in which these are destroyed, or more precisely on whether you can rely on certain scope being active during destruction of another scope. Weld (at least in WildFly) tries to destroy scopes with "shorter life span" first meaning request scope gets destroyed before session scope which in turn goes before application scope (if you are shutting down app). Hence the behavior you see; it's actually inteded. I am not sure if weblogic added some manual scope activation, but to me it seems logical the way I described it above so that req. context cannot "outlive" session context. Since you already played with this quite a lot, do you happen to have a reproducer project to share? I also find it weird that there are two session contexts active because the way {{HttpSessionDestructionContext}} gets activated is visible [here|https://github.com/weld/core/blob/master/modules/web/src/main/java/o...]. It should only happen in case there is no session context already. Also take a glance at the javadoc of this class which explains how and why its done. The actual on/off toggling of http contexts is done via [WeldInitialListener|https://github.com/weld/core/blob/master/modules/web/...] which delegates most logic to [HttpContextLifecycle|https://github.com/weld/core/blob/master/modules/web/src/main/java/org/jboss/weld/module/web/servlet/HttpContextLifecycle.java]. Now, if I understood the problem, then the situation will only happen if you deliberately try and "corrupt" all the threads by using inactive scopes on them and them you try and start new session on one of those threads. That's pretty fishy code in the first place, but we should still look into why this happens. If you have the reproducer, then [this is where {{HttpSessionDestructionContext}} gets destroyed|https://github.com/weld/core/blob/master/modules/web/src/main/j...]. The possible issue could be the ordering of {{WeldInitialListener}} and {{WeldTerminalListener}} - basically you need {{WeldTerminalListener}} to be the last registered and hence first invoked; this will get you the special context activated. Then, after some other optional listeners, comes {{WeldInitialListener}} (registered first, called last) that will attempt to terminate this special context. At least that's how I understand it from a glance into the code, if you toss me a reproducer, I'll try and go deeper. Meanwhile, I'll try to dig up where WFLY registers those listeners. -- This message was sent by Atlassian Jira (v7.13.8#713008)