Re: [cdi-dev] Best way to specify for spec that CDI contexts should be available?

Hi, 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 Servlet concern). On the other hand, the CDI spec defines when the request scope, session scope and application scope should be active, referencing other spec artifacts there. 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? Kind regards, Arjan Tijms _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.