[cdi-dev] Best way to specify for spec that CDI contexts should be available?
antonio.goncalves at gmail.com
Thu Apr 16 05:12:35 EDT 2015
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
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.
On Wed, Mar 25, 2015 at 3:54 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
> 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
> 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.
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cdi-dev