[cdi-dev] Best way to specify for spec that CDI contexts should be available?
arjan.tijms at gmail.com
Wed Mar 25 10:54:57 EDT 2015
In the Security EG many proposals that are currently being discussed depend
on CDI being available in authentication modules.
Low level authentication modules do not necessarily have to be beans
themselves, but they have to be able to programmatically pull beans from
the bean manager, in order to be able to delegate certain authentication
decisions to those.
Now if I'm not mistaken, CDI is most often initialized per request via a
ServletRequestListener (in a vendor specific way), so those obviously have
to be invoked before an authentication module is invoked (which is a
On the other hand, the CDI spec defines when the request scope, session
scope and application scope should be active, referencing other spec
Furthermore, it seems the CDI 2.0 spec is also working on providing APIs
for initializing CDI, but does that also take into account the per request
initialization that CDI implementations currently do? Would this be
powerful enough for code in an authentication module to initialize CDI
itself, such that request- session- and application scoped beans can be
pulled from the bean manager?
And if the above would be possible, what would happen if an authentication
module initialized the per request bits of CDI, and then afterwards (within
the same request) the container would attempt to initialize CDI as it would
normally do for usage in Servlets and Filters?
So, what would be spec-wise and practically speaking the best way to
specify that CDI should be available in authentication modules?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cdi-dev