<div dir="ltr">No, this is useful for both SE and EE.<div><br></div><div>The biggest problem I've run into, which requires context activation, is around multithreading in EE. Say I'm using Quartz in my app server, I need a way to start the context for that job's duration. Its outside the spec since Quartz isn't an EE technology.</div><div><br></div><div>John<br><br><div class="gmail_quote"><div dir="ltr">On Tue, May 31, 2016 at 9:48 AM Antoine Sabot-Durand <<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think this approach very interesting for built-in context support on Java SE. What bothers me is the use of this under Java EE. I don't say it wouldn't be useful, but it adds a level of complexity that may puzzle users.<div>So my point is : shouldn't we limit this feature to SE only ?</div></div><div dir="ltr"><div><br></div><div>Antoine</div></div><br><div class="gmail_quote"><div dir="ltr">Le mar. 31 mai 2016 à 15:00, Martin Kouba <<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think John's proposal is defacto a standardized version of "unbound<br>
contexts" from Weld [1]. These are scoped to the thread in which they<br>
are activated and destroyed upon deactivation. For @RequestScoped it<br>
makes perfect sense (we use it internally in Weld if needed during<br>
@PostConstruct callbacks). For @ConversationScoped and @SessionScoped it<br>
would be more like a dummy context just to make beans working.<br>
<br>
Actually, I find the Weld Context Management API quite nice and<br>
powerful. But including all this stuff in the spec might be overkill.<br>
<br>
Martin<br>
<br>
[1]<br>
<a href="http://docs.jboss.org/weld/reference/latest/en-US/html/contexts.html#_managing_the_built_in_contexts" rel="noreferrer" target="_blank">http://docs.jboss.org/weld/reference/latest/en-US/html/contexts.html#_managing_the_built_in_contexts</a><br>
<br>
Dne 31.5.2016 v 08:51 Mark Struberg napsal(a):<br>
> Quick feedback:<br>
><br>
> *) activate might be ambiguous. There is actually a ’start’ and a ‚activate on this very thread‘. Think about @SessionScoped or @ConversationScoped. Not every new thread will start a new Context. Multiple threads might re-use the very same one. Now you need a way to explicitlely say which ’Session’ (or Map) you like to attach to<br>
><br>
> *) @ActivateRequestScope et al. Interesting idea but I fear it wont work out. Let’s stick with the @SessionScoped example: _which_ Session should get created/attached for the very thread?<br>
><br>
> But it’s a start! Thanks for getting the ball rolling.<br>
><br>
> LieGrue,<br>
> strub<br>
><br>
><br>
>> Am 26.05.2016 um 12:42 schrieb John D. Ament <<a href="mailto:john.d.ament@gmail.com" target="_blank">john.d.ament@gmail.com</a>>:<br>
>><br>
>> All,<br>
>><br>
>> As mentioned during Tuesday's meeting, I'm looking for more feedback on PR #291 - the context control APIs. I think the current version is pretty snazy, and thanks especially to Martin for his input on it thus far. I'm looking for more input though, especially from the OWB team (Mark Struberg??) on whether its realistic or not.<br>
>><br>
>> <a href="https://github.com/cdi-spec/cdi/pull/291" rel="noreferrer" target="_blank">https://github.com/cdi-spec/cdi/pull/291</a><br>
>><br>
>><br>
>> John<br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br>
>> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">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>
><br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">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>
<br>
--<br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">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.</blockquote></div>
</blockquote></div></div></div>