<div dir="ltr">If you pass an AsyncContext to a random other thread (which is not necessarily container managed), then the fact that code in this other thread gets hold of this context, doesn&#39;t set up the TLS stuff needed for @RequestScoped etc, does it?<div><br></div><div>If so, how would this technically work?<br><div><br></div><div>This is different from container managed threads which get work submitted to it (like Concurrency spec executor service and @Asynchronous). They have an opportunity to set up and tear down the contexts before and after working on the unit respectively.</div><div><br></div><div>For the AsyncContext case, what about something like the following in the thread that in whatever way gets hold of the AsyncContext</div><div><br></div><div>beanmanager.initScope(RequestScoped.class, request);<br></div><div><br></div><div>or with a guard:</div><div><br></div><div>beanmanager.initScopeIfNotActive(RequestScoped.class, request);<br></div><div><br></div><div>Would that work?</div><div><br></div><div><br></div><div><br></div><div><div id=":306.ma" class="" title="3/20/16, 10:09 PM" style="font-size:13px;line-height:16px;margin-bottom:6px;margin-left:9px;margin-right:9px;word-wrap:break-word;color:rgb(38,50,56)"><br></div><div id=":30h.ma" class="" style="font-size:13px;line-height:16px;margin-bottom:6px;margin-left:9px;margin-right:9px;word-wrap:break-word;color:rgb(38,50,56)"><div id=":30h.at" class="" style="text-align:center"></div><br></div></div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 20, 2016 at 9:51 PM, Mark Struberg <span dir="ltr">&lt;<a href="mailto:struberg@yahoo.de" target="_blank">struberg@yahoo.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think the current spec wording already defines what happens in that case. At least there are TCK tests for it.<br>
<br>
LieGrue,<br>
strub<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
On Sunday, 20 March 2016, 21:37, arjan tijms &lt;<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;On Sun, Mar 20, 2016 at 6:36 PM, Manfred Riem &lt;<a href="mailto:mnriem@gmail.com">mnriem@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;Why is changing @RequestScoped out of the question?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;From my perspective when an AsyncContext is started the request is still there.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;It is just being served by a different thread.<br>
&gt;<br>
&gt;<br>
&gt;With just AsyncContext the original request thread can end and a new thread can write to the response. Both of them can access the request object after the AsyncContext has been handed to the second thread. But the second thread is not necessarily &quot;connected&quot; to anything, is it? It&#39;s just any random thread that gets the AsyncContext object passed in.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;Would it work here if there was a public CDI API available to activate the request scope (and session scope possibly) from a given instance of ServletRequest?<br>
&gt;<br>
&gt;<br>
&gt;Regardless, this is a slightly different problem from when a given request thread submits work to a Concurrency spec executor.<br>
&gt;<br>
&gt;<br>
&gt;Kind regards,<br>
&gt;Arjan Tijms<br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div>