I just wonder, what is it you are ultimately trying to achieve with contexts since you are
diving this deep?
That is, if it's not classified ;)
----- Original Message -----
From: "Laird Nelson" <ljnelson(a)gmail.com>
To: "Martin Kouba" <mkouba(a)redhat.com>
Sent: Friday, November 2, 2018 10:07:07 PM
Subject: Re: [weld-dev] BeanManagerImpl permits multiple Contexts per scope type: why?
On Fri, Nov 2, 2018 at 1:25 AM Martin Kouba < mkouba(a)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 (
"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 . 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?
I would say it is defined well, but yes, it behaves pretty much like you say.
Take for instance session scope (and its context). While you query the context, it may
well be active, but right after that, there could be session timeout
and that obviously kills the context as well. It is not something you can control, but you
need to account for that.
Contexts have quite well defined lifecycle in a way that you know when they are supposed
to be active and what ends them (request, session, conversation, your custom scope...).
Consider a (hypothetical, thought-experiment) stupid Context that tracks
whether it's active or not for a given Thread (using a Map of Thread s-to-
boolean s 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
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.
If I understand you correctly, then yes, this is true.
If you retrieve an active context and store it for later use, by the time you reach for
it, it may no longer be active.
For instance request context in SE can be activated on a per-method scope by annotation
(interceptor in fact). In such case you may get to activate/deactivate request context
many time over in a single thread.
Hence retrieving the context within the method which activates it will work, but using it
right after you exit that method will fail.
The immutability of context activeness wouldn't make sense at all.
(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.
weld-dev mailing list