[cdi-dev] Types of Principal object
manovotn at redhat.com
Wed Apr 26 10:48:40 EDT 2017
just to shed some light.
One of the reasons it works this way is because the types the actual Principal has might not be proxyable.
And spec requires all built-in beans to be decorable - e.g. you need them to be proxyable (although the added value of principal decorator is ...eh, disputable at best?).
Therefore, it is safer/viable to create a proxyable wrapper object which implements Principal only and delegetas calls (that's what Weld does).
Otherwise I agree it could be nice to ahve a way to cast the object as the pure Principal interface doesn't help much.
----- Original Message -----
> From: "John Ament" <john.ament at spartasystems.com>
> To: "cdi-dev" <cdi-dev at lists.jboss.org>
> Sent: Wednesday, April 26, 2017 3:54:57 PM
> Subject: [cdi-dev] Types of Principal object
> 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?
> 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 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.
More information about the cdi-dev