Quantcast

Re: cdi-dev Digest, Vol 77, Issue 8

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cdi-dev Digest, Vol 77, Issue 8

Werner Keil-2
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<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, <[hidden email]> wrote:
Send cdi-dev mailing list submissions to
        [hidden email]

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
        [hidden email]

You can reach the person managing the list at
        [hidden email]

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 <[hidden email]>
Subject: [cdi-dev] Types of Principal object
To: cdi-dev <[hidden email]>
Message-ID:
        <[hidden email]>

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/20170426/b6740722/attachment-0001.html

------------------------------

Message: 2
Date: Wed, 26 Apr 2017 16:38:01 +0200
From: Romain Manni-Bucau <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: John Ament <[hidden email]>
Cc: cdi-dev <[hidden email]>
Message-ID:
        <CACLE=7N=[hidden email]>
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 <[hidden email]>:

> 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
> [hidden email]
> 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/19976ebd/attachment-0001.html

------------------------------

Message: 3
Date: Wed, 26 Apr 2017 10:48:40 -0400 (EDT)
From: Matej Novotny <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: John Ament <[hidden email]>
Cc: cdi-dev <[hidden email]>
Message-ID:
        <[hidden email]>
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" <[hidden email]>
> To: "cdi-dev" <[hidden email]>
> 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
> [hidden email]
> 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 <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: John Ament <[hidden email]>
Cc: cdi-dev <[hidden email]>
Message-ID:
        <CAE=-AhA0PiXZpSKmy0XYoMxCFuyxjV3Wt=jjFzhC=[hidden email]>
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 <[hidden email]>
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
> [hidden email]
> 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/206ff811/attachment.html

------------------------------

_______________________________________________
cdi-dev mailing list
[hidden email]
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 8
**************************************


_______________________________________________
cdi-dev mailing list
[hidden email]
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.
Loading...