Dne 02. 11. 18 v 22:07 Laird Nelson napsal(a): > On Fri, Nov 2, 2018 at 1:25 AM Martin Kouba <[email protected] > <mailto:[email protected]>> 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 _______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
