<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this?</div><div><br>On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>> wroteshar:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hi guys,<div><br></div><div>spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is.</div><div><br></div><div>Sample:</div><div>In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally.</div><div><br></div><div>Bonus:</div><div>One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat.</div><div><br></div><div>Question:</div><div>Would CDI handle it in 2.0?</div><div><br></div><div>Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now.</div><div><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>
</div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>cdi-dev mailing list</span><br><span><a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a></span><br><span></span><br><span>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">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.</span></div></blockquote></body></html>