hi folks! I'm not really happy with the RequestContextController. And it appears to me that the spec is broken.
Here is the important part from the spec: 6.5.2. Activating Built In Contexts Certain built in contexts support the ability to be activated and deactivated. This allows developers to control built-in contexts in ways that they could also manage custom built contexts. When activating and deactivating built in contexts, it is important to realize that they can only be activated if not already active within a given thread. 6.5.2.1. Activating a Request Context Request contexts can be managed either programmatically or via interceptor. To programmatically manage request contexts, the container provides a built in bean that is @Dependent scoped and of type RequestContextController that allows you to activate and deactivate a request context on the current thread. The object should be considered stateful, invoking the same instance on different threads may not work properly, non-portable behavior may occur. public interface RequestContextController { boolean activate(); void deactivate() throws ContextNotActiveException; } When the activate() method is called, if the request context is not already active on the current thread then it will be activated and the method returns true. Otherwise, the method returns false. When the deactivate() method is called, if this controller started the request context then the request context is stopped. The method does nothing if this controller did not activate the context The problem is that there are 2 ways to use that part a.) boolean didActivate = reqCtxCtrl.activate(); ... if (didActivate) reqCtxCrl.deactivate(); b.) try { reqCtxCtrl.activate(); ... } finally { reqCtxCrl.deactivate(); } The problematic part is nesting. In case a) we got maybe 7 calls to activate() but only 1 to deactivate. In case b) we got 7 calls to activate and 7 to deactivate(); There is simply no way to implement this in a clean way. My original impl was of course wrong. The ThreadLocal<List> does not help much either. If we use a ThreadLocal<Boolean> we potentially leak memory in case of a). If we close immediately we potentially close way too early in case b). Wdyt? Gonna open a ticket in the spec. LieGrue, strub