that's why security API needs a more typed API acting as an handler and not
as a contextual instance, it would allow to unwrap the actual instance
(like most specs do) but at CDI level it should also be possible. If not we
have this built-in bean never working until you add another not mandatory
spec - for CDI level. In other words either Principal is removed from CDI
spec or it stays but it should be extended to be made usable IMHO.
Romain Manni-Bucau
@rmannibucau <
Hi,
We discussed this very issue in the Security API EG as well. In the
Security API the actual type *MUST* be retained as per the spec definition.
The problem in CDI, at least in Weld, is that a proxy is injected. This
happens via the build-in bean "PrincipalBean extends AbstractEEBean", where
AbstractEEBean does:
public abstract class AbstractEEBean<T> extends
AbstractStaticallyDecorableBuiltInBean<T> {
private final T proxy;
protected AbstractEEBean(Class<T> type, Callable<T> callable,
BeanManagerImpl beanManager) {
super(beanManager, type);
this.proxy = new ProxyFactory<T>(beanManager.getContextId(),
type, getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new
CallableMethodHandler(callable)));
}
// ...
}
I'm not even sure if it's possible to downcast the proxy to the required
runtime type.
Also note that the Principal can change during the request. The simplest
case is when during an http request HttpServletRequest#logout is called.
Kind regards,
Arjan Tijms
On Wed, Apr 26, 2017 at 3:54 PM, John Ament <john.ament(a)spartasystems.com>
wrote:
> Hey guys
>
>
> I raised a bug against the Weld guys, but think its worth an EG
> discussion. When a Principal object is injected, the only type it has is
> Principal. It does not retain the actual type used at runtime. This threw
> me off on some Keycloak integration I'm working on (in $dayjob). So I was
> wondering, is this expected from our POV or should it retain the types of
> the actual runtime instance?
>
>
> John
>
> ------------------------------
> NOTICE: This e-mail message and any attachments may contain confidential,
> proprietary, and/or privileged information which should be treated
> accordingly. If you are not the intended recipient, please notify the
> sender immediately by return e-mail, delete this message, and destroy all
> physical and electronic copies. Thank you.
>
> _______________________________________________
> 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/license
> s/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.
>
_______________________________________________
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.