[weld-dev] BeanManagerImpl permits multiple Contexts per scope type: why?

[Martin Kouba]

Dne 02. 11. 18 v 22:07 Laird Nelson napsal(a):
> On Fri, Nov 2, 2018 at 1:25 AM Martin Kouba <mkouba at redhat.com 
> <mailto:mkouba at redhat.com>> wrote:
> 
>     The spec is very clear that this should be possible. See for example
>     6.5.1. The active context object for a scope:
>     "The container must search for an active instance of Context associated
>     with the scope type."
> 
> 
> Not so sure about the "very clear" part :-) but yes, you can read it 
> this way and clearly that's the intent so that's good enough for me!
> 
> Follow-up question: a Context's "activeness" is defined per-thread 
> (section 6.2 <http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#context>):
> 
> "At a particular point in the execution of the program a context object 
> may be active with respect to the current thread."
> 
> So when I ask the BeanManager for the (singular) 
> Context-that-is-active-with-respect-to-the-current-thread by giving it a 
> scope annotation, I get back a Context whose isActive() method returned 
> true at some point during the implementation of the 
> BeanManager#getContext(Class) method 
> <http://docs.jboss.org/cdi/api/2.0/javax/enterprise/inject/spi/BeanManager.html#getContext-java.lang.Class->.  
> And certainly I'd hope that once I receive this Context its isActive() 
> method would return true.
> 
> But this is just a "best effort" area of the specification, right?

Yes. It cannot be guaranteed, ie. it always depends on the context 
implementation.

> 
> Consider a (hypothetical, thought-experiment) stupid Context that tracks 
> whether it's active or not for a given Thread (using a Map of 
> Threads-to-booleans or something similar).  Then pretend solely for 
> discussion purposes that it has a daemon Thread in it that randomly and 
> periodically sets its activeness to true or false for a given Thread.  
> So sometimes a caller of its isActive() method gets true back, and 
> sometimes it gets false based on the random activeness-toggling actions 
> of the internal daemon thread.  Again, this is a thought experiment, not 
> proposed or useful code.  :-)
> 
> All the BeanManager can do in this (stupid but legal?) case is make a 
> /best effort/: at the time it selects the Context for returning from its 
> getContext(Class) method, the Context must have returned true from its 
> isActive() method (otherwise it would not be a candidate for returning), 
> but the caller of BeanManager#getContext(Class) receiving this stupid 
> Context may invoke isActive() and discover that suddenly it is returning 
> false because of the actions of its stupid embedded daemon thread.  Is 
> this thought-experiment scenario correct and permitted by the laws of 
> the specification?
> 
> Another way to ask this: is the following statement true or false?  I 
> believe it is true:
> 
>      There is no requirement that the activeness of a BeanManager-vended 
> Context be immutable with respect to the calling thread.

True. The state of the context can change at any time.

> 
> (It seems this statement must be true or the fact that a Context can 
> throw ContextNotActiveException from its methods would seemingly make no 
> sense.)
> 
> I'm just trying to understand this area very deeply, particularly with 
> respect to threading.  Thanks as always for your time.
> 
> Best,
> Laird

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic