<div dir="ltr">Hi Mark,<div><br></div><div>think 2.3.3.4 states the opposite.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><span style="font-size:small">Romain Manni-Bucau</span><br><a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> | <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">2016-03-10 19:43 GMT+01:00 Mark Struberg <span dir="ltr"><<a href="mailto:struberg@yahoo.de" target="_blank">struberg@yahoo.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Back from JavaLand conference, so sorry for not kicking in earlier.<br>
<br>
I not quite get the argumentation chain. It’s that all triggered by async servlet requests? And isn’t the servlet spec also saying that all the request param etc may max be assigned to a single thread AT A TIME!<br>
<br>
Means that it might not be on multiple threads in parallel, but the data is allowed to get moved from one thread to another (disapearing from the first one), right?<br>
Would really need to dig into the wording of the async servlets spec again, maybe has this in the back of his head?<br>
<br>
LieGrue,<br>
strub<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>>:<br>
><br>
> Hi guys,<br>
><br>
> following request scope thread and to center the discussion on the thread safety part: do we work on this?<br>
><br>
> Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint.<br>
><br>
> Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much.<br>
><br>
> Questions:<br>
> - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app):<br>
><br>
> <beans><br>
> <scopes><br>
> <thread><br>
> <active>JMS</active><br>
> <active>ASYNCHONOUS</active><br>
> </thread><br>
> </scopes><br>
> </beans><br>
><br>
> - start/stop API (this is typically an API the user should be able to control for its own threads)<br>
> - CDI 2.*0*?<br>
><br>
> wdyt?<br>
><br>
> Romain Manni-Bucau<br>
> @rmannibucau | Blog | Github | LinkedIn | Tomitriber<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
<br>
</div></div></blockquote></div><br></div>