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

[Mark Struberg]

Aside from other aspects, the whole sentence is wrong or at least not complete:

"An EJB packaged into a CDI bean archive and not annotated with javax.enterprise.inject.Vetoed annotation, is considered a CDI-enabled bean"


This misses ProcessAnnotatedType#veto() and all kind of other things. E.g. dynamically removing the javax.ejb.Stateless annotation. Does this make the EJB not being picked up? 

In other words: does EJB utilize the changes done via CDI Extensions?

LieGrue,
strub




On Thursday, 16 April 2015, 11:13, Antonio Goncalves <antonio.goncalves at gmail.com> wrote:


>
>
>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 at gmail.com> 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
>>cdi-dev at 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 at 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.
>
>