7:29 a.m.
Hi,
On Thu, Apr 16, 2015 at 11:12 AM, Antonio Goncalves
<antonio.goncalves(a)gmail.com> wrote:
Are you just wondering on how this should be expressed in the
specification
?
Basically, but also in what specification this should be done, and
whether any support from CDI could take its place.
Some options:
1. JASPIC "simply" says: "In a Java EE environment CDI should be
available inside an auth module", and then whoever implements this for
a server product has to make sure this happens in whatever way.
2. Servlet specifies that ServletRequestListeners are called before an
auth module is called. Practically this will almost always make CDI
available as a side-effect (at least, I think it will)
3. CDI in its sections about @RequestScoped, @SessionScoped and
@ApplicationScoped says that these scopes should be active during a
call to an auth module.
4. CDI provides an API that JSR 375 (Security) can leverage to
activate the per request initialization of CDI inside a wrapper auth
module that it installs.
Thoughts?
Kind regards,
Arjan Tijms
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> 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(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