[
https://issues.jboss.org/browse/CDI-597?page=com.atlassian.jira.plugin.sy...
]
Romain Manni-Bucau commented on CDI-597:
----------------------------------------
[~mkouba] happy to do it but not tempted to parse method bodies with asm to do so handling
java code dependencies etc and that's actually the only way to do it from the
container point of view. Point is: very often you rely on a particular principal in the
login module and you use it in your app in a dependent manner to propagate some fields
(mail, display name...). The LoginModule could even instantiate different kind of
principal in its implementation and you could use a "switch" like logic in your
code if needed but for that or simply the basic need of accessing additional fields you
need to access the actual principal. Here CDI is blocking cause of proxies, user can't
really produce the Principal cause LoginModule are often reused (ie code is not under your
responsability).
Make Principal unwrappable
--------------------------
Key: CDI-597
URL:
https://issues.jboss.org/browse/CDI-597
Project: CDI Specification Issues
Issue Type: Epic
Reporter: Romain Manni-Bucau
CDI allows to get injected a Principal but often you need to access the actual Principal
instance when you need more than a name. Since the injection is a proxy (otherwise it
would be broken in most of scoped wrapper instances cases) we would need a CDI solution
to unwrap this instance.
Solution I see without creating a new kind of API but just something specific to this
case: CDIPrincipal extends Principal { <T> T unwrap(Class<T> t) } and allow to
get it injected directly as Principal today.
This issue can be linked to CDI-10 but here it is safe to add unwrap() where on CDI-10 it
is not (too general).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)