[cdi-dev] Types of Principal object
Werner Keil
werner.keil at gmail.com
Wed Apr 26 12:14:10 EDT 2017
Not sure, if I follow you on that?
java.security.Principal is not part of the CDI spec at all and only used by
a special subclass of
AbstractEEBean<T>
The problem seems the generic T which Java at this point is unable to know
about at runtime.
It makes no difference, if you had
PrincipalBean extends AbstractEEBean<Principal>
or a
StringBean extends AbstractBuiltInBean<String>
Even created a JUnit test in
https://github.com/unitsofmeasurement/uom-se/blob/master/src/test/java/tec/uom/se/AbsUnitTest.java
Which under Java 8 returns
"java.lang.reflect.TypeVariable<D>"
No sign of "Length" which is what you'd hoped for (maybe we did not dig
deep enough, maybe it won't work until a future Java version?)
Werner
On Wed, Apr 26, 2017 at 5:46 PM, <cdi-dev-request at lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Types of Principal object (Romain Manni-Bucau)
> 2. Re: Types of Principal object (Werner Keil)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 26 Apr 2017 17:41:08 +0200
> From: Romain Manni-Bucau <rmannibucau at gmail.com>
> Subject: Re: [cdi-dev] Types of Principal object
> To: arjan tijms <arjan.tijms at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
> <CACLE=7OK-JWXptMQxM8BUAvE2ab5gOwNiNBHCDbjy=
> UNkuEGQg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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 <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-04-26 17:11 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:
>
> > 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 at 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 at 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 at 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.
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/
> 20170426/ad930662/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Wed, 26 Apr 2017 17:44:04 +0200
> From: Werner Keil <werner.keil at gmail.com>
> Subject: Re: [cdi-dev] Types of Principal object
> To: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
> <CAAGawe1dmVUmgnrnmtV_oS0==fttYOe44ZhG4YfO+yme2=oT_A@
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Seems the title of the thread was also not "reified" in this case.
> Sometimes reply just works, but if it was lost, sorry for that.
>
> Werner
>
>
> On Wed, Apr 26, 2017 at 5:41 PM, Werner Keil <werner.keil at gmail.com>
> wrote:
>
> > We had similar challenges and discussions even before JSR 363 about
> > knowing what type of quantity you're dealing with types like
> >
> > Unit<Q extends Quantity <http://unitsofmeasurement.
> github.io/unit-api/site/apidocs/javax/measure/Quantity.html><Q>>
> >
> > I can only confirm Arjan's impression. And I had numerous conversations
> > with Andrew Kennedy, the Chief Architect behind the F# Units of
> Measurement
> > support and other .NET libraries about it. Where he mentioned
> shortcomings
> > of the Java language especially the lack of Reified Generics (
> > http://stackoverflow.com/questions/31876372/what-is-reification), which
> > C#, F# or other .NET languages got, but Java won't at least not until
> Java
> > 10, 11 or even later.
> >
> > I tried a lot between 2010 and now but so far none of these Reflection
> > tricks and approaches were stable enough, so not sure, if it'll work any
> > better in this case (unless you implement CDI in C#;-)
> >
> > Werner
> >
> >
> > On Wed, Apr 26, 2017 at 5:29 PM, <cdi-dev-request at lists.jboss.org>
> wrote:
> >
> >> Send cdi-dev mailing list submissions to
> >> cdi-dev at lists.jboss.org
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >> or, via email, send a message with subject or body 'help' to
> >> cdi-dev-request at lists.jboss.org
> >>
> >> You can reach the person managing the list at
> >> cdi-dev-owner at lists.jboss.org
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of cdi-dev digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >> 1. Types of Principal object (John Ament)
> >> 2. Re: Types of Principal object (Romain Manni-Bucau)
> >> 3. Re: Types of Principal object (Matej Novotny)
> >> 4. Re: Types of Principal object (arjan tijms)
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >> Message: 1
> >> Date: Wed, 26 Apr 2017 13:54:57 +0000
> >> From: John Ament <john.ament at spartasystems.com>
> >> Subject: [cdi-dev] Types of Principal object
> >> To: cdi-dev <cdi-dev at lists.jboss.org>
> >> Message-ID:
> >> <CY4PR04MB048607BF779F8680ED5CE53898110 at CY4PR04MB0486.namprd
> >> 04.prod.outlook.com>
> >>
> >> Content-Type: text/plain; charset="iso-8859-1"
> >>
> >> 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.
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
> >> 6/b6740722/attachment-0001.html
> >>
> >> ------------------------------
> >>
> >> Message: 2
> >> Date: Wed, 26 Apr 2017 16:38:01 +0200
> >> From: Romain Manni-Bucau <rmannibucau at gmail.com>
> >> Subject: Re: [cdi-dev] Types of Principal object
> >> To: John Ament <john.ament at spartasystems.com>
> >> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> >> Message-ID:
> >> <CACLE=7N=pkvZDX3ULCFAK2Fhw8-bH0pbOsqctqsbkPhKk8i1VA at mail.gm
> >> ail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> Hi John,
> >>
> >> agree CDI/security integration (mainly through Principal bean) is
> >> completely unusable in practise cause Principal type is too simple (name
> >> only) and casting is needed in 99.99% of apps. AFAIK It is tracked at
> >> https://issues.jboss.org/browse/CDI-597.
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> >> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> >> <https://javaeefactory-rmannibucau.rhcloud.com>
> >>
> >> 2017-04-26 15:54 GMT+02:00 John Ament <john.ament at spartasystems.com>:
> >>
> >> > 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 at 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.
> >> >
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
> >> 6/19976ebd/attachment-0001.html
> >>
> >> ------------------------------
> >>
> >> Message: 3
> >> Date: Wed, 26 Apr 2017 10:48:40 -0400 (EDT)
> >> From: Matej Novotny <manovotn at redhat.com>
> >> Subject: Re: [cdi-dev] Types of Principal object
> >> To: John Ament <john.ament at spartasystems.com>
> >> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> >> Message-ID:
> >> <1098875365.1348630.1493218120014.JavaMail.zimbra at redhat.com>
> >> Content-Type: text/plain; charset=utf-8
> >>
> >> Hey John,
> >>
> >> 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.
> >>
> >> Matej
> >>
> >> ----- 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?
> >> >
> >> >
> >> >
> >> >
> >> > 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 at 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.
> >>
> >>
> >> ------------------------------
> >>
> >> Message: 4
> >> Date: Wed, 26 Apr 2017 17:11:11 +0200
> >> From: arjan tijms <arjan.tijms at gmail.com>
> >> Subject: Re: [cdi-dev] Types of Principal object
> >> To: John Ament <john.ament at spartasystems.com>
> >> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> >> Message-ID:
> >> <CAE=-AhA0PiXZpSKmy0XYoMxCFuyxjV3Wt=jjFzhC=G+LOc9TDA at mail.
> >> gmail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> 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 at 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 at 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.
> >> >
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
> >> 6/206ff811/attachment.html
> >>
> >> ------------------------------
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev at 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.
> >>
> >> End of cdi-dev Digest, Vol 77, Issue 8
> >> **************************************
> >>
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/
> 20170426/ebea1962/attachment.html
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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.
>
> End of cdi-dev Digest, Vol 77, Issue 10
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/f9b63cb4/attachment-0001.html
More information about the cdi-dev
mailing list