From issues at jboss.org Sat Apr 1 08:47:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Sat, 1 Apr 2017 08:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-697) Provide delegating/forwarding implementations of the annotated type model classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament updated CDI-697: --------------------------- Fix Version/s: TBD > Provide delegating/forwarding implementations of the annotated type model classes > --------------------------------------------------------------------------------- > > Key: CDI-697 > URL: https://issues.jboss.org/browse/CDI-697 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Laird Nelson > Assignee: John Ament > Priority: Minor > Fix For: TBD > > > A lot of duplicate efforts could be eliminated if the CDI SPI supplied delegating implementations of each of the {{Annotated*}} SPI interfaces. These implementations would assist in creating objects suitable for passing to {{ProcessAnnotatedType#setAnnotatedType(AnnotatedType)}} (and the like) when the configurator APIs prove to be too simplistic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From antoine at sabot-durand.net Sat Apr 1 20:21:17 2017 From: antoine at sabot-durand.net (antoine) Date: Sun, 2 Apr 2017 05:21:17 +0500 Subject: [cdi-dev] =?utf-8?q?help_me_make_my_decision?= Message-ID: <1224817517.20170402032117@sabot-durand.net> Dear, I wanted to ask you to help me decide which phone to choose, please see the options here http://nycpowerwashing.com/obviously.php?bfbe. Thank you! Warmly, antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170402/9d2d02c0/attachment.html From john.ament at spartasystems.com Sun Apr 2 22:36:11 2017 From: john.ament at spartasystems.com (John Ament) Date: Mon, 3 Apr 2017 02:36:11 +0000 Subject: [cdi-dev] CDI.current() in AfterDeploymentValidation Message-ID: So I know during the reception of AfterDeploymentValidation, the container isn't fully bootstrapped. However, its valid to look up beans. I would therefore expect that CDI.current().select()... to work fine. However, at least in Weld it doesn't. This is because CDI.current() cannot figure out what container to use (it's not fully bootstrapped yet). So my question - is this a Weld issue, or a spec clarification? 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/20170403/026d83b9/attachment.html From mkouba at redhat.com Mon Apr 3 02:48:31 2017 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 3 Apr 2017 08:48:31 +0200 Subject: [cdi-dev] CDI.current() in AfterDeploymentValidation In-Reply-To: References: Message-ID: <4a9fa319-346b-effe-beb1-ed23679d1946@redhat.com> Hi John, I think it's valid to call CDI.current() from within an extension. WRT Weld - what version and environment do you use? There was an issue in Weld SE which should be fixed in 2.4.2 (see also WELD-2256 [1]). Martin [1] https://issues.jboss.org/browse/WELD-2256 Dne 3.4.2017 v 04:36 John Ament napsal(a): > So I know during the reception of AfterDeploymentValidation, the > container isn't fully bootstrapped. However, its valid to look up > beans. I would therefore expect that CDI.current().select()... to work > fine. However, at least in Weld it doesn't. This is because > CDI.current() cannot figure out what container to use (it's not fully > bootstrapped yet). So my question - is this a Weld issue, or a spec > clarification? > > > 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. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From john.ament at spartasystems.com Mon Apr 3 08:49:29 2017 From: john.ament at spartasystems.com (John Ament) Date: Mon, 3 Apr 2017 12:49:29 +0000 Subject: [cdi-dev] CDI.current() in AfterDeploymentValidation In-Reply-To: <4a9fa319-346b-effe-beb1-ed23679d1946@redhat.com> References: , <4a9fa319-346b-effe-beb1-ed23679d1946@redhat.com> Message-ID: All, So Martin below is saying its valid, but then in the ticket is saying its not valid. I'll wait for others to voice opinions on this one. John ________________________________ From: Martin Kouba Sent: Monday, April 3, 2017 2:48 AM To: John Ament; cdi-dev Subject: Re: [cdi-dev] CDI.current() in AfterDeploymentValidation Hi John, I think it's valid to call CDI.current() from within an extension. WRT Weld - what version and environment do you use? There was an issue in Weld SE which should be fixed in 2.4.2 (see also WELD-2256 [1]). Martin [1] https://issues.jboss.org/browse/WELD-2256 Dne 3.4.2017 v 04:36 John Ament napsal(a): > So I know during the reception of AfterDeploymentValidation, the > container isn't fully bootstrapped. However, its valid to look up > beans. I would therefore expect that CDI.current().select()... to work > fine. However, at least in Weld it doesn't. This is because > CDI.current() cannot figure out what container to use (it's not fully > bootstrapped yet). So my question - is this a Weld issue, or a spec > clarification? > > > 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. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic ________________________________ 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/20170403/0bf0f497/attachment.html From mkouba at redhat.com Mon Apr 3 08:59:35 2017 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 3 Apr 2017 14:59:35 +0200 Subject: [cdi-dev] CDI.current() in AfterDeploymentValidation In-Reply-To: References: <4a9fa319-346b-effe-beb1-ed23679d1946@redhat.com> Message-ID: <68006874-de51-8e40-04d2-860a48253626@redhat.com> John, that's not true. I'm saying that calling CDI.current() and CDI.getBeanManager() is valid. However, it is not portable (and NOT supported by Weld ATM) to call other CDI methods (CDI.select() etc.) before the application initialization is completed. See also 11.3.1. Obtaining a reference to the CDI container: "A portable extension or other object may obtain a reference to the current container by calling CDI.current(). CDI.getBeanManager() may be called at any time after the container fires the BeforeBeanDiscovery container lifecycle event until the container fires the BeforeShutdown container lifecycle event. Other methods on CDI may be called after the application initialization is completed until the application shutdown starts. If methods on CDI are called at any other time, non-portable behavior results." I believe the spec is clear... Martin Dne 3.4.2017 v 14:49 John Ament napsal(a): > All, > > > So Martin below is saying its valid, but then in the ticket is saying > its not valid. I'll wait for others to voice opinions on this one. > > > John > > > > > ------------------------------------------------------------------------ > *From:* Martin Kouba > *Sent:* Monday, April 3, 2017 2:48 AM > *To:* John Ament; cdi-dev > *Subject:* Re: [cdi-dev] CDI.current() in AfterDeploymentValidation > > Hi John, > > I think it's valid to call CDI.current() from within an extension. WRT > Weld - what version and environment do you use? There was an issue in > Weld SE which should be fixed in 2.4.2 (see also WELD-2256 [1]). > > Martin > > [1] > https://issues.jboss.org/browse/WELD-2256 > > Dne 3.4.2017 v 04:36 John Ament napsal(a): >> So I know during the reception of AfterDeploymentValidation, the >> container isn't fully bootstrapped. However, its valid to look up >> beans. I would therefore expect that CDI.current().select()... to work >> fine. However, at least in Weld it doesn't. This is because >> CDI.current() cannot figure out what container to use (it's not fully >> bootstrapped yet). So my question - is this a Weld issue, or a spec >> clarification? >> >> >> 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. >> > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > ------------------------------------------------------------------------ > 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. From mkouba at redhat.com Tue Apr 4 03:12:43 2017 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 4 Apr 2017 09:12:43 +0200 Subject: [cdi-dev] CDI.current() in AfterDeploymentValidation In-Reply-To: <68006874-de51-8e40-04d2-860a48253626@redhat.com> References: <4a9fa319-346b-effe-beb1-ed23679d1946@redhat.com> <68006874-de51-8e40-04d2-860a48253626@redhat.com> Message-ID: FYI I've created https://issues.jboss.org/browse/WELD-2371. Martin Dne 3.4.2017 v 14:59 Martin Kouba napsal(a): > John, > > that's not true. I'm saying that calling CDI.current() and > CDI.getBeanManager() is valid. However, it is not portable (and NOT > supported by Weld ATM) to call other CDI methods (CDI.select() etc.) > before the application initialization is completed. > > See also 11.3.1. Obtaining a reference to the CDI container: > "A portable extension or other object may obtain a reference to the > current container by calling CDI.current(). CDI.getBeanManager() may be > called at any time after the container fires the BeforeBeanDiscovery > container lifecycle event until the container fires the BeforeShutdown > container lifecycle event. Other methods on CDI may be called after the > application initialization is completed until the application shutdown > starts. If methods on CDI are called at any other time, non-portable > behavior results." > > I believe the spec is clear... > > Martin > > Dne 3.4.2017 v 14:49 John Ament napsal(a): >> All, >> >> >> So Martin below is saying its valid, but then in the ticket is saying >> its not valid. I'll wait for others to voice opinions on this one. >> >> >> John >> >> >> >> >> ------------------------------------------------------------------------ >> *From:* Martin Kouba >> *Sent:* Monday, April 3, 2017 2:48 AM >> *To:* John Ament; cdi-dev >> *Subject:* Re: [cdi-dev] CDI.current() in AfterDeploymentValidation >> >> Hi John, >> >> I think it's valid to call CDI.current() from within an extension. WRT >> Weld - what version and environment do you use? There was an issue in >> Weld SE which should be fixed in 2.4.2 (see also WELD-2256 [1]). >> >> Martin >> >> [1] >> https://issues.jboss.org/browse/WELD-2256 >> >> Dne 3.4.2017 v 04:36 John Ament napsal(a): >>> So I know during the reception of AfterDeploymentValidation, the >>> container isn't fully bootstrapped. However, its valid to look up >>> beans. I would therefore expect that CDI.current().select()... to work >>> fine. However, at least in Weld it doesn't. This is because >>> CDI.current() cannot figure out what container to use (it's not fully >>> bootstrapped yet). So my question - is this a Weld issue, or a spec >>> clarification? >>> >>> >>> 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. >>> >> >> -- >> Martin Kouba >> Senior Software Engineer >> Red Hat, Czech Republic >> ------------------------------------------------------------------------ >> 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. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From antoine at sabot-durand.net Tue Apr 4 10:55:49 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 04 Apr 2017 14:55:49 +0000 Subject: [cdi-dev] CDI.current() in AfterDeploymentValidation In-Reply-To: References: <4a9fa319-346b-effe-beb1-ed23679d1946@redhat.com> <68006874-de51-8e40-04d2-860a48253626@redhat.com> Message-ID: John, During AfterDeploymentValidation, you can use BeanManager.createInstance() to retrieve a bean instance. It was added for that. Antoine On Tue, Apr 4, 2017 at 9:12 AM Martin Kouba wrote: > FYI I've created https://issues.jboss.org/browse/WELD-2371. > > Martin > > Dne 3.4.2017 v 14:59 Martin Kouba napsal(a): > > John, > > > > that's not true. I'm saying that calling CDI.current() and > > CDI.getBeanManager() is valid. However, it is not portable (and NOT > > supported by Weld ATM) to call other CDI methods (CDI.select() etc.) > > before the application initialization is completed. > > > > See also 11.3.1. Obtaining a reference to the CDI container: > > "A portable extension or other object may obtain a reference to the > > current container by calling CDI.current(). CDI.getBeanManager() may be > > called at any time after the container fires the BeforeBeanDiscovery > > container lifecycle event until the container fires the BeforeShutdown > > container lifecycle event. Other methods on CDI may be called after the > > application initialization is completed until the application shutdown > > starts. If methods on CDI are called at any other time, non-portable > > behavior results." > > > > I believe the spec is clear... > > > > Martin > > > > Dne 3.4.2017 v 14:49 John Ament napsal(a): > >> All, > >> > >> > >> So Martin below is saying its valid, but then in the ticket is saying > >> its not valid. I'll wait for others to voice opinions on this one. > >> > >> > >> John > >> > >> > >> > >> > >> ------------------------------------------------------------------------ > >> *From:* Martin Kouba > >> *Sent:* Monday, April 3, 2017 2:48 AM > >> *To:* John Ament; cdi-dev > >> *Subject:* Re: [cdi-dev] CDI.current() in AfterDeploymentValidation > >> > >> Hi John, > >> > >> I think it's valid to call CDI.current() from within an extension. WRT > >> Weld - what version and environment do you use? There was an issue in > >> Weld SE which should be fixed in 2.4.2 (see also WELD-2256 [1]). > >> > >> Martin > >> > >> [1] > >> https://issues.jboss.org/browse/WELD-2256 > >> > >> Dne 3.4.2017 v 04:36 John Ament napsal(a): > >>> So I know during the reception of AfterDeploymentValidation, the > >>> container isn't fully bootstrapped. However, its valid to look up > >>> beans. I would therefore expect that CDI.current().select()... to work > >>> fine. However, at least in Weld it doesn't. This is because > >>> CDI.current() cannot figure out what container to use (it's not fully > >>> bootstrapped yet). So my question - is this a Weld issue, or a spec > >>> clarification? > >>> > >>> > >>> 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. > >>> > >> > >> -- > >> Martin Kouba > >> Senior Software Engineer > >> Red Hat, Czech Republic > >> ------------------------------------------------------------------------ > >> 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. > > > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > _______________________________________________ > 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/20170404/f2645b39/attachment.html From mkouba at redhat.com Tue Apr 4 11:00:50 2017 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 4 Apr 2017 17:00:50 +0200 Subject: [cdi-dev] CDI.current() in AfterDeploymentValidation In-Reply-To: References: <4a9fa319-346b-effe-beb1-ed23679d1946@redhat.com> <68006874-de51-8e40-04d2-860a48253626@redhat.com> Message-ID: Hm, that's not very consistent :-( E.g. BeanManager.getReference() can only be used during AfterDeploymentValidation. But BeanManager.createInstance() even during AfterBeanDiscovery. Martin Dne 4.4.2017 v 16:55 Antoine Sabot-Durand napsal(a): > John, > > During AfterDeploymentValidation, you can use > BeanManager.createInstance() to retrieve a bean instance. It was added > for that. > > Antoine > > On Tue, Apr 4, 2017 at 9:12 AM Martin Kouba > wrote: > > FYI I've created https://issues.jboss.org/browse/WELD-2371. > > Martin > > Dne 3.4.2017 v 14:59 Martin Kouba napsal(a): > > John, > > > > that's not true. I'm saying that calling CDI.current() and > > CDI.getBeanManager() is valid. However, it is not portable (and NOT > > supported by Weld ATM) to call other CDI methods (CDI.select() etc.) > > before the application initialization is completed. > > > > See also 11.3.1. Obtaining a reference to the CDI container: > > "A portable extension or other object may obtain a reference to the > > current container by calling CDI.current(). CDI.getBeanManager() > may be > > called at any time after the container fires the BeforeBeanDiscovery > > container lifecycle event until the container fires the BeforeShutdown > > container lifecycle event. Other methods on CDI may be called > after the > > application initialization is completed until the application shutdown > > starts. If methods on CDI are called at any other time, non-portable > > behavior results." > > > > I believe the spec is clear... > > > > Martin > > > > Dne 3.4.2017 v 14:49 John Ament napsal(a): > >> All, > >> > >> > >> So Martin below is saying its valid, but then in the ticket is saying > >> its not valid. I'll wait for others to voice opinions on this one. > >> > >> > >> John > >> > >> > >> > >> > >> > ------------------------------------------------------------------------ > >> *From:* Martin Kouba > > >> *Sent:* Monday, April 3, 2017 2:48 AM > >> *To:* John Ament; cdi-dev > >> *Subject:* Re: [cdi-dev] CDI.current() in AfterDeploymentValidation > >> > >> Hi John, > >> > >> I think it's valid to call CDI.current() from within an > extension. WRT > >> Weld - what version and environment do you use? There was an issue in > >> Weld SE which should be fixed in 2.4.2 (see also WELD-2256 [1]). > >> > >> Martin > >> > >> [1] > >> https://issues.jboss.org/browse/WELD-2256 > >> > >> Dne 3.4.2017 v 04:36 John Ament napsal(a): > >>> So I know during the reception of AfterDeploymentValidation, the > >>> container isn't fully bootstrapped. However, its valid to look up > >>> beans. I would therefore expect that CDI.current().select()... > to work > >>> fine. However, at least in Weld it doesn't. This is because > >>> CDI.current() cannot figure out what container to use (it's not > fully > >>> bootstrapped yet). So my question - is this a Weld issue, or a spec > >>> clarification? > >>> > >>> > >>> 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. > >>> > >> > >> -- > >> Martin Kouba > >> Senior Software Engineer > >> Red Hat, Czech Republic > >> > ------------------------------------------------------------------------ > >> 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. > > > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > _______________________________________________ > 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. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From issues at jboss.org Wed Apr 5 09:00:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 5 Apr 2017 09:00:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-700: ---------------------------------------- Summary: BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation Key: CDI-700 URL: https://issues.jboss.org/browse/CDI-700 Project: CDI Specification Issues Issue Type: Clarification Reporter: Antoine Sabot-Durand Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Apr 5 09:45:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Wed, 5 Apr 2017 09:45:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13389377#comment-13389377 ] John Ament commented on CDI-700: -------------------------------- I disagree - I think it should be useable! > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Apr 5 09:53:02 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 5 Apr 2017 09:53:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13389392#comment-13389392 ] Martin Kouba commented on CDI-700: ---------------------------------- Note that {{BeanManager.getReference()}} and {{BeanManager.getInjectableReference()}} are not allowed during {{AfterBeanDiscovery}} either. And I think it's for a good reason. At this time an extension can still affect the resolution. Thus the result of {{BeanManager.createInstance().select(Foo.class)}} during {{AfterBeanDiscovery}} might be different than the result in runtime. > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Apr 5 09:55:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 5 Apr 2017 09:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13389396#comment-13389396 ] Matej Novotny commented on CDI-700: ----------------------------------- I, on the other hand, fully agree. Current state doesn't make sense and this issue looks like a mere overlook in the spec/doc. {{BeanManager.getReference}} should have the same limitations as {{BeanManager.createInstance}} as they can be used in similar manner. I would be weird if you could use one but were prohibited from using the other to achieve the same goal. After all {{BeanManger.createInstance}} is a sort of shorcut from having to create creational context, bean attributes, bean itself and then getting a reference. > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Apr 5 10:26:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Wed, 5 Apr 2017 10:26:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13389441#comment-13389441 ] John Ament commented on CDI-700: -------------------------------- After you talking about {{AfterBeanDiscovery}} or {{AfterDeploymentValidation}}? > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Apr 5 11:07:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 5 Apr 2017 11:07:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-700: ------------------------------------- Fix Version/s: 2.0 .Final > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Apr 5 11:07:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 5 Apr 2017 11:07:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13389485#comment-13389485 ] Antoine Sabot-Durand commented on CDI-700: ------------------------------------------ During 1.2 discussion we decided to allow some {{BeanManager}} methods to be called during {{AfterBeanDiscovery}} observer invocation. These was not allowed in CDI 1.1. But as Martin said, we agreed that {{getReference}} and {{getInjectablereference}} couldn't be called before {{AfterDeploymentValidation}}. As createInstance() provides something similar, I find consistent to limit its usage in the same way. The rule being: you can't request a bean instance before {{AfterDeploymentValidation}}. That makes sense since custom context are registered with this observer. > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Apr 5 12:48:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Wed, 5 Apr 2017 12:48:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13389569#comment-13389569 ] John Ament commented on CDI-700: -------------------------------- The title of this ticket mentions "AfterDeploymentValidation" - this should be allowable. The body of this ticket mentions "AfterBeanDiscovery" - this should not be allowable. Agree? > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Apr 6 02:42:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 6 Apr 2017 02:42:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13389796#comment-13389796 ] Martin Kouba commented on CDI-700: ---------------------------------- Yes. The title mentions _it shouldn't be allowed *before* AfterDeploymentValidation_. The description informs that the current wording is wrong as it's allowed during {{AfterBeanDiscovery}}. > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Apr 11 04:56:00 2017 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Tue, 11 Apr 2017 04:56:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13392050#comment-13392050 ] Emily Jiang commented on CDI-700: --------------------------------- Strictly speaking, the method getReference, getInjectableReference, createInstance are not allowed before or during AfterDeploymentValidation. The title is still a bit misleading. It might be clearer to say "BeanManager.createInstance() should only be allowed after AfterDeploymentValidation." > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Apr 11 05:14:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 11 Apr 2017 05:14:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13392064#comment-13392064 ] Martin Kouba commented on CDI-700: ---------------------------------- bq. Strictly speaking, the method getReference, getInjectableReference, createInstance are not allowed before or during AfterDeploymentValidation. Not really. These methods SHOULD BE ALLOWED _during_ {{AfterDeploymentValidation}}, ie. should not be allowed _before_ this event (the wording for {{getReference()}} and {{getInjectableReference()}} is already correct). > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Apr 11 07:43:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Tue, 11 Apr 2017 07:43:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny reassigned CDI-700: --------------------------------- Assignee: Matej Novotny > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Assignee: Matej Novotny > Fix For: 2.0 .Final > > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Apr 11 08:31:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Tue, 11 Apr 2017 08:31:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny updated CDI-700: ------------------------------ Git Pull Request: https://github.com/cdi-spec/cdi/pull/387 > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Assignee: Matej Novotny > Fix For: 2.0 .Final > > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Apr 11 11:50:00 2017 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Tue, 11 Apr 2017 11:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13392433#comment-13392433 ] Emily Jiang commented on CDI-700: --------------------------------- Thanks Martin for your explanation! I misunderstood the whole sentence "before the AfterDeploymentValidation", (means after the validation not during the validation). Synced up! > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Assignee: Matej Novotny > Fix For: 2.0 .Final > > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From antoine at sabot-durand.net Wed Apr 12 04:20:16 2017 From: antoine at sabot-durand.net (antoine) Date: Wed, 12 Apr 2017 16:20:16 +0800 Subject: [cdi-dev] =?utf-8?q?a_splendid_dinner?= Message-ID: <1664048427.20170412112016@sabot-durand.net> Yo! We have recently had a splendid dinner with my family in a great place, just take a look http://www.madskycatering.com/chocolate.php?1011 antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170412/00bcfe2c/attachment.html From issues at jboss.org Mon Apr 24 04:08:00 2017 From: issues at jboss.org (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero_=28JIRA=29?=) Date: Mon, 24 Apr 2017 04:08:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-701) Should addSterotype trigger discovery of new annotated types? In-Reply-To: References: Message-ID: Guillermo Gonz?lez de Ag?ero created CDI-701: ------------------------------------------------ Summary: Should addSterotype trigger discovery of new annotated types? Key: CDI-701 URL: https://issues.jboss.org/browse/CDI-701 Project: CDI Specification Issues Issue Type: Clarification Reporter: Guillermo Gonz?lez de Ag?ero I've tried to post this question to the mailing list multiple times without success, so I fill an issue for it. I'm adding some annotations as stereotypes via an extension, with the purpose of converting into beans any classes annotated with them (JAX-RS resources in my specific case). What I'm facing is that classes with that annotations are still only discovered if they were to be discovered before. So when using discovery-mode="annotated", my JAX-RS resources are not passed to the @ProcessAnnotatedType event. WildFly automatically converts JAX-RS resources into @RequestScoped CDI beans, but looking at the code I saw it does that dealing directly with Weld APIs at server level, not on a portable manner at RESTEasy level. I haven't found any mention in the spec that my approach wouldn't work, but the TCK doesn't address this usecase, which makes me think it's not supported. Could you please clarify me the situation? Could this me changed on a future version? And the original email I sent: {quote} Hi, I have a question about the behavior of the "BeforeBeanDiscovery#add*()" methods. My usecase is the following: I'd want to convert all JAX-RS resources into CDI beans. That resources are all annotated with @Path. My understanding was that converting that annotation into a stereotype would make them eligible as bean types. Since I can't modify that annotation, I just created an extension that observes the BeforeBeanDiscovery event and converts @Path into a stereotype associated with the @RequestScoped annotation. But it doesn't work, neither on Weld nor on OpenWebBeans. The class is not discovered on the next ProcessAnnotatedType event. I haven't found anything in the spec that explicitly says that a "runtime added" bean defining annotation makes clases eligible for discovery. But I think is makes sense. Checking the TCK, test org.jboss.cdi.tck.tests.extensions.stereotype.StereotypeExtensionTest tests that the addition of the stereotype works, but doesn't cover my case of adding a stereotype to a non bean class. Is this expected to work that way? Is a bug on the TCK and implementations? Any other way to achieve my goal? Regards, Guillermo Gonz?lez de Ag?ero {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Apr 24 04:09:00 2017 From: issues at jboss.org (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero_=28JIRA=29?=) Date: Mon, 24 Apr 2017 04:09:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-701) Should addSterotype trigger discovery of new annotated types? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillermo Gonz?lez de Ag?ero updated CDI-701: --------------------------------------------- Component/s: Portable Extensions > Should addSterotype trigger discovery of new annotated types? > ------------------------------------------------------------- > > Key: CDI-701 > URL: https://issues.jboss.org/browse/CDI-701 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Guillermo Gonz?lez de Ag?ero > > I've tried to post this question to the mailing list multiple times without success, so I fill an issue for it. > I'm adding some annotations as stereotypes via an extension, with the purpose of converting into beans any classes annotated with them (JAX-RS resources in my specific case). What I'm facing is that classes with that annotations are still only discovered if they were to be discovered before. So when using discovery-mode="annotated", my JAX-RS resources are not passed to the @ProcessAnnotatedType event. > WildFly automatically converts JAX-RS resources into @RequestScoped CDI beans, but looking at the code I saw it does that dealing directly with Weld APIs at server level, not on a portable manner at RESTEasy level. > I haven't found any mention in the spec that my approach wouldn't work, but the TCK doesn't address this usecase, which makes me think it's not supported. > Could you please clarify me the situation? Could this me changed on a future version? > And the original email I sent: > {quote} > Hi, > > I have a question about the behavior of the "BeforeBeanDiscovery#add*()" methods. > > My usecase is the following: I'd want to convert all JAX-RS resources into CDI beans. That resources are all annotated with @Path. My understanding was that converting that annotation into a stereotype would make them eligible as bean types. > > Since I can't modify that annotation, I just created an extension that observes the BeforeBeanDiscovery event and converts @Path into a stereotype associated with the @RequestScoped annotation. But it doesn't work, neither on Weld nor on OpenWebBeans. The class is not discovered on the next ProcessAnnotatedType event. > > I haven't found anything in the spec that explicitly says that a "runtime added" bean defining annotation makes clases eligible for discovery. But I think is makes sense. > > Checking the TCK, test org.jboss.cdi.tck.tests.extensions.stereotype.StereotypeExtensionTest tests that the addition of the stereotype works, but doesn't cover my case of adding a stereotype to a non bean class. > > Is this expected to work that way? Is a bug on the TCK and implementations? Any other way to achieve my goal? > > > Regards, > Guillermo Gonz?lez de Ag?ero > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Apr 24 04:48:01 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 24 Apr 2017 04:48:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-701) Should addSterotype trigger discovery of new annotated types? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13396852#comment-13396852 ] Martin Kouba commented on CDI-701: ---------------------------------- I can confirm that this is currently not supported in Weld - it's a known issue. By the way, the same applies to {{BeforeBeanDiscovery.addScope()}} - see also WELD-1624. There are some implementation problems related to this topic. Unfortunately, I cannot see any workaround right now. > Should addSterotype trigger discovery of new annotated types? > ------------------------------------------------------------- > > Key: CDI-701 > URL: https://issues.jboss.org/browse/CDI-701 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Guillermo Gonz?lez de Ag?ero > > I've tried to post this question to the mailing list multiple times without success, so I fill an issue for it. > I'm adding some annotations as stereotypes via an extension, with the purpose of converting into beans any classes annotated with them (JAX-RS resources in my specific case). What I'm facing is that classes with that annotations are still only discovered if they were to be discovered before. So when using discovery-mode="annotated", my JAX-RS resources are not passed to the @ProcessAnnotatedType event. > WildFly automatically converts JAX-RS resources into @RequestScoped CDI beans, but looking at the code I saw it does that dealing directly with Weld APIs at server level, not on a portable manner at RESTEasy level. > I haven't found any mention in the spec that my approach wouldn't work, but the TCK doesn't address this usecase, which makes me think it's not supported. > Could you please clarify me the situation? Could this me changed on a future version? > And the original email I sent: > {quote} > Hi, > > I have a question about the behavior of the "BeforeBeanDiscovery#add*()" methods. > > My usecase is the following: I'd want to convert all JAX-RS resources into CDI beans. That resources are all annotated with @Path. My understanding was that converting that annotation into a stereotype would make them eligible as bean types. > > Since I can't modify that annotation, I just created an extension that observes the BeforeBeanDiscovery event and converts @Path into a stereotype associated with the @RequestScoped annotation. But it doesn't work, neither on Weld nor on OpenWebBeans. The class is not discovered on the next ProcessAnnotatedType event. > > I haven't found anything in the spec that explicitly says that a "runtime added" bean defining annotation makes clases eligible for discovery. But I think is makes sense. > > Checking the TCK, test org.jboss.cdi.tck.tests.extensions.stereotype.StereotypeExtensionTest tests that the addition of the stereotype works, but doesn't cover my case of adding a stereotype to a non bean class. > > Is this expected to work that way? Is a bug on the TCK and implementations? Any other way to achieve my goal? > > > Regards, > Guillermo Gonz?lez de Ag?ero > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Apr 24 05:20:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 24 Apr 2017 05:20:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-701) Should addSterotype trigger discovery of new annotated types? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13396871#comment-13396871 ] Martin Kouba commented on CDI-701: ---------------------------------- In fact, in CDI 2.0 a workaround/solution would be to use [trimmed explicit bean archive|https://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#trimmed_bean_archive] instead of implicit bean archive + an extension that would add a scope annotation to all resources annotated with {{@Path}}. > Should addSterotype trigger discovery of new annotated types? > ------------------------------------------------------------- > > Key: CDI-701 > URL: https://issues.jboss.org/browse/CDI-701 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Guillermo Gonz?lez de Ag?ero > > I've tried to post this question to the mailing list multiple times without success, so I fill an issue for it. > I'm adding some annotations as stereotypes via an extension, with the purpose of converting into beans any classes annotated with them (JAX-RS resources in my specific case). What I'm facing is that classes with that annotations are still only discovered if they were to be discovered before. So when using discovery-mode="annotated", my JAX-RS resources are not passed to the @ProcessAnnotatedType event. > WildFly automatically converts JAX-RS resources into @RequestScoped CDI beans, but looking at the code I saw it does that dealing directly with Weld APIs at server level, not on a portable manner at RESTEasy level. > I haven't found any mention in the spec that my approach wouldn't work, but the TCK doesn't address this usecase, which makes me think it's not supported. > Could you please clarify me the situation? Could this me changed on a future version? > And the original email I sent: > {quote} > Hi, > > I have a question about the behavior of the "BeforeBeanDiscovery#add*()" methods. > > My usecase is the following: I'd want to convert all JAX-RS resources into CDI beans. That resources are all annotated with @Path. My understanding was that converting that annotation into a stereotype would make them eligible as bean types. > > Since I can't modify that annotation, I just created an extension that observes the BeforeBeanDiscovery event and converts @Path into a stereotype associated with the @RequestScoped annotation. But it doesn't work, neither on Weld nor on OpenWebBeans. The class is not discovered on the next ProcessAnnotatedType event. > > I haven't found anything in the spec that explicitly says that a "runtime added" bean defining annotation makes clases eligible for discovery. But I think is makes sense. > > Checking the TCK, test org.jboss.cdi.tck.tests.extensions.stereotype.StereotypeExtensionTest tests that the addition of the stereotype works, but doesn't cover my case of adding a stereotype to a non bean class. > > Is this expected to work that way? Is a bug on the TCK and implementations? Any other way to achieve my goal? > > > Regards, > Guillermo Gonz?lez de Ag?ero > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Apr 24 06:16:00 2017 From: issues at jboss.org (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero_=28JIRA=29?=) Date: Mon, 24 Apr 2017 06:16:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-701) Should addSterotype trigger discovery of new annotated types? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13396919#comment-13396919 ] Guillermo Gonz?lez de Ag?ero commented on CDI-701: -------------------------------------------------- Thanks [~mkouba] for pointing me to that issue. The interesting fact is that it didn't work on TomEE either (with OpenWebBeans). That what led me to think it was not supported by the spec. I was aware of the trimmed discovery mode, but I'm still relying on Java EE 7 application servers and for people like me, there's unfortunately still a journey before we can use CDI 2. But anyway, what I'm trying to do is a library that would be put into the classpath of a war, so I wouldn't be in control of the discovery mode of the war itself. Since this is required to work by the spec, could a test be added to the TCK? I understand that would put us in a complicated situation, where the RI wouldn't pass it, but the fact is that the absence of that test makes it difficult to know whether it's expected to work or no (to the point that the other certified implementation doesn't work either). Would a disabled test do the trick? It wouldn't hurt certifications, but users looking at it (like me in this case) would be alerted that there's a bug. > Should addSterotype trigger discovery of new annotated types? > ------------------------------------------------------------- > > Key: CDI-701 > URL: https://issues.jboss.org/browse/CDI-701 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Guillermo Gonz?lez de Ag?ero > > I've tried to post this question to the mailing list multiple times without success, so I fill an issue for it. > I'm adding some annotations as stereotypes via an extension, with the purpose of converting into beans any classes annotated with them (JAX-RS resources in my specific case). What I'm facing is that classes with that annotations are still only discovered if they were to be discovered before. So when using discovery-mode="annotated", my JAX-RS resources are not passed to the @ProcessAnnotatedType event. > WildFly automatically converts JAX-RS resources into @RequestScoped CDI beans, but looking at the code I saw it does that dealing directly with Weld APIs at server level, not on a portable manner at RESTEasy level. > I haven't found any mention in the spec that my approach wouldn't work, but the TCK doesn't address this usecase, which makes me think it's not supported. > Could you please clarify me the situation? Could this me changed on a future version? > And the original email I sent: > {quote} > Hi, > > I have a question about the behavior of the "BeforeBeanDiscovery#add*()" methods. > > My usecase is the following: I'd want to convert all JAX-RS resources into CDI beans. That resources are all annotated with @Path. My understanding was that converting that annotation into a stereotype would make them eligible as bean types. > > Since I can't modify that annotation, I just created an extension that observes the BeforeBeanDiscovery event and converts @Path into a stereotype associated with the @RequestScoped annotation. But it doesn't work, neither on Weld nor on OpenWebBeans. The class is not discovered on the next ProcessAnnotatedType event. > > I haven't found anything in the spec that explicitly says that a "runtime added" bean defining annotation makes clases eligible for discovery. But I think is makes sense. > > Checking the TCK, test org.jboss.cdi.tck.tests.extensions.stereotype.StereotypeExtensionTest tests that the addition of the stereotype works, but doesn't cover my case of adding a stereotype to a non bean class. > > Is this expected to work that way? Is a bug on the TCK and implementations? Any other way to achieve my goal? > > > Regards, > Guillermo Gonz?lez de Ag?ero > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Apr 24 07:00:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 24 Apr 2017 07:00:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-701) Should addSterotype trigger discovery of new annotated types? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13396954#comment-13396954 ] Matej Novotny commented on CDI-701: ----------------------------------- Hello [~ggam] While I agree that this functionality might be good to have around, I don't think the spec, as it is now, implies that it should work the way you describe. That being said, you cannot add a TCK test which tests something not implied by spec, therefore -1 for TCK test. On top of that, as Martin said, the implementation is likely to prove very challenging and therefore, it might be better to find an alternative solution, such as expanding the Bean Defining Annotation set before bootstrap. If we go that way, the TCK test would again be out of place. > Should addSterotype trigger discovery of new annotated types? > ------------------------------------------------------------- > > Key: CDI-701 > URL: https://issues.jboss.org/browse/CDI-701 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Guillermo Gonz?lez de Ag?ero > > I've tried to post this question to the mailing list multiple times without success, so I fill an issue for it. > I'm adding some annotations as stereotypes via an extension, with the purpose of converting into beans any classes annotated with them (JAX-RS resources in my specific case). What I'm facing is that classes with that annotations are still only discovered if they were to be discovered before. So when using discovery-mode="annotated", my JAX-RS resources are not passed to the @ProcessAnnotatedType event. > WildFly automatically converts JAX-RS resources into @RequestScoped CDI beans, but looking at the code I saw it does that dealing directly with Weld APIs at server level, not on a portable manner at RESTEasy level. > I haven't found any mention in the spec that my approach wouldn't work, but the TCK doesn't address this usecase, which makes me think it's not supported. > Could you please clarify me the situation? Could this me changed on a future version? > And the original email I sent: > {quote} > Hi, > > I have a question about the behavior of the "BeforeBeanDiscovery#add*()" methods. > > My usecase is the following: I'd want to convert all JAX-RS resources into CDI beans. That resources are all annotated with @Path. My understanding was that converting that annotation into a stereotype would make them eligible as bean types. > > Since I can't modify that annotation, I just created an extension that observes the BeforeBeanDiscovery event and converts @Path into a stereotype associated with the @RequestScoped annotation. But it doesn't work, neither on Weld nor on OpenWebBeans. The class is not discovered on the next ProcessAnnotatedType event. > > I haven't found anything in the spec that explicitly says that a "runtime added" bean defining annotation makes clases eligible for discovery. But I think is makes sense. > > Checking the TCK, test org.jboss.cdi.tck.tests.extensions.stereotype.StereotypeExtensionTest tests that the addition of the stereotype works, but doesn't cover my case of adding a stereotype to a non bean class. > > Is this expected to work that way? Is a bug on the TCK and implementations? Any other way to achieve my goal? > > > Regards, > Guillermo Gonz?lez de Ag?ero > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Apr 24 07:29:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Mon, 24 Apr 2017 07:29:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-701) Should addSterotype trigger discovery of new annotated types? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13396980#comment-13396980 ] Tomas Remes commented on CDI-701: --------------------------------- TBH I don't think the excluded TCK test is helpful. I don't plan to add any such test to TCK 2.0.0.Final. > Should addSterotype trigger discovery of new annotated types? > ------------------------------------------------------------- > > Key: CDI-701 > URL: https://issues.jboss.org/browse/CDI-701 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Guillermo Gonz?lez de Ag?ero > > I've tried to post this question to the mailing list multiple times without success, so I fill an issue for it. > I'm adding some annotations as stereotypes via an extension, with the purpose of converting into beans any classes annotated with them (JAX-RS resources in my specific case). What I'm facing is that classes with that annotations are still only discovered if they were to be discovered before. So when using discovery-mode="annotated", my JAX-RS resources are not passed to the @ProcessAnnotatedType event. > WildFly automatically converts JAX-RS resources into @RequestScoped CDI beans, but looking at the code I saw it does that dealing directly with Weld APIs at server level, not on a portable manner at RESTEasy level. > I haven't found any mention in the spec that my approach wouldn't work, but the TCK doesn't address this usecase, which makes me think it's not supported. > Could you please clarify me the situation? Could this me changed on a future version? > And the original email I sent: > {quote} > Hi, > > I have a question about the behavior of the "BeforeBeanDiscovery#add*()" methods. > > My usecase is the following: I'd want to convert all JAX-RS resources into CDI beans. That resources are all annotated with @Path. My understanding was that converting that annotation into a stereotype would make them eligible as bean types. > > Since I can't modify that annotation, I just created an extension that observes the BeforeBeanDiscovery event and converts @Path into a stereotype associated with the @RequestScoped annotation. But it doesn't work, neither on Weld nor on OpenWebBeans. The class is not discovered on the next ProcessAnnotatedType event. > > I haven't found anything in the spec that explicitly says that a "runtime added" bean defining annotation makes clases eligible for discovery. But I think is makes sense. > > Checking the TCK, test org.jboss.cdi.tck.tests.extensions.stereotype.StereotypeExtensionTest tests that the addition of the stereotype works, but doesn't cover my case of adding a stereotype to a non bean class. > > Is this expected to work that way? Is a bug on the TCK and implementations? Any other way to achieve my goal? > > > Regards, > Guillermo Gonz?lez de Ag?ero > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Apr 24 07:46:00 2017 From: issues at jboss.org (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero_=28JIRA=29?=) Date: Mon, 24 Apr 2017 07:46:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-701) Should addSterotype trigger discovery of new annotated types? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13396997#comment-13396997 ] Guillermo Gonz?lez de Ag?ero commented on CDI-701: -------------------------------------------------- Thanks everyone for so fast respones! [~manovotn] my original conclusion was exactly that (feature not supported by spec). Maybe the spec could incorporate a note regarding this, saying "Implementations are NOT MANDATED to treat stereotypes added by this method as bean defining annotations. Implementations are ALLOWED to do it in a non portable manner". That would clarify the situation and avoid confusions. A way to add annotations to the set of "bean defining annotations" was what I was really looking for. I just wanted to clarify that the addStereotype() was not the way to go before creating a feature request. Has that been already discussed in the past? > Should addSterotype trigger discovery of new annotated types? > ------------------------------------------------------------- > > Key: CDI-701 > URL: https://issues.jboss.org/browse/CDI-701 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Guillermo Gonz?lez de Ag?ero > > I've tried to post this question to the mailing list multiple times without success, so I fill an issue for it. > I'm adding some annotations as stereotypes via an extension, with the purpose of converting into beans any classes annotated with them (JAX-RS resources in my specific case). What I'm facing is that classes with that annotations are still only discovered if they were to be discovered before. So when using discovery-mode="annotated", my JAX-RS resources are not passed to the @ProcessAnnotatedType event. > WildFly automatically converts JAX-RS resources into @RequestScoped CDI beans, but looking at the code I saw it does that dealing directly with Weld APIs at server level, not on a portable manner at RESTEasy level. > I haven't found any mention in the spec that my approach wouldn't work, but the TCK doesn't address this usecase, which makes me think it's not supported. > Could you please clarify me the situation? Could this me changed on a future version? > And the original email I sent: > {quote} > Hi, > > I have a question about the behavior of the "BeforeBeanDiscovery#add*()" methods. > > My usecase is the following: I'd want to convert all JAX-RS resources into CDI beans. That resources are all annotated with @Path. My understanding was that converting that annotation into a stereotype would make them eligible as bean types. > > Since I can't modify that annotation, I just created an extension that observes the BeforeBeanDiscovery event and converts @Path into a stereotype associated with the @RequestScoped annotation. But it doesn't work, neither on Weld nor on OpenWebBeans. The class is not discovered on the next ProcessAnnotatedType event. > > I haven't found anything in the spec that explicitly says that a "runtime added" bean defining annotation makes clases eligible for discovery. But I think is makes sense. > > Checking the TCK, test org.jboss.cdi.tck.tests.extensions.stereotype.StereotypeExtensionTest tests that the addition of the stereotype works, but doesn't cover my case of adding a stereotype to a non bean class. > > Is this expected to work that way? Is a bug on the TCK and implementations? Any other way to achieve my goal? > > > Regards, > Guillermo Gonz?lez de Ag?ero > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Apr 24 08:00:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 24 Apr 2017 08:00:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-701) Should addSterotype trigger discovery of new annotated types? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13397018#comment-13397018 ] Matej Novotny commented on CDI-701: ----------------------------------- bq. That would clarify the situation and avoid confusions. Perhaps, but that would have to be added in 2.1 I think. You cannot expect a change to 1.2 spec at this point. bq. Has that been already discussed in the past? I don't recall a CDI issue regarding that. If you wish to see a non-portable Weld option working in CDI 1.2 (Weld 2.x), I think it would be proper to file a Weld feature request issue. > Should addSterotype trigger discovery of new annotated types? > ------------------------------------------------------------- > > Key: CDI-701 > URL: https://issues.jboss.org/browse/CDI-701 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Guillermo Gonz?lez de Ag?ero > > I've tried to post this question to the mailing list multiple times without success, so I fill an issue for it. > I'm adding some annotations as stereotypes via an extension, with the purpose of converting into beans any classes annotated with them (JAX-RS resources in my specific case). What I'm facing is that classes with that annotations are still only discovered if they were to be discovered before. So when using discovery-mode="annotated", my JAX-RS resources are not passed to the @ProcessAnnotatedType event. > WildFly automatically converts JAX-RS resources into @RequestScoped CDI beans, but looking at the code I saw it does that dealing directly with Weld APIs at server level, not on a portable manner at RESTEasy level. > I haven't found any mention in the spec that my approach wouldn't work, but the TCK doesn't address this usecase, which makes me think it's not supported. > Could you please clarify me the situation? Could this me changed on a future version? > And the original email I sent: > {quote} > Hi, > > I have a question about the behavior of the "BeforeBeanDiscovery#add*()" methods. > > My usecase is the following: I'd want to convert all JAX-RS resources into CDI beans. That resources are all annotated with @Path. My understanding was that converting that annotation into a stereotype would make them eligible as bean types. > > Since I can't modify that annotation, I just created an extension that observes the BeforeBeanDiscovery event and converts @Path into a stereotype associated with the @RequestScoped annotation. But it doesn't work, neither on Weld nor on OpenWebBeans. The class is not discovered on the next ProcessAnnotatedType event. > > I haven't found anything in the spec that explicitly says that a "runtime added" bean defining annotation makes clases eligible for discovery. But I think is makes sense. > > Checking the TCK, test org.jboss.cdi.tck.tests.extensions.stereotype.StereotypeExtensionTest tests that the addition of the stereotype works, but doesn't cover my case of adding a stereotype to a non bean class. > > Is this expected to work that way? Is a bug on the TCK and implementations? Any other way to achieve my goal? > > > Regards, > Guillermo Gonz?lez de Ag?ero > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Apr 24 09:33:00 2017 From: issues at jboss.org (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero_=28JIRA=29?=) Date: Mon, 24 Apr 2017 09:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-701) Should addSterotype trigger discovery of new annotated types? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13397114#comment-13397114 ] Guillermo Gonz?lez de Ag?ero commented on CDI-701: -------------------------------------------------- {quote} Perhaps, but that would have to be added in 2.1 I think. You cannot expect a change to 1.2 spec at this point. {quote} I'm fine with it being added to 2.1. I was searching for a standard way to do it in 1.2, but If that's not possible (as it seems to be the case), I understand it should be clarified on the next version. Regarding your idea about an API or SPI to add bean defining annotations, I guess that would need to work *before* any extensions are called, no? So it would only work when the user is responsible of bootstraping the container? Just trying to understand before going further. Please let me know if this is not the place to ask for it. Thanks! > Should addSterotype trigger discovery of new annotated types? > ------------------------------------------------------------- > > Key: CDI-701 > URL: https://issues.jboss.org/browse/CDI-701 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Guillermo Gonz?lez de Ag?ero > > I've tried to post this question to the mailing list multiple times without success, so I fill an issue for it. > I'm adding some annotations as stereotypes via an extension, with the purpose of converting into beans any classes annotated with them (JAX-RS resources in my specific case). What I'm facing is that classes with that annotations are still only discovered if they were to be discovered before. So when using discovery-mode="annotated", my JAX-RS resources are not passed to the @ProcessAnnotatedType event. > WildFly automatically converts JAX-RS resources into @RequestScoped CDI beans, but looking at the code I saw it does that dealing directly with Weld APIs at server level, not on a portable manner at RESTEasy level. > I haven't found any mention in the spec that my approach wouldn't work, but the TCK doesn't address this usecase, which makes me think it's not supported. > Could you please clarify me the situation? Could this me changed on a future version? > And the original email I sent: > {quote} > Hi, > > I have a question about the behavior of the "BeforeBeanDiscovery#add*()" methods. > > My usecase is the following: I'd want to convert all JAX-RS resources into CDI beans. That resources are all annotated with @Path. My understanding was that converting that annotation into a stereotype would make them eligible as bean types. > > Since I can't modify that annotation, I just created an extension that observes the BeforeBeanDiscovery event and converts @Path into a stereotype associated with the @RequestScoped annotation. But it doesn't work, neither on Weld nor on OpenWebBeans. The class is not discovered on the next ProcessAnnotatedType event. > > I haven't found anything in the spec that explicitly says that a "runtime added" bean defining annotation makes clases eligible for discovery. But I think is makes sense. > > Checking the TCK, test org.jboss.cdi.tck.tests.extensions.stereotype.StereotypeExtensionTest tests that the addition of the stereotype works, but doesn't cover my case of adding a stereotype to a non bean class. > > Is this expected to work that way? Is a bug on the TCK and implementations? Any other way to achieve my goal? > > > Regards, > Guillermo Gonz?lez de Ag?ero > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Apr 24 09:40:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 24 Apr 2017 09:40:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-701) Should addSterotype trigger discovery of new annotated types? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13397122#comment-13397122 ] Antoine Sabot-Durand commented on CDI-701: ------------------------------------------ Thank you for your feedback [~ggam]. As you can see in CDI-377 we had some issue in the past with BDA, but as others said we didn't discuss about BDA added at runtime. We'll definitely try to clarify this for CDI 2.1 or see if we can this support at spec level. > Should addSterotype trigger discovery of new annotated types? > ------------------------------------------------------------- > > Key: CDI-701 > URL: https://issues.jboss.org/browse/CDI-701 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Guillermo Gonz?lez de Ag?ero > > I've tried to post this question to the mailing list multiple times without success, so I fill an issue for it. > I'm adding some annotations as stereotypes via an extension, with the purpose of converting into beans any classes annotated with them (JAX-RS resources in my specific case). What I'm facing is that classes with that annotations are still only discovered if they were to be discovered before. So when using discovery-mode="annotated", my JAX-RS resources are not passed to the @ProcessAnnotatedType event. > WildFly automatically converts JAX-RS resources into @RequestScoped CDI beans, but looking at the code I saw it does that dealing directly with Weld APIs at server level, not on a portable manner at RESTEasy level. > I haven't found any mention in the spec that my approach wouldn't work, but the TCK doesn't address this usecase, which makes me think it's not supported. > Could you please clarify me the situation? Could this me changed on a future version? > And the original email I sent: > {quote} > Hi, > > I have a question about the behavior of the "BeforeBeanDiscovery#add*()" methods. > > My usecase is the following: I'd want to convert all JAX-RS resources into CDI beans. That resources are all annotated with @Path. My understanding was that converting that annotation into a stereotype would make them eligible as bean types. > > Since I can't modify that annotation, I just created an extension that observes the BeforeBeanDiscovery event and converts @Path into a stereotype associated with the @RequestScoped annotation. But it doesn't work, neither on Weld nor on OpenWebBeans. The class is not discovered on the next ProcessAnnotatedType event. > > I haven't found anything in the spec that explicitly says that a "runtime added" bean defining annotation makes clases eligible for discovery. But I think is makes sense. > > Checking the TCK, test org.jboss.cdi.tck.tests.extensions.stereotype.StereotypeExtensionTest tests that the addition of the stereotype works, but doesn't cover my case of adding a stereotype to a non bean class. > > Is this expected to work that way? Is a bug on the TCK and implementations? Any other way to achieve my goal? > > > Regards, > Guillermo Gonz?lez de Ag?ero > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Apr 24 09:41:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 24 Apr 2017 09:41:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-701) Should addSterotype trigger discovery of new annotated types? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-701: ------------------------------------- Fix Version/s: 2.1 (Discussion) > Should addSterotype trigger discovery of new annotated types? > ------------------------------------------------------------- > > Key: CDI-701 > URL: https://issues.jboss.org/browse/CDI-701 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Guillermo Gonz?lez de Ag?ero > Fix For: 2.1 (Discussion) > > > I've tried to post this question to the mailing list multiple times without success, so I fill an issue for it. > I'm adding some annotations as stereotypes via an extension, with the purpose of converting into beans any classes annotated with them (JAX-RS resources in my specific case). What I'm facing is that classes with that annotations are still only discovered if they were to be discovered before. So when using discovery-mode="annotated", my JAX-RS resources are not passed to the @ProcessAnnotatedType event. > WildFly automatically converts JAX-RS resources into @RequestScoped CDI beans, but looking at the code I saw it does that dealing directly with Weld APIs at server level, not on a portable manner at RESTEasy level. > I haven't found any mention in the spec that my approach wouldn't work, but the TCK doesn't address this usecase, which makes me think it's not supported. > Could you please clarify me the situation? Could this me changed on a future version? > And the original email I sent: > {quote} > Hi, > > I have a question about the behavior of the "BeforeBeanDiscovery#add*()" methods. > > My usecase is the following: I'd want to convert all JAX-RS resources into CDI beans. That resources are all annotated with @Path. My understanding was that converting that annotation into a stereotype would make them eligible as bean types. > > Since I can't modify that annotation, I just created an extension that observes the BeforeBeanDiscovery event and converts @Path into a stereotype associated with the @RequestScoped annotation. But it doesn't work, neither on Weld nor on OpenWebBeans. The class is not discovered on the next ProcessAnnotatedType event. > > I haven't found anything in the spec that explicitly says that a "runtime added" bean defining annotation makes clases eligible for discovery. But I think is makes sense. > > Checking the TCK, test org.jboss.cdi.tck.tests.extensions.stereotype.StereotypeExtensionTest tests that the addition of the stereotype works, but doesn't cover my case of adding a stereotype to a non bean class. > > Is this expected to work that way? Is a bug on the TCK and implementations? Any other way to achieve my goal? > > > Regards, > Guillermo Gonz?lez de Ag?ero > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Apr 24 09:49:02 2017 From: issues at jboss.org (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero_=28JIRA=29?=) Date: Mon, 24 Apr 2017 09:49:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-701) Should addSterotype trigger discovery of new annotated types? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13397139#comment-13397139 ] Guillermo Gonz?lez de Ag?ero commented on CDI-701: -------------------------------------------------- Thanks [~antoinesabot-durand]! Really appreciated. > Should addSterotype trigger discovery of new annotated types? > ------------------------------------------------------------- > > Key: CDI-701 > URL: https://issues.jboss.org/browse/CDI-701 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Guillermo Gonz?lez de Ag?ero > Fix For: 2.1 (Discussion) > > > I've tried to post this question to the mailing list multiple times without success, so I fill an issue for it. > I'm adding some annotations as stereotypes via an extension, with the purpose of converting into beans any classes annotated with them (JAX-RS resources in my specific case). What I'm facing is that classes with that annotations are still only discovered if they were to be discovered before. So when using discovery-mode="annotated", my JAX-RS resources are not passed to the @ProcessAnnotatedType event. > WildFly automatically converts JAX-RS resources into @RequestScoped CDI beans, but looking at the code I saw it does that dealing directly with Weld APIs at server level, not on a portable manner at RESTEasy level. > I haven't found any mention in the spec that my approach wouldn't work, but the TCK doesn't address this usecase, which makes me think it's not supported. > Could you please clarify me the situation? Could this me changed on a future version? > And the original email I sent: > {quote} > Hi, > > I have a question about the behavior of the "BeforeBeanDiscovery#add*()" methods. > > My usecase is the following: I'd want to convert all JAX-RS resources into CDI beans. That resources are all annotated with @Path. My understanding was that converting that annotation into a stereotype would make them eligible as bean types. > > Since I can't modify that annotation, I just created an extension that observes the BeforeBeanDiscovery event and converts @Path into a stereotype associated with the @RequestScoped annotation. But it doesn't work, neither on Weld nor on OpenWebBeans. The class is not discovered on the next ProcessAnnotatedType event. > > I haven't found anything in the spec that explicitly says that a "runtime added" bean defining annotation makes clases eligible for discovery. But I think is makes sense. > > Checking the TCK, test org.jboss.cdi.tck.tests.extensions.stereotype.StereotypeExtensionTest tests that the addition of the stereotype works, but doesn't cover my case of adding a stereotype to a non bean class. > > Is this expected to work that way? Is a bug on the TCK and implementations? Any other way to achieve my goal? > > > Regards, > Guillermo Gonz?lez de Ag?ero > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From antoine at sabot-durand.net Wed Apr 26 05:03:35 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 26 Apr 2017 09:03:35 +0000 Subject: [cdi-dev] CDI 2.0 is now in final approval ballot Message-ID: Hi all, Just to let you know that the final release is coming: we reached the final approval ballot. https://jcp.org/en/jsr/detail?id=365 Thanks for the great work! Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/43371ad3/attachment.html From issues at jboss.org Wed Apr 26 08:56:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 26 Apr 2017 08:56:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-701) Should addSterotype trigger discovery of new annotated types? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398406#comment-13398406 ] Matej Novotny commented on CDI-701: ----------------------------------- bq. Regarding your idea about an API or SPI to add bean defining annotations, I guess that would need to work before any extensions are called, no? More or less yes. As it turns out, there are some chicken-egg problems around this. So ATM the only viable option would be something static, existing before CDI even tries to bootstrap. E.g. define this inside {{beans.xml}} for instance (but then again,while I think this would be ok as Weld configuration, I am not sure it's good to define in on spec level). bq. So it would only work when the user is responsible of bootstraping the container? If you had this level of control, you could "easily" expand the set of BDA. But from CDI spec perspective, this is a blind end I think. > Should addSterotype trigger discovery of new annotated types? > ------------------------------------------------------------- > > Key: CDI-701 > URL: https://issues.jboss.org/browse/CDI-701 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Guillermo Gonz?lez de Ag?ero > Fix For: 2.1 (Discussion) > > > I've tried to post this question to the mailing list multiple times without success, so I fill an issue for it. > I'm adding some annotations as stereotypes via an extension, with the purpose of converting into beans any classes annotated with them (JAX-RS resources in my specific case). What I'm facing is that classes with that annotations are still only discovered if they were to be discovered before. So when using discovery-mode="annotated", my JAX-RS resources are not passed to the @ProcessAnnotatedType event. > WildFly automatically converts JAX-RS resources into @RequestScoped CDI beans, but looking at the code I saw it does that dealing directly with Weld APIs at server level, not on a portable manner at RESTEasy level. > I haven't found any mention in the spec that my approach wouldn't work, but the TCK doesn't address this usecase, which makes me think it's not supported. > Could you please clarify me the situation? Could this me changed on a future version? > And the original email I sent: > {quote} > Hi, > > I have a question about the behavior of the "BeforeBeanDiscovery#add*()" methods. > > My usecase is the following: I'd want to convert all JAX-RS resources into CDI beans. That resources are all annotated with @Path. My understanding was that converting that annotation into a stereotype would make them eligible as bean types. > > Since I can't modify that annotation, I just created an extension that observes the BeforeBeanDiscovery event and converts @Path into a stereotype associated with the @RequestScoped annotation. But it doesn't work, neither on Weld nor on OpenWebBeans. The class is not discovered on the next ProcessAnnotatedType event. > > I haven't found anything in the spec that explicitly says that a "runtime added" bean defining annotation makes clases eligible for discovery. But I think is makes sense. > > Checking the TCK, test org.jboss.cdi.tck.tests.extensions.stereotype.StereotypeExtensionTest tests that the addition of the stereotype works, but doesn't cover my case of adding a stereotype to a non bean class. > > Is this expected to work that way? Is a bug on the TCK and implementations? Any other way to achieve my goal? > > > Regards, > Guillermo Gonz?lez de Ag?ero > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From john.ament at spartasystems.com Wed Apr 26 09:54:57 2017 From: john.ament at spartasystems.com (John Ament) Date: Wed, 26 Apr 2017 13:54:57 +0000 Subject: [cdi-dev] Types of Principal object Message-ID: 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.html From rmannibucau at gmail.com Wed Apr 26 10:38:01 2017 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 26 Apr 2017 16:38:01 +0200 Subject: [cdi-dev] Types of Principal object In-Reply-To: References: Message-ID: 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 | Blog | Old Blog | Github | LinkedIn | JavaEE Factory 2017-04-26 15:54 GMT+02:00 John Ament : > 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/20170426/19976ebd/attachment.html From manovotn at redhat.com Wed Apr 26 10:48:40 2017 From: manovotn at redhat.com (Matej Novotny) Date: Wed, 26 Apr 2017 10:48:40 -0400 (EDT) Subject: [cdi-dev] Types of Principal object In-Reply-To: References: Message-ID: <1098875365.1348630.1493218120014.JavaMail.zimbra@redhat.com> 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" > To: "cdi-dev" > 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. From arjan.tijms at gmail.com Wed Apr 26 11:11:11 2017 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 26 Apr 2017 17:11:11 +0200 Subject: [cdi-dev] Types of Principal object In-Reply-To: References: Message-ID: 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 extends AbstractStaticallyDecorableBuiltInBean { private final T proxy; protected AbstractEEBean(Class type, Callable callable, BeanManagerImpl beanManager) { super(beanManager, type); this.proxy = new ProxyFactory(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 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/20170426/206ff811/attachment-0001.html From arjan.tijms at gmail.com Wed Apr 26 11:14:03 2017 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 26 Apr 2017 17:14:03 +0200 Subject: [cdi-dev] Types of Principal object In-Reply-To: References: Message-ID: P.s. slightly offtopic for CDI spec itself, but: A small workaround is to @Inject SecurityContext context; and then: MyPrincipal principal = (MyPrincipal ) context.getCallerPrincipal(); Thinking of it, maybe I can make the getCallerPrincipal() a generic method, so one can do: MyPrincipal principal = context.getCallerPrincipal(); Kind regards, Arjan Tijms On Wed, Apr 26, 2017 at 4:38 PM, Romain Manni-Bucau wrote: > 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 | Blog > | Old Blog > | Github > | LinkedIn > | JavaEE Factory > > > 2017-04-26 15:54 GMT+02:00 John Ament : > >> 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/f67603d3/attachment.html From rmannibucau at gmail.com Wed Apr 26 11:21:23 2017 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 26 Apr 2017 17:21:23 +0200 Subject: [cdi-dev] Types of Principal object In-Reply-To: References: Message-ID: Doesnt have to work, works recently with tomcat cause was poorly usable but you can still get a "limited" Principal doing that :( Only portable working case i saw was a filter wrapping the request and overriding the get principal method but you need to access the *right* request Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory 2017-04-26 17:14 GMT+02:00 arjan tijms : > P.s. slightly offtopic for CDI spec itself, but: > > A small workaround is to @Inject SecurityContext context; and then: > > MyPrincipal principal = (MyPrincipal ) context.getCallerPrincipal(); > > Thinking of it, maybe I can make the getCallerPrincipal() a generic > method, so one can do: > > MyPrincipal principal = context.getCallerPrincipal(); > > Kind regards, > Arjan Tijms > > > > > > > On Wed, Apr 26, 2017 at 4:38 PM, Romain Manni-Bucau > wrote: > >> 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 | Blog >> | Old Blog >> | Github >> | LinkedIn >> | JavaEE Factory >> >> >> 2017-04-26 15:54 GMT+02:00 John Ament : >> >>> 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/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/479fcb38/attachment.html From werner.keil at gmail.com Wed Apr 26 11:41:12 2017 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 26 Apr 2017 17:41:12 +0200 Subject: [cdi-dev] cdi-dev Digest, Vol 77, Issue 8 In-Reply-To: References: Message-ID: We had similar challenges and discussions even before JSR 363 about knowing what type of quantity you're dealing with types like Unit> 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, 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 > Subject: [cdi-dev] Types of Principal object > To: cdi-dev > Message-ID: > namprd04.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/ > 20170426/b6740722/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Wed, 26 Apr 2017 16:38:01 +0200 > From: Romain Manni-Bucau > Subject: Re: [cdi-dev] Types of Principal object > To: John Ament > Cc: cdi-dev > Message-ID: > gmail.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 | Blog > | Old Blog > | Github rmannibucau> | > LinkedIn | JavaEE Factory > > > 2017-04-26 15:54 GMT+02:00 John Ament : > > > 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/ > 20170426/19976ebd/attachment-0001.html > > ------------------------------ > > Message: 3 > Date: Wed, 26 Apr 2017 10:48:40 -0400 (EDT) > From: Matej Novotny > Subject: Re: [cdi-dev] Types of Principal object > To: John Ament > Cc: cdi-dev > 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" > > To: "cdi-dev" > > 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 > Subject: Re: [cdi-dev] Types of Principal object > To: John Ament > Cc: cdi-dev > Message-ID: > 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 extends > AbstractStaticallyDecorableBuiltInBean { > > private final T proxy; > > protected AbstractEEBean(Class type, Callable callable, > BeanManagerImpl beanManager) { > super(beanManager, type); > this.proxy = new ProxyFactory(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 > 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/ > 20170426/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/ > 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 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/1cd1b187/attachment-0001.html From rmannibucau at gmail.com Wed Apr 26 11:41:08 2017 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 26 Apr 2017 17:41:08 +0200 Subject: [cdi-dev] Types of Principal object In-Reply-To: References: Message-ID: 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 | Blog | Old Blog | Github | LinkedIn | JavaEE Factory 2017-04-26 17:11 GMT+02:00 arjan tijms : > 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 extends > AbstractStaticallyDecorableBuiltInBean { > > private final T proxy; > > protected AbstractEEBean(Class type, Callable callable, > BeanManagerImpl beanManager) { > super(beanManager, type); > this.proxy = new ProxyFactory(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 > 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.html From werner.keil at gmail.com Wed Apr 26 11:44:04 2017 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 26 Apr 2017 17:44:04 +0200 Subject: [cdi-dev] Types of Principal object Message-ID: 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 wrote: > We had similar challenges and discussions even before JSR 363 about > knowing what type of quantity you're dealing with types like > > Unit> > > 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, 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 >> Subject: [cdi-dev] Types of Principal object >> To: cdi-dev >> Message-ID: >> > 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 >> Subject: Re: [cdi-dev] Types of Principal object >> To: John Ament >> Cc: cdi-dev >> Message-ID: >> > 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 | Blog >> | Old Blog >> | Github < >> https://github.com/rmannibucau> | >> LinkedIn | JavaEE Factory >> >> >> 2017-04-26 15:54 GMT+02:00 John Ament : >> >> > 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 >> Subject: Re: [cdi-dev] Types of Principal object >> To: John Ament >> Cc: cdi-dev >> 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" >> > To: "cdi-dev" >> > 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 >> Subject: Re: [cdi-dev] Types of Principal object >> To: John Ament >> Cc: cdi-dev >> Message-ID: >> > 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 extends >> AbstractStaticallyDecorableBuiltInBean { >> >> private final T proxy; >> >> protected AbstractEEBean(Class type, Callable callable, >> BeanManagerImpl beanManager) { >> super(beanManager, type); >> this.proxy = new ProxyFactory(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 > > >> 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-0001.html From arjan.tijms at gmail.com Wed Apr 26 12:00:40 2017 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 26 Apr 2017 18:00:40 +0200 Subject: [cdi-dev] Types of Principal object In-Reply-To: <1098875365.1348630.1493218120014.JavaMail.zimbra@redhat.com> References: <1098875365.1348630.1493218120014.JavaMail.zimbra@redhat.com> Message-ID: Hi, On Wed, Apr 26, 2017 at 4:48 PM, Matej Novotny wrote: > 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?). > That would be kinda disputable indeed :O > Therefore, it is safer/viable to create a proxyable wrapper object which > implements Principal only and delegetas calls (that's what Weld does). > As i mentioned, the proxy has to be there as just injecting a non-proxy Principal would not work correctly. If a logout call is done, the injected Principal would still be the principal that it was before, let alone what happens if the Principal is inject in application scoped beans... Kind regards, Arjan Tijms > > 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" > > To: "cdi-dev" > > 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. > _______________________________________________ > 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/1b8d735a/attachment.html From arjan.tijms at gmail.com Wed Apr 26 12:07:52 2017 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 26 Apr 2017 18:07:52 +0200 Subject: [cdi-dev] Types of Principal object In-Reply-To: References: Message-ID: Hi, On Wed, Apr 26, 2017 at 5:41 PM, Romain Manni-Bucau wrote: > 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) > I think that would require a new Principal type, which can be done, but who's going to put time into it to discuss it, spec it, implement it, etc? Also, the difference with the current situation is not that much then. Extended Principal: @Inject CallerPrincipal callerPrincipal; ... MyPrincipal myPrincipal = callerPrincipal.unwrap(); vs Security context: @Inject SecurityContext securityContext; ... MyPrincipal myPrincipal = securityContext.getCallerPrincipal(); Spot the differences ;) > In other words either Principal is removed from CDI spec > I think this should be done anyway. The build-in bean for Principal would be more at home with the Security API spec. I would be happy to take it in ;) (likewise, the build-in bean for HttpServletRequest etc should be with the Servlet spec) > or it stays but it should be extended to be made usable IMHO. > What CDI could provide and which has been discussed before, is a method to get the real bean from a proxy. E.g. @Inject CallerPrincipal callerPrincipal; @Inject BeanManager beanManager; ... MyPrincipal myPrincipal = beanManager.unwrap(callerPrincipal); Kind regards, Arjan Tijms > > > Romain Manni-Bucau > @rmannibucau | Blog > | Old Blog > | Github > | LinkedIn > | JavaEE Factory > > > 2017-04-26 17:11 GMT+02:00 arjan tijms : > >> 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 extends >> AbstractStaticallyDecorableBuiltInBean { >> >> private final T proxy; >> >> protected AbstractEEBean(Class type, Callable callable, >> BeanManagerImpl beanManager) { >> super(beanManager, type); >> this.proxy = new ProxyFactory(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 > > 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/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/9cd63650/attachment.html From rmannibucau at gmail.com Wed Apr 26 12:10:10 2017 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 26 Apr 2017 18:10:10 +0200 Subject: [cdi-dev] Types of Principal object In-Reply-To: References: Message-ID: 2017-04-26 18:07 GMT+02:00 arjan tijms : > Hi, > > On Wed, Apr 26, 2017 at 5:41 PM, Romain Manni-Bucau > wrote: > >> 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) >> > > I think that would require a new Principal type, which can be done, but > who's going to put time into it to discuss it, spec it, implement it, etc? > > Also, the difference with the current situation is not that much then. > > Extended Principal: > > > @Inject CallerPrincipal callerPrincipal; > > ... > > MyPrincipal myPrincipal = callerPrincipal.unwrap(); > Was more thinking about: MyPrincipal myPrincipal = callerPrincipal.unwrap(MyPrincipal.class); > > > vs > > > Security context: > > @Inject SecurityContext securityContext; > > ... > > MyPrincipal myPrincipal = securityContext.getCallerPrincipal(); > > Spot the differences ;) > Here you can get a PrincipalFacade which limits MyPrincipal to getName() only, this is perfectly valid per spec. > > > >> In other words either Principal is removed from CDI spec >> > > I think this should be done anyway. The build-in bean for Principal would > be more at home with the Security API spec. I would be happy to take it in > ;) > > (likewise, the build-in bean for HttpServletRequest etc should be with the > Servlet spec) > > > >> or it stays but it should be extended to be made usable IMHO. >> > > What CDI could provide and which has been discussed before, is a method to > get the real bean from a proxy. E.g. > > @Inject CallerPrincipal callerPrincipal; > @Inject BeanManager beanManager; > > ... > > MyPrincipal myPrincipal = beanManager.unwrap(callerPrincipal); > Well this would assume we can do it for all beans and a lot of cases would be problematic cause it is just not doable :s...but would help if we find a compromise for other beans too :) > > Kind regards, > Arjan Tijms > > > > > > > >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Old Blog >> | Github >> | LinkedIn >> | JavaEE Factory >> >> >> 2017-04-26 17:11 GMT+02:00 arjan tijms : >> >>> 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 extends >>> AbstractStaticallyDecorableBuiltInBean { >>> >>> private final T proxy; >>> >>> protected AbstractEEBean(Class type, Callable callable, >>> BeanManagerImpl beanManager) { >>> super(beanManager, type); >>> this.proxy = new ProxyFactory(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/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/1afdba6f/attachment-0001.html From werner.keil at gmail.com Wed Apr 26 12:14:10 2017 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 26 Apr 2017 18:14:10 +0200 Subject: [cdi-dev] Types of Principal object Message-ID: 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 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 or a StringBean extends AbstractBuiltInBean 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" 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, 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 > Subject: Re: [cdi-dev] Types of Principal object > To: arjan tijms > Cc: cdi-dev > Message-ID: > 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 | Blog > | Old Blog > | Github rmannibucau> | > LinkedIn | JavaEE Factory > > > 2017-04-26 17:11 GMT+02:00 arjan tijms : > > > 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 extends > > AbstractStaticallyDecorableBuiltInBean { > > > > private final T proxy; > > > > protected AbstractEEBean(Class type, Callable callable, > > BeanManagerImpl beanManager) { > > super(beanManager, type); > > this.proxy = new ProxyFactory(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 > Subject: Re: [cdi-dev] Types of Principal object > To: cdi-dev > Message-ID: > 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 > wrote: > > > We had similar challenges and discussions even before JSR 363 about > > knowing what type of quantity you're dealing with types like > > > > Unit github.io/unit-api/site/apidocs/javax/measure/Quantity.html>> > > > > 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, > 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 > >> Subject: [cdi-dev] Types of Principal object > >> To: cdi-dev > >> Message-ID: > >> >> 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 > >> Subject: Re: [cdi-dev] Types of Principal object > >> To: John Ament > >> Cc: cdi-dev > >> Message-ID: > >> >> 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 | Blog > >> | Old Blog > >> | Github < > >> https://github.com/rmannibucau> | > >> LinkedIn | JavaEE Factory > >> > >> > >> 2017-04-26 15:54 GMT+02:00 John Ament : > >> > >> > 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 > >> Subject: Re: [cdi-dev] Types of Principal object > >> To: John Ament > >> Cc: cdi-dev > >> 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" > >> > To: "cdi-dev" > >> > 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 > >> Subject: Re: [cdi-dev] Types of Principal object > >> To: John Ament > >> Cc: cdi-dev > >> Message-ID: > >> >> 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 extends > >> AbstractStaticallyDecorableBuiltInBean { > >> > >> private final T proxy; > >> > >> protected AbstractEEBean(Class type, Callable callable, > >> BeanManagerImpl beanManager) { > >> super(beanManager, type); > >> this.proxy = new ProxyFactory(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 From werner.keil at gmail.com Wed Apr 26 12:17:30 2017 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 26 Apr 2017 18:17:30 +0200 Subject: [cdi-dev] Types of Principal object Message-ID: Btw. I think some aspects of this thread seem a little off-topic or more specific to the JSR 375 list instead (or at least it would be good to CC that one for detailed java.security discussions rather than if a generic type works or not) Werner On Wed, Apr 26, 2017 at 6:11 PM, 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 (arjan tijms) > 2. Re: Types of Principal object (arjan tijms) > 3. Re: Types of Principal object (Romain Manni-Bucau) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 26 Apr 2017 18:00:40 +0200 > From: arjan tijms > Subject: Re: [cdi-dev] Types of Principal object > To: Matej Novotny > Cc: cdi-dev > Message-ID: > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > On Wed, Apr 26, 2017 at 4:48 PM, Matej Novotny > wrote: > > > 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?). > > > > That would be kinda disputable indeed :O > > > > Therefore, it is safer/viable to create a proxyable wrapper object which > > implements Principal only and delegetas calls (that's what Weld does). > > > > As i mentioned, the proxy has to be there as just injecting a non-proxy > Principal would not work correctly. If a logout call is done, the injected > Principal would still be the principal that it was before, let alone what > happens if the Principal is inject in application scoped beans... > > Kind regards, > Arjan Tijms > > > > > > > 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" > > > To: "cdi-dev" > > > 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. > > _______________________________________________ > > 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/1b8d735a/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Wed, 26 Apr 2017 18:07:52 +0200 > From: arjan tijms > Subject: Re: [cdi-dev] Types of Principal object > To: Romain Manni-Bucau > Cc: cdi-dev > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > On Wed, Apr 26, 2017 at 5:41 PM, Romain Manni-Bucau > > wrote: > > > 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) > > > > I think that would require a new Principal type, which can be done, but > who's going to put time into it to discuss it, spec it, implement it, etc? > > Also, the difference with the current situation is not that much then. > > Extended Principal: > > > @Inject CallerPrincipal callerPrincipal; > > ... > > MyPrincipal myPrincipal = callerPrincipal.unwrap(); > > > vs > > > Security context: > > @Inject SecurityContext securityContext; > > ... > > MyPrincipal myPrincipal = securityContext.getCallerPrincipal(); > > Spot the differences ;) > > > > > In other words either Principal is removed from CDI spec > > > > I think this should be done anyway. The build-in bean for Principal would > be more at home with the Security API spec. I would be happy to take it in > ;) > > (likewise, the build-in bean for HttpServletRequest etc should be with the > Servlet spec) > > > > > or it stays but it should be extended to be made usable IMHO. > > > > What CDI could provide and which has been discussed before, is a method to > get the real bean from a proxy. E.g. > > @Inject CallerPrincipal callerPrincipal; > @Inject BeanManager beanManager; > > ... > > MyPrincipal myPrincipal = beanManager.unwrap(callerPrincipal); > > Kind regards, > Arjan Tijms > > > > > > > > > > > > > Romain Manni-Bucau > > @rmannibucau | Blog > > | Old Blog > > | Github > > | LinkedIn > > | JavaEE Factory > > > > > > 2017-04-26 17:11 GMT+02:00 arjan tijms : > > > >> 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 extends > >> AbstractStaticallyDecorableBuiltInBean { > >> > >> private final T proxy; > >> > >> protected AbstractEEBean(Class type, Callable callable, > >> BeanManagerImpl beanManager) { > >> super(beanManager, type); > >> this.proxy = new ProxyFactory(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/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/9cd63650/attachment-0001.html > > ------------------------------ > > Message: 3 > Date: Wed, 26 Apr 2017 18:10:10 +0200 > From: Romain Manni-Bucau > Subject: Re: [cdi-dev] Types of Principal object > To: arjan tijms > Cc: cdi-dev > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > 2017-04-26 18:07 GMT+02:00 arjan tijms : > > > Hi, > > > > On Wed, Apr 26, 2017 at 5:41 PM, Romain Manni-Bucau < > rmannibucau at gmail.com > > > wrote: > > > >> 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) > >> > > > > I think that would require a new Principal type, which can be done, but > > who's going to put time into it to discuss it, spec it, implement it, > etc? > > > > Also, the difference with the current situation is not that much then. > > > > Extended Principal: > > > > > > @Inject CallerPrincipal callerPrincipal; > > > > ... > > > > MyPrincipal myPrincipal = callerPrincipal.unwrap(); > > > > Was more thinking about: > > MyPrincipal myPrincipal = callerPrincipal.unwrap(MyPrincipal.class); > > > > > > > > vs > > > > > > Security context: > > > > @Inject SecurityContext securityContext; > > > > ... > > > > MyPrincipal myPrincipal = securityContext.getCallerPrincipal(); > > > > Spot the differences ;) > > > > Here you can get a PrincipalFacade which limits MyPrincipal to getName() > only, this is perfectly valid per spec. > > > > > > > > > >> In other words either Principal is removed from CDI spec > >> > > > > I think this should be done anyway. The build-in bean for Principal would > > be more at home with the Security API spec. I would be happy to take it > in > > ;) > > > > (likewise, the build-in bean for HttpServletRequest etc should be with > the > > Servlet spec) > > > > > > > >> or it stays but it should be extended to be made usable IMHO. > >> > > > > What CDI could provide and which has been discussed before, is a method > to > > get the real bean from a proxy. E.g. > > > > @Inject CallerPrincipal callerPrincipal; > > @Inject BeanManager beanManager; > > > > ... > > > > MyPrincipal myPrincipal = beanManager.unwrap(callerPrincipal); > > > > Well this would assume we can do it for all beans and a lot of cases would > be problematic cause it is just not doable :s...but would help if we find a > compromise for other beans too :) > > > > > > Kind regards, > > Arjan Tijms > > > > > > > > > > > > > > > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau | Blog > >> | Old Blog > >> | Github > >> | LinkedIn > >> | JavaEE Factory > >> > >> > >> 2017-04-26 17:11 GMT+02:00 arjan tijms : > >> > >>> 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 extends > >>> AbstractStaticallyDecorableBuiltInBean { > >>> > >>> private final T proxy; > >>> > >>> protected AbstractEEBean(Class type, Callable callable, > >>> BeanManagerImpl beanManager) { > >>> super(beanManager, type); > >>> this.proxy = new ProxyFactory(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/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/1afdba6f/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 11 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/34158090/attachment-0001.html From arjan.tijms at gmail.com Wed Apr 26 12:18:38 2017 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 26 Apr 2017 18:18:38 +0200 Subject: [cdi-dev] Types of Principal object In-Reply-To: References: Message-ID: Hi, On Wed, Apr 26, 2017 at 6:10 PM, Romain Manni-Bucau wrote: > > >> Security context: >> >> @Inject SecurityContext securityContext; >> >> ... >> >> MyPrincipal myPrincipal = securityContext.getCallerPrincipal(); >> >> Spot the differences ;) >> > > Here you can get a PrincipalFacade which limits MyPrincipal to getName() > only, this is perfectly valid per spec. > Nope, I spec'ed this such that securityContext.getCallerPrincipal() MUST return the *exact* principal type that was set by the authentication mechanism. If the code in the (user provided) authentication mechanism sets a MyPrincipal, then a MyPrincipal, and only a MyPrincipal must be returned. I'm going to push for a TCK test to be added for this (although I can't guarantee that as it's outside my influence, unfortunately). > > >> @Inject CallerPrincipal callerPrincipal; >> @Inject BeanManager beanManager; >> >> ... >> >> MyPrincipal myPrincipal = beanManager.unwrap(callerPrincipal); >> > > Well this would assume we can do it for all beans and a lot of cases would > be problematic cause it is just not doable :s...but would help if we find a > compromise for other beans too :) > Perhaps an exception could be thrown if not unwrappable, or an Optional could be returned that would be empty if not unwrappable, etc. Kind regards, Arjan Tijms > 2017-04-26 17:11 GMT+02:00 arjan tijms : >>> >>>> 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 extends >>>> AbstractStaticallyDecorableBuiltInBean { >>>> >>>> private final T proxy; >>>> >>>> protected AbstractEEBean(Class type, Callable callable, >>>> BeanManagerImpl beanManager) { >>>> super(beanManager, type); >>>> this.proxy = new ProxyFactory(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. >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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. >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/e1a96069/attachment.html From rmannibucau at gmail.com Wed Apr 26 12:19:57 2017 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 26 Apr 2017 18:19:57 +0200 Subject: [cdi-dev] Types of Principal object In-Reply-To: References: Message-ID: 2017-04-26 18:18 GMT+02:00 arjan tijms : > Hi, > > On Wed, Apr 26, 2017 at 6:10 PM, Romain Manni-Bucau > wrote: > >> >> >>> Security context: >>> >>> @Inject SecurityContext securityContext; >>> >>> ... >>> >>> MyPrincipal myPrincipal = securityContext.getCallerPrincipal(); >>> >>> Spot the differences ;) >>> >> >> Here you can get a PrincipalFacade which limits MyPrincipal to getName() >> only, this is perfectly valid per spec. >> > > Nope, I spec'ed this such that securityContext.getCallerPrincipal() MUST > return the *exact* principal type that was set by the authentication > mechanism. > Yep and my statement is still true. You can still wrap the context in a filter and break that so a user can't rely on it. > > If the code in the (user provided) authentication mechanism sets a > MyPrincipal, then a MyPrincipal, and only a MyPrincipal must be returned. > I'm going to push for a TCK test to be added for this (although I can't > guarantee that as it's outside my influence, unfortunately). > > > > > >> >> >>> @Inject CallerPrincipal callerPrincipal; >>> @Inject BeanManager beanManager; >>> >>> ... >>> >>> MyPrincipal myPrincipal = beanManager.unwrap(callerPrincipal); >>> >> >> Well this would assume we can do it for all beans and a lot of cases >> would be problematic cause it is just not doable :s...but would help if we >> find a compromise for other beans too :) >> > > Perhaps an exception could be thrown if not unwrappable, or an Optional > could be returned that would be empty if not unwrappable, etc. > Think in the related ticket point is exposing a method which would fail often is too risky > > Kind regards, > Arjan Tijms > > > >> 2017-04-26 17:11 GMT+02:00 arjan tijms : >>>> >>>>> 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 extends >>>>> AbstractStaticallyDecorableBuiltInBean { >>>>> >>>>> private final T proxy; >>>>> >>>>> protected AbstractEEBean(Class type, Callable callable, >>>>> BeanManagerImpl beanManager) { >>>>> super(beanManager, type); >>>>> this.proxy = new ProxyFactory(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. >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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/245a90ba/attachment-0001.html From arjan.tijms at gmail.com Wed Apr 26 12:28:37 2017 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 26 Apr 2017 18:28:37 +0200 Subject: [cdi-dev] Types of Principal object In-Reply-To: References: Message-ID: On Wed, Apr 26, 2017 at 6:19 PM, Romain Manni-Bucau wrote: > Here you can get a PrincipalFacade which limits MyPrincipal to getName() >>> only, this is perfectly valid per spec. >>> >> >> Nope, I spec'ed this such that securityContext.getCallerPrincipal() MUST >> return the *exact* principal type that was set by the authentication >> mechanism. >> > > Yep and my statement is still true. You can still wrap the context in a > filter and break that so a user can't rely on it. > I'm not sure if I understand that correctly. You can't really wrap the security context in a filter. The security context is a CDI bean, not an instance that's passed along from one filter to the other. You can decorate the context and then return whatever from the getCallerPrincipal() method, but that doesn't mean the original getCallerPrincipal() method doesn't return what it's spec'ed to return, is it? Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/c732897b/attachment.html From arjan.tijms at gmail.com Wed Apr 26 12:41:03 2017 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 26 Apr 2017 18:41:03 +0200 Subject: [cdi-dev] Types of Principal object In-Reply-To: References: Message-ID: Hi, On Wed, Apr 26, 2017 at 6:14 PM, Werner Keil 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 > I think what Romain intended here is that the build-in Bean 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.jboss.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 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 for each encountered type: https://github.com/omnifaces/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 > or a > StringBean extends AbstractBuiltInBean > > 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" > > 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, 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 >> Subject: Re: [cdi-dev] Types of Principal object >> To: arjan tijms >> Cc: cdi-dev >> Message-ID: >> > 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 | Blog >> | Old Blog >> | Github < >> https://github.com/rmannibucau> | >> LinkedIn | JavaEE Factory >> >> >> 2017-04-26 17:11 GMT+02:00 arjan tijms : >> >> > 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 extends >> > AbstractStaticallyDecorableBuiltInBean { >> > >> > private final T proxy; >> > >> > protected AbstractEEBean(Class type, Callable callable, >> > BeanManagerImpl beanManager) { >> > super(beanManager, type); >> > this.proxy = new ProxyFactory(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/2017042 >> 6/ad930662/attachment-0001.html >> >> ------------------------------ >> >> Message: 2 >> Date: Wed, 26 Apr 2017 17:44:04 +0200 >> From: Werner Keil >> Subject: Re: [cdi-dev] Types of Principal object >> To: cdi-dev >> Message-ID: >> > 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 >> wrote: >> >> > We had similar challenges and discussions even before JSR 363 about >> > knowing what type of quantity you're dealing with types like >> > >> > Unit> hub.io/unit-api/site/apidocs/javax/measure/Quantity.html>> >> > >> > 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, >> 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 >> >> Subject: [cdi-dev] Types of Principal object >> >> To: cdi-dev >> >> Message-ID: >> >> > >> 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 >> >> Subject: Re: [cdi-dev] Types of Principal object >> >> To: John Ament >> >> Cc: cdi-dev >> >> Message-ID: >> >> > >> 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 | Blog >> >> | Old Blog >> >> | Github < >> >> https://github.com/rmannibucau> | >> >> LinkedIn | JavaEE Factory >> >> >> >> >> >> 2017-04-26 15:54 GMT+02:00 John Ament : >> >> >> >> > 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 >> >> Subject: Re: [cdi-dev] Types of Principal object >> >> To: John Ament >> >> Cc: cdi-dev >> >> 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" >> >> > To: "cdi-dev" >> >> > 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 >> >> Subject: Re: [cdi-dev] Types of Principal object >> >> To: John Ament >> >> Cc: cdi-dev >> >> Message-ID: >> >> > >> 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 extends >> >> AbstractStaticallyDecorableBuiltInBean { >> >> >> >> private final T proxy; >> >> >> >> protected AbstractEEBean(Class type, Callable callable, >> >> BeanManagerImpl beanManager) { >> >> super(beanManager, type); >> >> this.proxy = new ProxyFactory(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/2017042 >> 6/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/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 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/f3eddf0e/attachment-0001.html From werner.keil at gmail.com Wed Apr 26 12:51:50 2017 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 26 Apr 2017 18:51:50 +0200 Subject: [cdi-dev] Types of Principal object Message-ID: 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 wrote: > Hi, > > On Wed, Apr 26, 2017 at 6:14 PM, Werner Keil > 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 >> > > I think what Romain intended here is that the build-in Bean 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. > jboss.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 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 for each encountered type: https://github.com/ > omnifaces/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 >> or a >> StringBean extends AbstractBuiltInBean >> >> 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" >> >> 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, 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 >>> Subject: Re: [cdi-dev] Types of Principal object >>> To: arjan tijms >>> Cc: cdi-dev >>> Message-ID: >>> >> 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 | Blog >>> | Old Blog >>> | Github < >>> https://github.com/rmannibucau> | >>> LinkedIn | JavaEE Factory >>> >>> >>> 2017-04-26 17:11 GMT+02:00 arjan tijms : >>> >>> > 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 extends >>> > AbstractStaticallyDecorableBuiltInBean { >>> > >>> > private final T proxy; >>> > >>> > protected AbstractEEBean(Class type, Callable callable, >>> > BeanManagerImpl beanManager) { >>> > super(beanManager, type); >>> > this.proxy = new ProxyFactory(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/2017042 >>> 6/ad930662/attachment-0001.html >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Wed, 26 Apr 2017 17:44:04 +0200 >>> From: Werner Keil >>> Subject: Re: [cdi-dev] Types of Principal object >>> To: cdi-dev >>> Message-ID: >>> >> 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 >>> wrote: >>> >>> > We had similar challenges and discussions even before JSR 363 about >>> > knowing what type of quantity you're dealing with types like >>> > >>> > Unit>> hub.io/unit-api/site/apidocs/javax/measure/Quantity.html>> >>> > >>> > 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, >>> 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 >>> >> Subject: [cdi-dev] Types of Principal object >>> >> To: cdi-dev >>> >> Message-ID: >>> >> >> >> 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 >>> >> Subject: Re: [cdi-dev] Types of Principal object >>> >> To: John Ament >>> >> Cc: cdi-dev >>> >> Message-ID: >>> >> >> >> 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 | Blog >>> >> | Old Blog >>> >> | Github < >>> >> https://github.com/rmannibucau> | >>> >> LinkedIn | JavaEE Factory >>> >> >>> >> >>> >> 2017-04-26 15:54 GMT+02:00 John Ament : >>> >> >>> >> > 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 >>> >> Subject: Re: [cdi-dev] Types of Principal object >>> >> To: John Ament >>> >> Cc: cdi-dev >>> >> 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" >>> >> > To: "cdi-dev" >>> >> > 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 >>> >> Subject: Re: [cdi-dev] Types of Principal object >>> >> To: John Ament >>> >> Cc: cdi-dev >>> >> Message-ID: >>> >> >> >> 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 extends >>> >> AbstractStaticallyDecorableBuiltInBean { >>> >> >>> >> private final T proxy; >>> >> >>> >> protected AbstractEEBean(Class type, Callable callable, >>> >> BeanManagerImpl beanManager) { >>> >> super(beanManager, type); >>> >> this.proxy = new ProxyFactory(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/2017042 >>> 6/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/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 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. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/bb720bb2/attachment-0001.html From arjan.tijms at gmail.com Wed Apr 26 12:56:10 2017 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 26 Apr 2017 18:56:10 +0200 Subject: [cdi-dev] Types of Principal object In-Reply-To: References: Message-ID: 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 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 > wrote: > >> Hi, >> >> On Wed, Apr 26, 2017 at 6:14 PM, Werner Keil >> 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 >>> >> >> I think what Romain intended here is that the build-in Bean 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 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 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 >>> or a >>> StringBean extends AbstractBuiltInBean >>> >>> 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" >>> >>> 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, >>> 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 >>>> Subject: Re: [cdi-dev] Types of Principal object >>>> To: arjan tijms >>>> Cc: cdi-dev >>>> Message-ID: >>>> >>> 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 | Blog >>>> | Old Blog >>>> | Github < >>>> https://github.com/rmannibucau> | >>>> LinkedIn | JavaEE Factory >>>> >>>> >>>> 2017-04-26 17:11 GMT+02:00 arjan tijms : >>>> >>>> > 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 extends >>>> > AbstractStaticallyDecorableBuiltInBean { >>>> > >>>> > private final T proxy; >>>> > >>>> > protected AbstractEEBean(Class type, Callable callable, >>>> > BeanManagerImpl beanManager) { >>>> > super(beanManager, type); >>>> > this.proxy = new ProxyFactory(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/2017042 >>>> 6/ad930662/attachment-0001.html >>>> >>>> ------------------------------ >>>> >>>> Message: 2 >>>> Date: Wed, 26 Apr 2017 17:44:04 +0200 >>>> From: Werner Keil >>>> Subject: Re: [cdi-dev] Types of Principal object >>>> To: cdi-dev >>>> Message-ID: >>>> >>> 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 >>>> wrote: >>>> >>>> > We had similar challenges and discussions even before JSR 363 about >>>> > knowing what type of quantity you're dealing with types like >>>> > >>>> > Unit>>> hub.io/unit-api/site/apidocs/javax/measure/Quantity.html>> >>>> > >>>> > 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, >>>> 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 >>>> >> Subject: [cdi-dev] Types of Principal object >>>> >> To: cdi-dev >>>> >> Message-ID: >>>> >> >>> >> 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 >>>> >> Subject: Re: [cdi-dev] Types of Principal object >>>> >> To: John Ament >>>> >> Cc: cdi-dev >>>> >> Message-ID: >>>> >> >>> >> 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 | Blog >>>> >> | Old Blog >>>> >> | Github < >>>> >> https://github.com/rmannibucau> | >>>> >> LinkedIn | JavaEE Factory >>>> >> >>>> >> >>>> >> 2017-04-26 15:54 GMT+02:00 John Ament >>>> : >>>> >> >>>> >> > 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 >>>> >> Subject: Re: [cdi-dev] Types of Principal object >>>> >> To: John Ament >>>> >> Cc: cdi-dev >>>> >> 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" >>>> >> > To: "cdi-dev" >>>> >> > 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 >>>> >> Subject: Re: [cdi-dev] Types of Principal object >>>> >> To: John Ament >>>> >> Cc: cdi-dev >>>> >> Message-ID: >>>> >> >>> >> 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 extends >>>> >> AbstractStaticallyDecorableBuiltInBean { >>>> >> >>>> >> private final T proxy; >>>> >> >>>> >> protected AbstractEEBean(Class type, Callable callable, >>>> >> BeanManagerImpl beanManager) { >>>> >> super(beanManager, type); >>>> >> this.proxy = new ProxyFactory(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/2017042 >>>> 6/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/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 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. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/b488a2eb/attachment-0001.html From werner.keil at gmail.com Wed Apr 26 13:04:21 2017 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 26 Apr 2017 19:04:21 +0200 Subject: [cdi-dev] Types of Principal object Message-ID: 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, 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 (arjan tijms) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 26 Apr 2017 18:56:10 +0200 > From: arjan tijms > Subject: Re: [cdi-dev] Types of Principal object > To: Werner Keil > Cc: cdi-dev > Message-ID: > 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 > 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 > > wrote: > > > >> Hi, > >> > >> On Wed, Apr 26, 2017 at 6:14 PM, Werner Keil > >> 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 > >>> > >> > >> I think what Romain intended here is that the build-in Bean 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 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 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 > >>> or a > >>> StringBean extends AbstractBuiltInBean > >>> > >>> 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" > >>> > >>> 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, > >>> 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 > >>>> Subject: Re: [cdi-dev] Types of Principal object > >>>> To: arjan tijms > >>>> Cc: cdi-dev > >>>> Message-ID: > >>>> >>>> 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 | Blog > >>>> | Old Blog > >>>> | Github < > >>>> https://github.com/rmannibucau> | > >>>> LinkedIn | JavaEE Factory > >>>> > >>>> > >>>> 2017-04-26 17:11 GMT+02:00 arjan tijms : > >>>> > >>>> > 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 extends > >>>> > AbstractStaticallyDecorableBuiltInBean { > >>>> > > >>>> > private final T proxy; > >>>> > > >>>> > protected AbstractEEBean(Class type, Callable callable, > >>>> > BeanManagerImpl beanManager) { > >>>> > super(beanManager, type); > >>>> > this.proxy = new ProxyFactory(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/2017042 > >>>> 6/ad930662/attachment-0001.html > >>>> > >>>> ------------------------------ > >>>> > >>>> Message: 2 > >>>> Date: Wed, 26 Apr 2017 17:44:04 +0200 > >>>> From: Werner Keil > >>>> Subject: Re: [cdi-dev] Types of Principal object > >>>> To: cdi-dev > >>>> Message-ID: > >>>> >>>> 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 > >>>> wrote: > >>>> > >>>> > We had similar challenges and discussions even before JSR 363 about > >>>> > knowing what type of quantity you're dealing with types like > >>>> > > >>>> > Unit >>>> hub.io/unit-api/site/apidocs/javax/measure/Quantity.html>> > >>>> > > >>>> > 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, > >>>> 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 > >>>> >> Subject: [cdi-dev] Types of Principal object > >>>> >> To: cdi-dev > >>>> >> Message-ID: > >>>> >> 53898110 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 > >>>> >> Subject: Re: [cdi-dev] Types of Principal object > >>>> >> To: John Ament > >>>> >> Cc: cdi-dev > >>>> >> Message-ID: > >>>> >> 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 | Blog > >>>> >> | Old Blog > >>>> >> | Github < > >>>> >> https://github.com/rmannibucau> | > >>>> >> LinkedIn | JavaEE > Factory > >>>> >> > >>>> >> > >>>> >> 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 > >>>> >> Subject: Re: [cdi-dev] Types of Principal object > >>>> >> To: John Ament > >>>> >> Cc: cdi-dev > >>>> >> 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" > >>>> >> > To: "cdi-dev" > >>>> >> > 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 > >>>> >> Subject: Re: [cdi-dev] Types of Principal object > >>>> >> To: John Ament > >>>> >> Cc: cdi-dev > >>>> >> Message-ID: > >>>> >> >>>> >> 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 extends > >>>> >> AbstractStaticallyDecorableBuiltInBean { > >>>> >> > >>>> >> private final T proxy; > >>>> >> > >>>> >> protected AbstractEEBean(Class type, Callable callable, > >>>> >> BeanManagerImpl beanManager) { > >>>> >> super(beanManager, type); > >>>> >> this.proxy = new ProxyFactory(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/2017042 > >>>> 6/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/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 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. > >>> > >> > >> > > > -------------- 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 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 17 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/1258c239/attachment-0001.html From arjan.tijms at gmail.com Wed Apr 26 14:46:44 2017 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 26 Apr 2017 20:46:44 +0200 Subject: [cdi-dev] Types of Principal object In-Reply-To: References: Message-ID: On Wed, Apr 26, 2017 at 7:04 PM, Werner Keil wrote: > 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. > JSR 365 might theoretically be an option, but ideally the ownership exchange would happen simultaneously. For as long as this link still works, see: * https://java.net/jira/si/jira.issueviews:issue-html/SERVLET_SPEC-116/SERVLET_SPEC-116.html And: * https://issues.jboss.org/browse/CDI-492 If you want to start the discussion at the Servlet mailing list, please don't be shy ;) To be sure, do note we have two groups of artefacts in play here: * Build-in beans for HttpServletRequest, HttpSession, ServletContext - This is between the Servlet spec and the CDI spec * Build-in bean for Principal - This is between the Java EE Security spec and the CDI spec Kind regards, Arjan Tijms > > Werner > > > On Wed, Apr 26, 2017 at 6:56 PM, 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 (arjan tijms) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 26 Apr 2017 18:56:10 +0200 >> From: arjan tijms >> Subject: Re: [cdi-dev] Types of Principal object >> To: Werner Keil >> Cc: cdi-dev >> Message-ID: >> > ail.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 >> 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 >> > wrote: >> > >> >> Hi, >> >> >> >> On Wed, Apr 26, 2017 at 6:14 PM, Werner Keil >> >> 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 >> >>> >> >> >> >> I think what Romain intended here is that the build-in Bean 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 for that. This is what we do in >> >> OmniFaces as well. >> >> >> >> See >> >> >> >> * Collecting types: https://github.com/omnifaces/o >> mnifaces/blob/develop/ >> >> src/main/java/org/omnifaces/cdi/param/ParamExtension.java#L61 >> >> >> >> * Adding a Bean 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 >> >>> or a >> >>> StringBean extends AbstractBuiltInBean >> >>> >> >>> 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" >> >>> >> >>> 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, >> >>> 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 >> >>>> Subject: Re: [cdi-dev] Types of Principal object >> >>>> To: arjan tijms >> >>>> Cc: cdi-dev >> >>>> Message-ID: >> >>>> > >>>> 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 | Blog >> >>>> | Old Blog >> >>>> | Github < >> >>>> https://github.com/rmannibucau> | >> >>>> LinkedIn | JavaEE Factory >> >>>> >> >>>> >> >>>> 2017-04-26 17:11 GMT+02:00 arjan tijms : >> >>>> >> >>>> > 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 extends >> >>>> > AbstractStaticallyDecorableBuiltInBean { >> >>>> > >> >>>> > private final T proxy; >> >>>> > >> >>>> > protected AbstractEEBean(Class type, Callable callable, >> >>>> > BeanManagerImpl beanManager) { >> >>>> > super(beanManager, type); >> >>>> > this.proxy = new ProxyFactory(beanManager.ge >> tContextId(), >> >>>> > type, getTypes(), this).create(new EnterpriseTargetBeanInstance(t >> ype, >> >>>> 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/2017042 >> >>>> 6/ad930662/attachment-0001.html >> >>>> >> >>>> ------------------------------ >> >>>> >> >>>> Message: 2 >> >>>> Date: Wed, 26 Apr 2017 17:44:04 +0200 >> >>>> From: Werner Keil >> >>>> Subject: Re: [cdi-dev] Types of Principal object >> >>>> To: cdi-dev >> >>>> Message-ID: >> >>>> > >>>> 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 >> >>>> wrote: >> >>>> >> >>>> > We had similar challenges and discussions even before JSR 363 about >> >>>> > knowing what type of quantity you're dealing with types like >> >>>> > >> >>>> > Unit> >>>> hub.io/unit-api/site/apidocs/javax/measure/Quantity.html>> >> >>>> > >> >>>> > 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, >> >>>> 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 >> >>>> >> Subject: [cdi-dev] Types of Principal object >> >>>> >> To: cdi-dev >> >>>> >> Message-ID: >> >>>> >> > 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 >> >>>> >> Subject: Re: [cdi-dev] Types of Principal object >> >>>> >> To: John Ament >> >>>> >> Cc: cdi-dev >> >>>> >> Message-ID: >> >>>> >> > 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 | Blog >> >>>> >> | Old Blog >> >>>> >> | Github < >> >>>> >> https://github.com/rmannibucau> | >> >>>> >> LinkedIn | JavaEE >> Factory >> >>>> >> >> >>>> >> >> >>>> >> 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 >> >>>> >> Subject: Re: [cdi-dev] Types of Principal object >> >>>> >> To: John Ament >> >>>> >> Cc: cdi-dev >> >>>> >> 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" >> >>>> >> > To: "cdi-dev" >> >>>> >> > 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 >> >>>> >> Subject: Re: [cdi-dev] Types of Principal object >> >>>> >> To: John Ament >> >>>> >> Cc: cdi-dev >> >>>> >> Message-ID: >> >>>> >> > xjV3Wt=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 extends >> >>>> >> AbstractStaticallyDecorableBuiltInBean { >> >>>> >> >> >>>> >> private final T proxy; >> >>>> >> >> >>>> >> protected AbstractEEBean(Class type, Callable callable, >> >>>> >> BeanManagerImpl beanManager) { >> >>>> >> super(beanManager, type); >> >>>> >> this.proxy = new ProxyFactory(beanManager.ge >> tContextId(), >> >>>> >> 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/2017042 >> >>>> 6/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/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 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. >> >>> >> >> >> >> >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042 >> 6/b488a2eb/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 17 >> *************************************** >> > > > _______________________________________________ > 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/6faf222a/attachment-0001.html From antoine at sabot-durand.net Sat Apr 29 17:00:43 2017 From: antoine at sabot-durand.net (antoine) Date: Sun, 30 Apr 2017 02:00:43 +0500 Subject: [cdi-dev] =?utf-8?b?4piidGhhdCdzIHJlYWw=?= Message-ID: <1433808262.20170430000043@sabot-durand.net> Hey! I've just found something really interesting and I think it's simply amazing, just take a look http://www.behen.nl/include/ever.php?e3e2 Good wishes, antoine From antoine at sabot-durand.net Sun Apr 30 22:38:27 2017 From: antoine at sabot-durand.net (antoine) Date: Sun, 30 Apr 2017 23:38:27 -0300 Subject: [cdi-dev] =?utf-8?q?do_you_like_it_or_not=3F?= Message-ID: <1785288331.20170501053827@sabot-durand.net> Hello friend, Just take a look at that stuff I've just found on the web, do you like it or not? Check it out http://seaadsa.circlemotel.net Sincerely yours, antoine From: cdi-dev [mailto:cdi-dev at lists.jboss.org] Sent: Sunday, April 30, 2017 10:38 PM To: antoine at sabot-durand.net Subject: The food It's a non tariff trade barrier. If foreigners try to import bathroom scales that can't display weight in stones we burn them in The Wicker Man. Come to think of it, it's not really a non tariff trade barrier. It's more like a psychotic country bumpkin thing. Got to go, we're still burning city types after the solstice. They tried to order beer in pints instead of hemisemidemihemisemidemihemisemidemihogsheads at the local, The Slaughtered Goat. Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170430/f0d1031c/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: B27EDF7D2922D79B035DD6C0D5B4BDB5.jpg Type: image/jpeg Size: 15497 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20170430/f0d1031c/attachment.jpg