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
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."
Dne 01. 11. 18 v 22:46 Laird Nelson napsal(a):
I noticed that BeanManagerImpl permits many Contexts to be indexed
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
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.
weld-dev mailing list
Senior Software Engineer
Red Hat, Czech Republic