I think John's proposal is defacto a standardized version of "unbound
contexts" from Weld [1]. These are scoped to the thread in which they
are activated and destroyed upon deactivation. For @RequestScoped it
makes perfect sense (we use it internally in Weld if needed during
@PostConstruct callbacks). For @ConversationScoped and @SessionScoped it
would be more like a dummy context just to make beans working.
Actually, I find the Weld Context Management API quite nice and
powerful. But including all this stuff in the spec might be overkill.
Martin
[1]
Quick feedback:
*) 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
*) @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?
But it’s a start! Thanks for getting the ball rolling.
LieGrue,
strub
> Am 26.05.2016 um 12:42 schrieb John D. Ament <john.d.ament(a)gmail.com>:
>
> All,
>
> 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.
>
>
https://github.com/cdi-spec/cdi/pull/291
>
>
> John
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under
the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all
other ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.