JSR 365 is not yet final, the FAB just started yesterday, but it had to be
a rather drastic change to still remove it from the CDI 2 Spec and RI,
otherwise letting 375 extend it sounds like a good idea.
Werner
On Wed, Apr 26, 2017 at 6:56 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
Send cdi-dev mailing list submissions to
cdi-dev(a)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(a)lists.jboss.org
You can reach the person managing the list at
cdi-dev-owner(a)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 (arjan tijms)
----------------------------------------------------------------------
Message: 1
Date: Wed, 26 Apr 2017 18:56:10 +0200
From: arjan tijms <arjan.tijms(a)gmail.com>
Subject: Re: [cdi-dev] Types of Principal object
To: Werner Keil <werner.keil(a)gmail.com>
Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
Message-ID:
<CAE=-AhD65_mWbOBM0JL-c_UzL4p-k_76_T_Y3E08PZNFpJJTHA@mail.
gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
We might do sub-types of Principal, and leave the base Principal at CDI
(since we can't change that now in CDI 2.0).
But we are also short of time. I'm not even sure TBH when the deadline for
the JSR 375 PR is.
Kind regards,
Arjan Tijms
On Wed, Apr 26, 2017 at 6:51 PM, Werner Keil <werner.keil(a)gmail.com>
wrote:
> If Soteria could handle something like that independent of the underlying
> CDI implementation, it would be great. At the moment it does not seem to
> require Weld, so unless it redefined the whole "AbstractBean"
> functionality, not sure, if we can do it there, but I would certainly
love
> to see it there if possible.
>
> Kind Regards,
> Werner
>
>
> On Wed, Apr 26, 2017 at 6:41 PM, arjan tijms <arjan.tijms(a)gmail.com>
> wrote:
>
>> Hi,
>>
>> On Wed, Apr 26, 2017 at 6:14 PM, Werner Keil <werner.keil(a)gmail.com>
>> wrote:
>>
>>> 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>
>>>
>>
>> I think what Romain intended here is that the build-in Bean<T> for
>> Principal is removed from CDI and moved to e.g. the Java EE Security
spec.
>> In case of Weld that would be org.jboss.weld.bean.builtin
>> .ee.PrincipalBean
>>
>> (see
http://grepcode.com/file/repo1.maven.org/maven2/org.jbo
>> ss.weld.servlet/weld-servlet/2.3.0.Beta3/org/jboss/weld/
>> bean/builtin/ee/PrincipalBean.java#PrincipalBean)
>>
>> The Principal type itself is of course not part of CDI, but part of Java
>> SE.
>>
>> Btw, a CDI extension can easily scan the application for occurrences of
>> Injection Points that have a Principal subtype as their target, and then
>> dynamically add a specific Bean<T> for that. This is what we do in
>> OmniFaces as well.
>>
>> See
>>
>> * Collecting types:
https://github.com/omnifaces/
omnifaces/blob/develop/
>> src/main/java/org/omnifaces/cdi/param/ParamExtension.java#L61
>>
>> * Adding a Bean<T> for each encountered type:
https://github.com/omnif
>> aces/omnifaces/blob/develop/src/main/java/org/omnifaces/
>> cdi/param/ParamExtension.java#L74
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>>
>>>
>>> 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(a)lists.jboss.org>
>>> wrote:
>>>
>>>> Send cdi-dev mailing list submissions to
>>>> cdi-dev(a)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(a)lists.jboss.org
>>>>
>>>> You can reach the person managing the list at
>>>> cdi-dev-owner(a)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(a)gmail.com>
>>>> Subject: Re: [cdi-dev] Types of Principal object
>>>> To: arjan tijms <arjan.tijms(a)gmail.com>
>>>> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
>>>> Message-ID:
>>>> <CACLE=7OK-JWXptMQxM8BUAvE2ab5gOwNiNBHCDbjy=UNkuEGQg(a)mail.gm
>>>> ail.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(a)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(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.
>>>> >
>>>> -------------- next part --------------
>>>> An HTML attachment was scrubbed...
>>>> URL:
http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>>>> 6/ad930662/attachment-0001.html
>>>>
>>>> ------------------------------
>>>>
>>>> Message: 2
>>>> Date: Wed, 26 Apr 2017 17:44:04 +0200
>>>> From: Werner Keil <werner.keil(a)gmail.com>
>>>> Subject: Re: [cdi-dev] Types of Principal object
>>>> To: cdi-dev <cdi-dev(a)lists.jboss.org>
>>>> Message-ID:
>>>> <CAAGawe1dmVUmgnrnmtV_oS0==fttYOe44ZhG4YfO+yme2=oT_A(a)mail.gm
>>>> ail.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(a)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.git
>>>>
hub.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(a)lists.jboss.org>
>>>> wrote:
>>>> >
>>>> >> Send cdi-dev mailing list submissions to
>>>> >> cdi-dev(a)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(a)lists.jboss.org
>>>> >>
>>>> >> You can reach the person managing the list at
>>>> >> cdi-dev-owner(a)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(a)spartasystems.com>
>>>> >> Subject: [cdi-dev] Types of Principal object
>>>> >> To: cdi-dev <cdi-dev(a)lists.jboss.org>
>>>> >> Message-ID:
>>>> >> <CY4PR04MB048607BF779F8680ED5CE
53898110(a)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(a)gmail.com>
>>>> >> Subject: Re: [cdi-dev] Types of Principal object
>>>> >> To: John Ament <john.ament(a)spartasystems.com>
>>>> >> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
>>>> >> Message-ID:
>>>> >>
<CACLE=7N=pkvZDX3ULCFAK2Fhw8-bH0pbOsqctqsbkPhKk8i1VA@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(a)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(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.
>>>> >> >
>>>> >> -------------- 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(a)redhat.com>
>>>> >> Subject: Re: [cdi-dev] Types of Principal object
>>>> >> To: John Ament <john.ament(a)spartasystems.com>
>>>> >> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
>>>> >> Message-ID:
>>>> >> <1098875365.1348630.1493218120014.JavaMail.zimbra@
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(a)spartasystems.com>
>>>> >> > To: "cdi-dev" <cdi-dev(a)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(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.
>>>> >>
>>>> >>
>>>> >> ------------------------------
>>>> >>
>>>> >> Message: 4
>>>> >> Date: Wed, 26 Apr 2017 17:11:11 +0200
>>>> >> From: arjan tijms <arjan.tijms(a)gmail.com>
>>>> >> Subject: Re: [cdi-dev] Types of Principal object
>>>> >> To: John Ament <john.ament(a)spartasystems.com>
>>>> >> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
>>>> >> Message-ID:
>>>> >>
<CAE=-AhA0PiXZpSKmy0XYoMxCFuyxjV3Wt=jjFzhC=G+LOc9TDA@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(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/
>>>> >> > 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(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.
>>>> >>
>>>> >> 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/2017042
>>>> 6/ebea1962/attachment.html
>>>>
>>>> ------------------------------
>>>>
>>>> _______________________________________________
>>>> 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.
>>>>
>>>> End of cdi-dev Digest, Vol 77, Issue 10
>>>> ***************************************
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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.
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.jboss.org/pipermail/cdi-dev/attachments/
20170426/b488a2eb/attachment.html
------------------------------
_______________________________________________
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.
End of cdi-dev Digest, Vol 77, Issue 17
***************************************