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.

Hi Arjan, Are you just wondering on how this should be expressed in the specification ? If you look at most of the Java EE specs, there's often a "relationship to other specs" section (example Interceptor 1.2 "Relationship to Other Specifications"). EJB has two sections (2.8 - Relationship to Managed Bean Specification and 2.9 - Relationship to Contexts and Dependency Injection (CDI). If you read the relation to CDI section, you see things like "An EJB packaged into a CDI bean archive and not annotated with javax.enterprise.inject.Vetoed annotation, is considered a CDI-enabled bean" And, of course, most of the specs have a "Related Documents" section at the end that points to all the related specs. Antonio On Wed, Mar 25, 2015 at 3:54 PM, arjan tijms <arjan.tijms(a)gmail.com&gt; wrote: 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 &gt;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. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France _______________________________________________ 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.