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

2018-11-02 Thread Laird Nelson
On Fri, Nov 2, 2018 at 1:25 AM Martin Kouba  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 ):

"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?

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.

(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
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

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

2018-11-02 Thread Martin Kouba
Hi Laird,

The reason why it is possible to register multiple context objects for a 
scope is that a particular context implementation may be intended for a 
specific use case/technology. Take for example the request context - it 
should be active during HTTP requests, async EJB invocation, MDB, etc. 
It wouldn't be practical to only have one Context implementation for all 
use cases.

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."

And even 6.2. The Context interface:
"A context object may be defined for any of the built-in scopes and 
registered with the container using the AfterBeanDiscovery event as 
described in AfterBeanDiscovery event."

HTH

Martin

Dne 01. 11. 18 v 22:46 Laird Nelson napsal(a):
> I noticed that BeanManagerImpl permits many Contexts to be indexed under 
> a given scope type 
> .
>   
> Why is that?
> 
> The CDI 2.0 specification says 
> :
> 
> "Associated with every scope type is a context object."
> 
> I took "a context object" to mean "exactly one context object" but maybe 
> I'm mistaken?  Obviously Weld can do things outside of the specification 
> but I was curious what the use case might be here.
> 
> I do understand that certainly only one Context of a given scope type 
> may be active.  I was just curious why the container even permits many 
> to be registered.
> 
> Best,
> Laird
> 
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev