From issues at jboss.org Fri Apr 1 08:50:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Fri, 1 Apr 2016 08:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-595) Clarify if it is possible to 'manually' use interceptor In-Reply-To: References: Message-ID: Matej Novotny created CDI-595: --------------------------------- Summary: Clarify if it is possible to 'manually' use interceptor Key: CDI-595 URL: https://issues.jboss.org/browse/CDI-595 Project: CDI Specification Issues Issue Type: Bug Components: Interceptors Affects Versions: 2.0-EDR1 Reporter: Matej Novotny This issue was inspired by Deltapike issue ([DELTASPIKE-1060|https://issues.apache.org/jira/browse/DELTASPIKE-1060] and [DELTASPIKE-1108|https://issues.apache.org/jira/browse/DELTASPIKE-1108]). In the DS issue, the interceptor instance is created with {{new CreationalContext}} and injects an {{@Intercepted Bean}}. Later on, there is an attempt to manually call {{javax.enterprise.inject.spi.Interceptor.intercept(InterceptionType, T, InvocationContext)}}. This (obviously) fails, as the interceptor does not have a context (meaning a link to the bean it is supposed to intercept). Quoting the interceptors spec: "The lifecycle of an interceptor instance is the same as that of the target class instance with which it is associated." Therefore we might want to clarify whether creating interceptors in this way is valid at all. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Apr 3 07:14:00 2016 From: issues at jboss.org (Thomas Andraschko (JIRA)) Date: Sun, 3 Apr 2016 07:14:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-595) Clarify if it is possible to 'manually' use interceptor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185667#comment-13185667 ] Thomas Andraschko commented on CDI-595: --------------------------------------- +1 It would be great if we could enhance beanManager#resolveInterceptors to pass the bean. Currently in DS we can only support interceptors with binding and not via @Interceptors as beanManager#resolveInterceptors can only be used with bindings. It would be great if we could also enhance #resolveInceptors to be used with the interceptor class, too. > Clarify if it is possible to 'manually' use interceptor > ------------------------------------------------------- > > Key: CDI-595 > URL: https://issues.jboss.org/browse/CDI-595 > Project: CDI Specification Issues > Issue Type: Bug > Components: Interceptors > Affects Versions: 2.0-EDR1 > Reporter: Matej Novotny > > This issue was inspired by Deltapike issue ([DELTASPIKE-1060|https://issues.apache.org/jira/browse/DELTASPIKE-1060] and [DELTASPIKE-1108|https://issues.apache.org/jira/browse/DELTASPIKE-1108]). > In the DS issue, the interceptor instance is created with {{new CreationalContext}} and injects an {{@Intercepted Bean}}. > Later on, there is an attempt to manually call {{javax.enterprise.inject.spi.Interceptor.intercept(InterceptionType, T, InvocationContext)}}. > This (obviously) fails, as the interceptor does not have a context (meaning a link to the bean it is supposed to intercept). > Quoting the interceptors spec: "The lifecycle of an interceptor instance is the same as that of the target class instance with which it is associated." > Therefore we might want to clarify whether creating interceptors in this way is valid at all. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 4 05:15:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 4 Apr 2016 05:15:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-578) define behaviour of firing an event for an observer with transaction if the transaction is not open or marked rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-578: ----------------------------- Git Pull Request: https://github.com/cdi-spec/cdi/pull/272 > define behaviour of firing an event for an observer with transaction if the transaction is not open or marked rollback > ---------------------------------------------------------------------------------------------------------------------- > > Key: CDI-578 > URL: https://issues.jboss.org/browse/CDI-578 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > The original problem description can be found at https://issues.apache.org/jira/browse/OWB-1111 > If you have an observer > {code} > public void clearCacheAfterTx(@Observes(during=TransactionPhase.AFTER_COMPLETION) ClearAfterTx payload) {...} > {code} > and you fire the event > {code} > clearCacheEvent.fire(new ClearCacheEvent()); > {code} > In this case the behaviour when firing the event if the underlying transaction is already closed or rolled back is totally undefined. It might blow up or continue silently depending on the server. > The problem is that you cannot enlisten a Synchronisation at the tx anymore. > I think we should define/clarify how it should behave in the various phases. > E.g. a during=AFTER_SUCCESS should NOT deliver the event immediately if the tx is already marked for rollback. But for AFTER_COMPLETION it might be perfectly fine. > At the end we need a matrix of the the event phases + possible Exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Mon Apr 4 11:42:41 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 04 Apr 2016 15:42:41 +0000 Subject: [cdi-dev] PR review and Hangout meeting In-Reply-To: References: Message-ID: Guys, I didn't got answer from my first mail. As I said I'm ok for Hangout meeting but only if the participant already start reviewing the open PR. So could we schedule such a meeting tomorrow or later this week. Please fill the following Doodle to give your best time slot for such a meeting. Antoine Le jeu. 31 mars 2016 ? 16:38, Antoine Sabot-Durand a ?crit : > Hi all, > > During last meeting we discuss about making some meeting with hangout to > be more efficient with the current PR. > We could setup a meeting Tuesday evening to replace our IRC meeting (6:00 > pm CEST) or any other day of the week (and later if necessary), but this > meeting will be useless if you don't have time to review the open PR. > So let me know if the slot is ok for you regarding availability and review > capacity before. > > Antoine > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160404/78bd73d8/attachment.html From john.d.ament at gmail.com Mon Apr 4 11:56:44 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 04 Apr 2016 15:56:44 +0000 Subject: [cdi-dev] PR review and Hangout meeting In-Reply-To: References: Message-ID: To be honest the current slot is nearly impossible for me in my current situation. A google hangout at that time is a non starter. I can block the two hours prior to it if its available for others. John On Mon, Apr 4, 2016 at 11:45 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Guys, > > > I didn't got answer from my first mail. As I said I'm ok for Hangout > meeting but only if the participant already start reviewing the open PR. > So could we schedule such a meeting tomorrow or later this week. > Please fill the following Doodle to give your best time slot for such a > meeting. > > Antoine > > Le jeu. 31 mars 2016 ? 16:38, Antoine Sabot-Durand < > antoine at sabot-durand.net> a ?crit : > >> Hi all, >> >> During last meeting we discuss about making some meeting with hangout to >> be more efficient with the current PR. >> We could setup a meeting Tuesday evening to replace our IRC meeting (6:00 >> pm CEST) or any other day of the week (and later if necessary), but this >> meeting will be useless if you don't have time to review the open PR. >> So let me know if the slot is ok for you regarding availability and >> review capacity before. >> >> Antoine >> > _______________________________________________ > 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/20160404/f4ef2398/attachment-0001.html From struberg at yahoo.de Mon Apr 4 12:37:05 2016 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 4 Apr 2016 16:37:05 +0000 (UTC) Subject: [cdi-dev] PR review and Hangout meeting In-Reply-To: References: Message-ID: <1102479792.2083328.1459787826077.JavaMail.yahoo@mail.yahoo.com> I like to work on CDI-420. I also like to review the builders stuff. Will both do in the evening today. And I'm available from 20:00 on today and tomorrow after the meeting. LieGrue, strub On Monday, 4 April 2016, 17:57, John D. Ament wrote: > > >To be honest the current slot is nearly impossible for me in my current situation. A google hangout at that time is a non starter. I can block the two hours prior to it if its available for others. > > >John > >On Mon, Apr 4, 2016 at 11:45 AM Antoine Sabot-Durand wrote: > >Guys, >> >> >> >> >>I didn't got answer from my first mail. As I said I'm ok for Hangout meeting but only if the participant already start reviewing the open PR. >>So could we schedule such a meeting tomorrow or later this week. >>Please fill the following Doodle to give your best time slot for such a meeting. >> >> >>Antoine >> >>Le jeu. 31 mars 2016 ? 16:38, Antoine Sabot-Durand a ?crit : >> >>Hi all, >>> >>> >>>During last meeting we discuss about making some meeting with hangout to be more efficient with the current PR. >>>We could setup a meeting Tuesday evening to replace our IRC meeting (6:00 pm CEST) or any other day of the week (and later if necessary), but this meeting will be useless if you don't have time to review the open PR. >>>So let me know if the slot is ok for you regarding availability and review capacity before. >>> >>> >>>Antoine _______________________________________________ >>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. > > From mpaluch at paluch.biz Mon Apr 4 12:50:29 2016 From: mpaluch at paluch.biz (Mark Paluch) Date: Mon, 04 Apr 2016 16:50:29 +0000 Subject: [cdi-dev] Fwd: PR review and Hangout meeting In-Reply-To: References: Message-ID: ---------- Forwarded message --------- From: Antoine Sabot-Durand Date: Mo., 4. Apr. 2016 um 18:36 Subject: Re: [cdi-dev] PR review and Hangout meeting To: Mark Paluch Oops sorry, http://doodle.com/poll/bcc264akxiingc8z Le lun. 4 avr. 2016 ? 18:34, Mark Paluch a ?crit : > Hi Antoine, > > do you have a link to the Doodle? > > Thanks, Mark > > > Am 04.04.2016 um 17:42 schrieb Antoine Sabot-Durand < > antoine at sabot-durand.net>: > > Guys, > > > I didn't got answer from my first mail. As I said I'm ok for Hangout > meeting but only if the participant already start reviewing the open PR. > So could we schedule such a meeting tomorrow or later this week. > Please fill the following Doodle to give your best time slot for such a > meeting. > > Antoine > > Le jeu. 31 mars 2016 ? 16:38, Antoine Sabot-Durand < > antoine at sabot-durand.net> a ?crit : > >> Hi all, >> >> During last meeting we discuss about making some meeting with hangout to >> be more efficient with the current PR. >> We could setup a meeting Tuesday evening to replace our IRC meeting (6:00 >> pm CEST) or any other day of the week (and later if necessary), but this >> meeting will be useless if you don't have time to review the open PR. >> So let me know if the slot is ok for you regarding availability and >> review capacity before. >> >> Antoine >> > _______________________________________________ > > > 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/20160404/c2a1bf13/attachment.html From struberg at yahoo.de Mon Apr 4 13:04:26 2016 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 4 Apr 2016 17:04:26 +0000 (UTC) Subject: [cdi-dev] PR review and Hangout meeting In-Reply-To: <1102479792.2083328.1459787826077.JavaMail.yahoo@mail.yahoo.com> References: <1102479792.2083328.1459787826077.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1233335651.2090334.1459789466448.JavaMail.yahoo@mail.yahoo.com> https://issues.jboss.org/browse/CDI-578 Should also be a reasonably low hanging fruit. We already had good discussions and are just missing the last final word polishing imo. LieGrue, strub > On Monday, 4 April 2016, 18:37, Mark Struberg wrote: > > I like to work on CDI-420. > > I also like to review the builders stuff. Will both do in the evening today. > And I'm available from 20:00 on today and tomorrow after the meeting. > > LieGrue, > strub > > > > > On Monday, 4 April 2016, 17:57, John D. Ament > wrote: > > >> >> >> To be honest the current slot is nearly impossible for me in my current > situation. A google hangout at that time is a non starter. I can block the two > hours prior to it if its available for others. >> >> >> John >> >> On Mon, Apr 4, 2016 at 11:45 AM Antoine Sabot-Durand > wrote: >> >> Guys, >>> >>> >>> >>> >>> I didn't got answer from my first mail. As I said I'm ok for > Hangout meeting but only if the participant already start reviewing the open PR. >>> So could we schedule such a meeting tomorrow or later this week. >>> Please fill the following Doodle to give your best time slot for such a > meeting. >>> >>> >>> Antoine >>> >>> Le jeu. 31 mars 2016 ? 16:38, Antoine Sabot-Durand > a ?crit : >>> >>> Hi all, >>>> >>>> >>>> During last meeting we discuss about making some meeting with > hangout to be more efficient with the current PR. >>>> We could setup a meeting Tuesday evening to replace our IRC meeting > (6:00 pm CEST) or any other day of the week (and later if necessary), but this > meeting will be useless if you don't have time to review the open PR. >>>> So let me know if the slot is ok for you regarding availability and > review capacity before. >>>> >>>> >>>> Antoine > _______________________________________________ >>> 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. >> >> > From antoine at sabot-durand.net Tue Apr 5 03:20:49 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 05 Apr 2016 07:20:49 +0000 Subject: [cdi-dev] Hangout meeting today 8:00pm CEST Message-ID: Hi, Only 4 of us answered to the Doodle. Since we all agree on today 8:00pm (CEST) I removed the IRC meeting and set an hangout meeting to this slot. Please check open PRs before the meeting so it can be useful. For those wanting to join, here's the link: https://plus.google.com/hangouts/_/sabot-durand.net/cdi-eg?authuser=0&hceid=YW50b2luZUBzYWJvdC1kdXJhbmQubmV0.jpqt4qo2pfk79avbpg86aq7mt0 Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160405/9be7a660/attachment.html From struberg at yahoo.de Tue Apr 5 11:07:06 2016 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 5 Apr 2016 15:07:06 +0000 (UTC) Subject: [cdi-dev] Hangout meeting today 8:00pm CEST In-Reply-To: References: Message-ID: <2109857690.2636661.1459868826676.JavaMail.yahoo@mail.yahoo.com> As emailed on Sunday, I like to tacke the following issues/PRs: * clarify behaviour of 'during' TransactionPhase Observers in case the TX is not open https://issues.jboss.org/browse/CDI-578 https://github.com/cdi-spec/cdi/pull/272 * bean-discovery-mode 'scoped' https://issues.jboss.org/browse/CDI-420 https://github.com/cdi-spec/cdi/pull/274 Please also send the PRs I should review primarily. txs and LieGrue, strub On Tuesday, 5 April 2016, 9:20, Antoine Sabot-Durand wrote: > > >Hi, > > >Only 4 of us answered to the Doodle. Since we all agree on today 8:00pm (CEST) I removed the IRC meeting and set an hangout meeting to this slot. > > >Please check open PRs before the meeting so it can be useful. > > >For those wanting to join, here's the link: https://plus.google.com/hangouts/_/sabot-durand.net/cdi-eg?authuser=0&hceid=YW50b2luZUBzYWJvdC1kdXJhbmQubmV0.jpqt4qo2pfk79avbpg86aq7mt0 > > >Antoine > > >_______________________________________________ >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 antoine at sabot-durand.net Wed Apr 6 03:24:18 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 06 Apr 2016 07:24:18 +0000 Subject: [cdi-dev] A new hangout meeting on Thursday 8:00pm CEST Message-ID: Hi All, We had a very productive meeting yesterday to work on open PR. We decided to have another one this week on Thursday. Please continue PR review to have a new productive meeting. Hangout link: https://plus.google.com/hangouts/_/sabot-durand.net/cdi-hangout?authuser=0&hceid=YW50b2luZUBzYWJvdC1kdXJhbmQubmV0._6d1kad2389346b9g6l24cb9k6ko4ab9o60ojeba184pk8ha3610j0hi58k Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160406/8b028a30/attachment-0001.html From antoine at sabot-durand.net Wed Apr 6 03:32:09 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 06 Apr 2016 07:32:09 +0000 Subject: [cdi-dev] Apr 5th meeting minutes Message-ID: You'll find the minutes here: https://docs.google.com/document/d/1yxhW--C2b-SKs6nVw8m3nkwfgBBL5aoOz3Hoyg5TWRA/edit?usp=sharing -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160406/f56e511a/attachment.html From mkouba at redhat.com Wed Apr 6 04:09:38 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 6 Apr 2016 10:09:38 +0200 Subject: [cdi-dev] Apr 5th meeting minutes In-Reply-To: References: Message-ID: <5704C442.4000805@redhat.com> I disagree to merge the current version of cdi/pull/272. 1. The current wording is not clear. Esp. the part: "the transaction is in an illegal state". I understand that it should mean an IllegalStateException is thrown during Transaction.registerSynchronization() but I think we should rather follow the javadoc of this method. See also https://github.com/cdi-spec/cdi/pull/272#discussion_r58493520 2. Observer ordering It might be useful to simulate the observer ordering as if the callback was sucessfully registered, e.g. BEFORE_COMPLETION notified before AFTER_COMPLETION and AFTER_FAILURE. See also https://github.com/cdi-spec/cdi/pull/272#issuecomment-206161278 and ongoing discussion. Martin Dne 6.4.2016 v 09:32 Antoine Sabot-Durand napsal(a): > You'll find the minutes here: > > https://docs.google.com/document/d/1yxhW--C2b-SKs6nVw8m3nkwfgBBL5aoOz3Hoyg5TWRA/edit?usp=sharing > > > _______________________________________________ > 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 Software Engineer Red Hat, Czech Republic From antoine at sabot-durand.net Wed Apr 6 04:22:07 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 06 Apr 2016 08:22:07 +0000 Subject: [cdi-dev] Apr 5th meeting minutes In-Reply-To: <5704C442.4000805@redhat.com> References: <5704C442.4000805@redhat.com> Message-ID: Ok, put it on standby and changing the minutes accordingly Le mer. 6 avr. 2016 ? 10:09, Martin Kouba a ?crit : > I disagree to merge the current version of cdi/pull/272. > > 1. The current wording is not clear. > > Esp. the part: "the transaction is in an illegal state". > > I understand that it should mean an IllegalStateException is thrown > during Transaction.registerSynchronization() but I think we should > rather follow the javadoc of this method. > > See also https://github.com/cdi-spec/cdi/pull/272#discussion_r58493520 > > 2. Observer ordering > > It might be useful to simulate the observer ordering as if the callback > was sucessfully registered, e.g. BEFORE_COMPLETION notified before > AFTER_COMPLETION and AFTER_FAILURE. > > See also https://github.com/cdi-spec/cdi/pull/272#issuecomment-206161278 > and ongoing discussion. > > Martin > > Dne 6.4.2016 v 09:32 Antoine Sabot-Durand napsal(a): > > You'll find the minutes here: > > > > > https://docs.google.com/document/d/1yxhW--C2b-SKs6nVw8m3nkwfgBBL5aoOz3Hoyg5TWRA/edit?usp=sharing > > > > > > _______________________________________________ > > 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 > Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160406/f3737adb/attachment.html From issues at jboss.org Wed Apr 6 04:39:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 6 Apr 2016 04:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-596) ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configureAnnotatedType() are used In-Reply-To: References: Message-ID: Martin Kouba created CDI-596: -------------------------------- Summary: ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configureAnnotatedType() are used Key: CDI-596 URL: https://issues.jboss.org/browse/CDI-596 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba Right now, it's not clear what happens if: * a user first calls {{setAnnotatedType()}} and then obtains a reference to the configurator (note that the configurator should be initialized with the AT being processed) * a user obtains a reference to a configurator and then invokes {{setAnnotatedType()}} We could either forbid using both of these methods during one notification, or state that the "last one wins". I would rather go the first way as the second solution might be confusing and error-prone. This applies to {{ProcessObserverMethod}}, {{ProcessBeanAttributes}} and {{ProcessInjectionPoint}} as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 6 04:41:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 6 Apr 2016 04:41:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-596) ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-596: ----------------------------- Summary: ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used (was: ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configureAnnotatedType() are used) > ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used > ------------------------------------------------------------------------------------------------ > > Key: CDI-596 > URL: https://issues.jboss.org/browse/CDI-596 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > > Right now, it's not clear what happens if: > * a user first calls {{setAnnotatedType()}} and then obtains a reference to the configurator (note that the configurator should be initialized with the AT being processed) > * a user obtains a reference to a configurator and then invokes {{setAnnotatedType()}} > We could either forbid using both of these methods during one notification, or state that the "last one wins". I would rather go the first way as the second solution might be confusing and error-prone. > This applies to {{ProcessObserverMethod}}, {{ProcessBeanAttributes}} and {{ProcessInjectionPoint}} as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 6 05:00:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 6 Apr 2016 05:00:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-596) ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-596: ----------------------------- Fix Version/s: 2.0 (discussion) > ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used > ------------------------------------------------------------------------------------------------ > > Key: CDI-596 > URL: https://issues.jboss.org/browse/CDI-596 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Right now, it's not clear what happens if: > * a user first calls {{setAnnotatedType()}} and then obtains a reference to the configurator (note that the configurator should be initialized with the AT being processed) > * a user obtains a reference to a configurator and then invokes {{setAnnotatedType()}} > We could either forbid using both of these methods during one notification, or state that the "last one wins". I would rather go the first way as the second solution might be confusing and error-prone. > This applies to {{ProcessObserverMethod}}, {{ProcessBeanAttributes}} and {{ProcessInjectionPoint}} as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 6 07:49:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 6 Apr 2016 07:49:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-596) ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used within observer notification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-596: ----------------------------- Summary: ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used within observer notification (was: ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used) > ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used within observer notification > ----------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-596 > URL: https://issues.jboss.org/browse/CDI-596 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Right now, it's not clear what happens if: > * a user first calls {{setAnnotatedType()}} and then obtains a reference to the configurator (note that the configurator should be initialized with the AT being processed) > * a user obtains a reference to a configurator and then invokes {{setAnnotatedType()}} > We could either forbid using both of these methods during one notification, or state that the "last one wins". I would rather go the first way as the second solution might be confusing and error-prone. > This applies to {{ProcessObserverMethod}}, {{ProcessBeanAttributes}} and {{ProcessInjectionPoint}} as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 6 08:44:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 6 Apr 2016 08:44:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-596) ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used within observer notification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187474#comment-13187474 ] Antoine Sabot-Durand commented on CDI-596: ------------------------------------------ I think throwing exception is the best approach > ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used within observer notification > ----------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-596 > URL: https://issues.jboss.org/browse/CDI-596 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Right now, it's not clear what happens if: > * a user first calls {{setAnnotatedType()}} and then obtains a reference to the configurator (note that the configurator should be initialized with the AT being processed) > * a user obtains a reference to a configurator and then invokes {{setAnnotatedType()}} > We could either forbid using both of these methods during one notification, or state that the "last one wins". I would rather go the first way as the second solution might be confusing and error-prone. > This applies to {{ProcessObserverMethod}}, {{ProcessBeanAttributes}} and {{ProcessInjectionPoint}} as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 6 10:37:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Wed, 6 Apr 2016 10:37:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-597) Make Principal unwrappable In-Reply-To: References: Message-ID: Romain Manni-Bucau created CDI-597: -------------------------------------- Summary: Make Principal unwrappable Key: CDI-597 URL: https://issues.jboss.org/browse/CDI-597 Project: CDI Specification Issues Issue Type: Epic Reporter: Romain Manni-Bucau CDI allows to get injected a Principal but often you need to access the actual Principal instance when you need more than a name. Since the injection is a proxy (otherwise it would be broken in most of scoped wrapper instances cases) we would need a CDI solution to unwrap this instance. Solution I see without creating a new kind of API but just something specific to this case: CDIPrincipal extends Principal { T unwrap(Class t) } and allow to get it injected directly as Principal today. This issue can be linked to CDI-10 but here it is safe to add unwrap() where on CDI-10 it is not (too general). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 6 10:48:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 6 Apr 2016 10:48:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-597) Make Principal unwrappable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187790#comment-13187790 ] Martin Kouba commented on CDI-597: ---------------------------------- Hi Romain, so the client code would depend on a specific Principal impl, right? If so, then it would make sense to provide a bean for this type (on the Java EE container level - e.g. in the TomEE integration code) so that a client could inject it directly (I don't see a reason for portability here). > Make Principal unwrappable > -------------------------- > > Key: CDI-597 > URL: https://issues.jboss.org/browse/CDI-597 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > CDI allows to get injected a Principal but often you need to access the actual Principal instance when you need more than a name. Since the injection is a proxy (otherwise it would be broken in most of scoped wrapper instances cases) we would need a CDI solution to unwrap this instance. > Solution I see without creating a new kind of API but just something specific to this case: CDIPrincipal extends Principal { T unwrap(Class t) } and allow to get it injected directly as Principal today. > This issue can be linked to CDI-10 but here it is safe to add unwrap() where on CDI-10 it is not (too general). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 6 10:55:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Wed, 6 Apr 2016 10:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-597) Make Principal unwrappable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187794#comment-13187794 ] Romain Manni-Bucau commented on CDI-597: ---------------------------------------- [~mkouba] happy to do it but not tempted to parse method bodies with asm to do so handling java code dependencies etc and that's actually the only way to do it from the container point of view. Point is: very often you rely on a particular principal in the login module and you use it in your app in a dependent manner to propagate some fields (mail, display name...). The LoginModule could even instantiate different kind of principal in its implementation and you could use a "switch" like logic in your code if needed but for that or simply the basic need of accessing additional fields you need to access the actual principal. Here CDI is blocking cause of proxies, user can't really produce the Principal cause LoginModule are often reused (ie code is not under your responsability). > Make Principal unwrappable > -------------------------- > > Key: CDI-597 > URL: https://issues.jboss.org/browse/CDI-597 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > CDI allows to get injected a Principal but often you need to access the actual Principal instance when you need more than a name. Since the injection is a proxy (otherwise it would be broken in most of scoped wrapper instances cases) we would need a CDI solution to unwrap this instance. > Solution I see without creating a new kind of API but just something specific to this case: CDIPrincipal extends Principal { T unwrap(Class t) } and allow to get it injected directly as Principal today. > This issue can be linked to CDI-10 but here it is safe to add unwrap() where on CDI-10 it is not (too general). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 6 11:04:01 2016 From: issues at jboss.org (Arjan t (JIRA)) Date: Wed, 6 Apr 2016 11:04:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-597) Make Principal unwrappable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187799#comment-13187799 ] Arjan t commented on CDI-597: ----------------------------- {quote} Here CDI is blocking cause of proxies, user can't really produce the Principal cause LoginModule are often reused{quote} Just wanted to mention that not every Java EE server makes use of {{LoginModule}}, if you mean {{javax.security.auth.spi.LoginModule}} ;) The responsibility of providing the {{Principal}} instance should perhaps be with the Security API and not with CDI itself. Antoine already asked for Servlet to take responsibility of providing Beans for the Servlet artifacts. I do acknowledge there may be some backward compatibility issues here. > Make Principal unwrappable > -------------------------- > > Key: CDI-597 > URL: https://issues.jboss.org/browse/CDI-597 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > CDI allows to get injected a Principal but often you need to access the actual Principal instance when you need more than a name. Since the injection is a proxy (otherwise it would be broken in most of scoped wrapper instances cases) we would need a CDI solution to unwrap this instance. > Solution I see without creating a new kind of API but just something specific to this case: CDIPrincipal extends Principal { T unwrap(Class t) } and allow to get it injected directly as Principal today. > This issue can be linked to CDI-10 but here it is safe to add unwrap() where on CDI-10 it is not (too general). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 6 11:22:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Wed, 6 Apr 2016 11:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-597) Make Principal unwrappable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187823#comment-13187823 ] Romain Manni-Bucau commented on CDI-597: ---------------------------------------- [~arjant] it is in JAAS so should be supported somehow (but LoginContext is not mandatory). +100 to move it to security spec. That said it means principal injection moves too since today it is in CDI (shouldn't have been I agree) > Make Principal unwrappable > -------------------------- > > Key: CDI-597 > URL: https://issues.jboss.org/browse/CDI-597 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > CDI allows to get injected a Principal but often you need to access the actual Principal instance when you need more than a name. Since the injection is a proxy (otherwise it would be broken in most of scoped wrapper instances cases) we would need a CDI solution to unwrap this instance. > Solution I see without creating a new kind of API but just something specific to this case: CDIPrincipal extends Principal { T unwrap(Class t) } and allow to get it injected directly as Principal today. > This issue can be linked to CDI-10 but here it is safe to add unwrap() where on CDI-10 it is not (too general). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 6 11:34:00 2016 From: issues at jboss.org (Arjan t (JIRA)) Date: Wed, 6 Apr 2016 11:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-597) Make Principal unwrappable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187837#comment-13187837 ] Arjan t commented on CDI-597: ----------------------------- {quote}it is in JAAS {quote} But not all application servers use JAAS, and JAAS is not a mandatory part of Java EE or Servlet. Unless... unless you're referring to the JASPIC LoginModule bridge profile ;) But then the {{CallerPrincipalCallback}} is the primary artifact to deal with, and the SAM just gets the {{Principal}} from the {{LoginModule}}. {quote} +100 to move it to security spec. That said it means principal injection moves too since today it is in CDI (shouldn't have been I agree) {quote} Okay, would be great if we can make this happen. > Make Principal unwrappable > -------------------------- > > Key: CDI-597 > URL: https://issues.jboss.org/browse/CDI-597 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > CDI allows to get injected a Principal but often you need to access the actual Principal instance when you need more than a name. Since the injection is a proxy (otherwise it would be broken in most of scoped wrapper instances cases) we would need a CDI solution to unwrap this instance. > Solution I see without creating a new kind of API but just something specific to this case: CDIPrincipal extends Principal { T unwrap(Class t) } and allow to get it injected directly as Principal today. > This issue can be linked to CDI-10 but here it is safe to add unwrap() where on CDI-10 it is not (too general). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 7 11:50:00 2016 From: issues at jboss.org (Vsevolod Golovanov (JIRA)) Date: Thu, 7 Apr 2016 11:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-525) Default names should maybe follow the inferring rules from the JavaBean spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188573#comment-13188573 ] Vsevolod Golovanov commented on CDI-525: ---------------------------------------- Please keep it consistent. JSF, JPA and everyone else use JavaBeans rules - CDI should too. Otherwise, one EL expression in JSF could have its parts resolved by the different rules for no good reason: {code} #{cDI.JSF} {code} > Default names should maybe follow the inferring rules from the JavaBean spec > ---------------------------------------------------------------------------- > > Key: CDI-525 > URL: https://issues.jboss.org/browse/CDI-525 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > *3.1.5. Default bean name for a managed bean*: > {quote} > The default name for a managed bean is the unqualified class name of the bean class, after converting the first character to lower case. > {quote} > As a result, the default name for a bean class {{URLMatcher}} should be {{uRLMatcher}}. On the other hand the JavaBean spec is using different rules when inferring property names, *8.8 Capitalization of inferred names*: > {quote} > However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone. > {quote} > I.e. the property name for getter {{getURLMatcher()}} woud be {{URLMatcher}}. > Note that there is no TCK test for this and so implementations may differ (issue is already filed: CDITCK-473). Weld is using {{java.beans.Introspector.decapitalize()}} and so it follows the JavaBean spec even now. I'm not sure about OpenWebBeans. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 7 12:58:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 7 Apr 2016 12:58:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-494) Events - clarify that a type variable that resolves to a wildcard is not resolvable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-494: ----------------------------- Summary: Events - clarify that a type variable that resolves to a wildcard is not resolvable (was: Clarify that a type variable that resolves to a wildcard is not resolvable) > Events - clarify that a type variable that resolves to a wildcard is not resolvable > ----------------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 11 08:52:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 11 Apr 2016 08:52:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-598) Clarify what happens if one of the interceptors in the AroundConstruct chain does not invoke InvocationContext.proceed() In-Reply-To: References: Message-ID: Martin Kouba created CDI-598: -------------------------------- Summary: Clarify what happens if one of the interceptors in the AroundConstruct chain does not invoke InvocationContext.proceed() Key: CDI-598 URL: https://issues.jboss.org/browse/CDI-598 Project: CDI Specification Issues Issue Type: Clarification Components: Interceptors Affects Versions: 1.2.Final Reporter: Martin Kouba The interceptors spec only states (2.2 Interceptor Life Cycle): {quote} If the InvocationContext.proceed method is not invoked by an interceptor method, *the target instance will not be created*. {quote} But it's not clear what does it mean in the context of CDI. Possible interpretations are: * {{Contextual.create()}} returns null * an exception (e.g. {{javax.enterprise.inject.CreationException}}) is thrown I think the exception is more appropriate. Note that right now only @Dependent producer methods are allowed to return a null value. By the way, the RI (Weld) currently returns null because there is a TCK test which requires this behavior. I'm going to create a separate TCK issue so that the test is redesigned. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 11 09:02:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 11 Apr 2016 09:02:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-598) Clarify what happens if one of the interceptors in the AroundConstruct chain does not invoke InvocationContext.proceed() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-598: ----------------------------- Description: The interceptors spec only states (2.2 Interceptor Life Cycle): {quote} If the InvocationContext.proceed method is not invoked by an interceptor method, *the target instance will not be created*. {quote} But it's not clear what does it mean in the context of CDI. Possible interpretations are: * {{Contextual.create()}} returns null * an exception (e.g. {{javax.enterprise.inject.CreationException}}) is thrown I think the exception is more appropriate. Note that right now only @Dependent producer methods are allowed to return a null value. By the way, the RI (Weld) currently returns null for beans which have no other interceptors associated and throws NPE for beans which also have other interceptor types associated. Also there is a TCK test which tests the "null" interpretation for a bean with only AroundConstruct interceptors. I'm going to create a separate TCK issue so that the test is redesigned. was: The interceptors spec only states (2.2 Interceptor Life Cycle): {quote} If the InvocationContext.proceed method is not invoked by an interceptor method, *the target instance will not be created*. {quote} But it's not clear what does it mean in the context of CDI. Possible interpretations are: * {{Contextual.create()}} returns null * an exception (e.g. {{javax.enterprise.inject.CreationException}}) is thrown I think the exception is more appropriate. Note that right now only @Dependent producer methods are allowed to return a null value. By the way, the RI (Weld) currently returns null because there is a TCK test which requires this behavior. I'm going to create a separate TCK issue so that the test is redesigned. > Clarify what happens if one of the interceptors in the AroundConstruct chain does not invoke InvocationContext.proceed() > ------------------------------------------------------------------------------------------------------------------------ > > Key: CDI-598 > URL: https://issues.jboss.org/browse/CDI-598 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > The interceptors spec only states (2.2 Interceptor Life Cycle): > {quote} > If the InvocationContext.proceed method is not invoked by an interceptor method, *the target instance will not be created*. > {quote} > But it's not clear what does it mean in the context of CDI. > Possible interpretations are: > * {{Contextual.create()}} returns null > * an exception (e.g. {{javax.enterprise.inject.CreationException}}) is thrown > I think the exception is more appropriate. Note that right now only @Dependent producer methods are allowed to return a null value. > By the way, the RI (Weld) currently returns null for beans which have no other interceptors associated and throws NPE for beans which also have other interceptor types associated. Also there is a TCK test which tests the "null" interpretation for a bean with only AroundConstruct interceptors. I'm going to create a separate TCK issue so that the test is redesigned. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Mon Apr 11 09:17:02 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 11 Apr 2016 13:17:02 +0000 Subject: [cdi-dev] slot of our next Hangout Message-ID: Hi all, We need to plan an other hangout session to discuss about PR for CDI-558 (configurators for meta-data) in priority and other open pr in a second time. Here are the slots I propose for it. Please answer asap to this Doodle, so the majority will be able to attend. http://doodle.com/poll/vu62u3wx5x5wtnu9 Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160411/9da8613d/attachment.html From john.d.ament at gmail.com Mon Apr 11 09:19:50 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 11 Apr 2016 13:19:50 +0000 Subject: [cdi-dev] slot of our next Hangout In-Reply-To: References: Message-ID: Antoine, Just want to check, as of now are we canceling the current recurring 5pm GMT Tuesday meeting? John On Mon, Apr 11, 2016 at 9:17 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > We need to plan an other hangout session to discuss about PR for CDI-558 > (configurators for meta-data) in priority and other open pr in a second > time. Here are the slots I propose for it. > > Please answer asap to this Doodle, so the majority will be able to attend. > > http://doodle.com/poll/vu62u3wx5x5wtnu9 > > Antoine > _______________________________________________ > 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/20160411/fdd7d5f7/attachment.html From antoine at sabot-durand.net Mon Apr 11 09:21:53 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 11 Apr 2016 13:21:53 +0000 Subject: [cdi-dev] slot of our next Hangout In-Reply-To: References: Message-ID: No John, most people can only attend IRC meeting. But we decided to switch a few of them to hangout to be more efficient on closing open PR. BTW it reveals quite useful. Le lun. 11 avr. 2016 ? 15:20, John D. Ament a ?crit : > Antoine, > > Just want to check, as of now are we canceling the current recurring 5pm > GMT Tuesday meeting? > > John > > On Mon, Apr 11, 2016 at 9:17 AM Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi all, >> >> We need to plan an other hangout session to discuss about PR for CDI-558 >> (configurators for meta-data) in priority and other open pr in a second >> time. Here are the slots I propose for it. >> >> Please answer asap to this Doodle, so the majority will be able to attend. >> >> http://doodle.com/poll/vu62u3wx5x5wtnu9 >> >> Antoine >> > _______________________________________________ >> 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/20160411/08e154e4/attachment.html From john.d.ament at gmail.com Mon Apr 11 09:24:43 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 11 Apr 2016 13:24:43 +0000 Subject: [cdi-dev] slot of our next Hangout In-Reply-To: References: Message-ID: Yes, i know, I was there for one of them last week :-) The reason I ask is that one of the proposed slots is scheduled over that meeting. John On Mon, Apr 11, 2016 at 9:22 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > No John, most people can only attend IRC meeting. But we decided to switch > a few of them to hangout to be more efficient on closing open PR. BTW it > reveals quite useful. > > Le lun. 11 avr. 2016 ? 15:20, John D. Ament a > ?crit : > >> Antoine, >> >> Just want to check, as of now are we canceling the current recurring 5pm >> GMT Tuesday meeting? >> >> John >> >> On Mon, Apr 11, 2016 at 9:17 AM Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> >>> Hi all, >>> >>> We need to plan an other hangout session to discuss about PR for CDI-558 >>> (configurators for meta-data) in priority and other open pr in a second >>> time. Here are the slots I propose for it. >>> >>> Please answer asap to this Doodle, so the majority will be able to >>> attend. >>> >>> http://doodle.com/poll/vu62u3wx5x5wtnu9 >>> >>> Antoine >>> >> _______________________________________________ >>> 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/20160411/9b40f0e1/attachment.html From antoine at sabot-durand.net Mon Apr 11 09:26:51 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 11 Apr 2016 13:26:51 +0000 Subject: [cdi-dev] slot of our next Hangout In-Reply-To: References: Message-ID: My idea is to replace it temporary now. And do it from time to time. Unless EG member have concern with this approach... Le lun. 11 avr. 2016 ? 15:24, John D. Ament a ?crit : > Yes, i know, I was there for one of them last week :-) > The reason I ask is that one of the proposed slots is scheduled over that > meeting. > > John > > > On Mon, Apr 11, 2016 at 9:22 AM Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> No John, most people can only attend IRC meeting. But we decided to >> switch a few of them to hangout to be more efficient on closing open PR. >> BTW it reveals quite useful. >> >> Le lun. 11 avr. 2016 ? 15:20, John D. Ament a >> ?crit : >> >>> Antoine, >>> >>> Just want to check, as of now are we canceling the current recurring 5pm >>> GMT Tuesday meeting? >>> >>> John >>> >>> On Mon, Apr 11, 2016 at 9:17 AM Antoine Sabot-Durand < >>> antoine at sabot-durand.net> wrote: >>> >>>> Hi all, >>>> >>>> We need to plan an other hangout session to discuss about PR for >>>> CDI-558 (configurators for meta-data) in priority and other open pr in a >>>> second time. Here are the slots I propose for it. >>>> >>>> Please answer asap to this Doodle, so the majority will be able to >>>> attend. >>>> >>>> http://doodle.com/poll/vu62u3wx5x5wtnu9 >>>> >>>> Antoine >>>> >>> _______________________________________________ >>>> 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/20160411/b8041486/attachment-0001.html From antoine at sabot-durand.net Mon Apr 11 16:45:54 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 11 Apr 2016 20:45:54 +0000 Subject: [cdi-dev] Invitation: CDI EG hangout (Builders API & others) @ Tue Apr 12, 2016 18:00 - 19:00 (ASD Perso) Message-ID: <001a1141784c83e2b305303ba1b9@google.com> You have been invited to the following event. Title: CDI EG hangout (Builders API & others) When: Tue Apr 12, 2016 18:00 - 19:00 Paris Video call: https://plus.google.com/hangouts/_/sabot-durand.net/cdi-eg Calendar: ASD Perso Who: * Antoine Sabot-Durand - organizer * cdi-dev at lists.jboss.org * mjremijan at yahoo.com * manovotn at redhat.com * struberg at yahoo.de * mkouba at redhat.com * John D. Ament Event details: https://www.google.com/calendar/event?action=VIEW&eid=bHBzODBqMzNsdnViMGZudTV2NXA1YnE5cWMgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0NmE2OTlmOWJjODAxNWE5OWI2NmY4ZDhjNzdmZGJjNDJlMjM0MmZkMg&ctz=Europe/Paris&hl=en Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev at lists.jboss.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160411/952f0ca7/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1991 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20160411/952f0ca7/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2032 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20160411/952f0ca7/attachment-0001.bin From antoine at sabot-durand.net Mon Apr 11 16:48:13 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 11 Apr 2016 20:48:13 +0000 Subject: [cdi-dev] slot of our next Hangout In-Reply-To: References: Message-ID: Hi all, So the slot for the hangout will be tomorrow at 6:00pm CEST. I sent an invite to all participant to the Doodle and to the mailing list. Hangout URL is : https://plus.google.com/hangouts/_/sabot-durand.net/cdi-eg?authuser=0&hceid=YW50b2luZUBzYWJvdC1kdXJhbmQubmV0.lps80j33lvub0fnu5v5p5bq9qc Antoine Le lun. 11 avr. 2016 ? 15:26, Antoine Sabot-Durand a ?crit : > My idea is to replace it temporary now. And do it from time to time. > Unless EG member have concern with this approach... > > Le lun. 11 avr. 2016 ? 15:24, John D. Ament a > ?crit : > >> Yes, i know, I was there for one of them last week :-) >> The reason I ask is that one of the proposed slots is scheduled over that >> meeting. >> >> John >> >> >> On Mon, Apr 11, 2016 at 9:22 AM Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> >>> No John, most people can only attend IRC meeting. But we decided to >>> switch a few of them to hangout to be more efficient on closing open PR. >>> BTW it reveals quite useful. >>> >>> Le lun. 11 avr. 2016 ? 15:20, John D. Ament a >>> ?crit : >>> >>>> Antoine, >>>> >>>> Just want to check, as of now are we canceling the current recurring >>>> 5pm GMT Tuesday meeting? >>>> >>>> John >>>> >>>> On Mon, Apr 11, 2016 at 9:17 AM Antoine Sabot-Durand < >>>> antoine at sabot-durand.net> wrote: >>>> >>>>> Hi all, >>>>> >>>>> We need to plan an other hangout session to discuss about PR for >>>>> CDI-558 (configurators for meta-data) in priority and other open pr in a >>>>> second time. Here are the slots I propose for it. >>>>> >>>>> Please answer asap to this Doodle, so the majority will be able to >>>>> attend. >>>>> >>>>> http://doodle.com/poll/vu62u3wx5x5wtnu9 >>>>> >>>>> Antoine >>>>> >>>> _______________________________________________ >>>>> 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/20160411/2a146f4b/attachment-0001.html From antoine at sabot-durand.net Tue Apr 12 02:55:18 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 12 Apr 2016 06:55:18 +0000 Subject: [cdi-dev] CDI 2.0 rodmap Message-ID: Hi guys, Just to share with you the official roadmap that was validated and accepted by Red Hat until CDI 2.0 release. *Release date*: the target is December 2016 / January 2017 *Next early draft (EDR2)*: July 2016 *Next F2F*: tentatively in May/June or September (budget has to be approved yet) Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160412/fcec30a3/attachment.html From issues at jboss.org Tue Apr 12 13:01:00 2016 From: issues at jboss.org (Mark Paluch (JIRA)) Date: Tue, 12 Apr 2016 13:01:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-599) New lifecycle event to handle deployment/statup errors In-Reply-To: References: Message-ID: Mark Paluch created CDI-599: ------------------------------- Summary: New lifecycle event to handle deployment/statup errors Key: CDI-599 URL: https://issues.jboss.org/browse/CDI-599 Project: CDI Specification Issues Issue Type: Feature Request Components: Events Reporter: Mark Paluch With CDI 1.2 the only way to react to deployment/validation errors is to fail on the container start. Some exceptions could be handled/suppressed such as {{UnproxyableResolutionException}}. This ticket is to discuss a new lifecycle event which carries a deployment/validation error so a SPI developer can handle this problem. An example would be to allow unproxyable types in which case the error is reported, a portable extension tells the event to suppress the problem. This way the problem is handled and does not prevent the container start. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 12 13:02:00 2016 From: issues at jboss.org (Mark Paluch (JIRA)) Date: Tue, 12 Apr 2016 13:02:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-599) New lifecycle event to handle deployment/statup errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Paluch updated CDI-599: ---------------------------- Description: With CDI 1.2 the only way to react to deployment/validation errors is to fail on the container start. Some exceptions could be handled/suppressed such as {{UnproxyableResolutionException}}. This ticket is to discuss a new lifecycle event which carries a deployment/validation error so a SPI developer can handle this problem. An example would be to allow unproxyable types in which case the error is reported, a portable extension tells the event to suppress the problem. This way the problem is handled and does not prevent the container start. For the concrete example of allowing proxy was:With CDI 1.2 the only way to react to deployment/validation errors is to fail on the container start. Some exceptions could be handled/suppressed such as {{UnproxyableResolutionException}}. This ticket is to discuss a new lifecycle event which carries a deployment/validation error so a SPI developer can handle this problem. An example would be to allow unproxyable types in which case the error is reported, a portable extension tells the event to suppress the problem. This way the problem is handled and does not prevent the container start. > New lifecycle event to handle deployment/statup errors > ------------------------------------------------------ > > Key: CDI-599 > URL: https://issues.jboss.org/browse/CDI-599 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Reporter: Mark Paluch > > With CDI 1.2 the only way to react to deployment/validation errors is to fail on the container start. Some exceptions could be handled/suppressed such as {{UnproxyableResolutionException}}. This ticket is to discuss a new lifecycle event which carries a deployment/validation error so a SPI developer can handle this problem. An example would be to allow unproxyable types in which case the error is reported, a portable extension tells the event to suppress the problem. This way the problem is handled and does not prevent the container start. > For the concrete example of allowing proxy -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 12 13:03:00 2016 From: issues at jboss.org (Mark Paluch (JIRA)) Date: Tue, 12 Apr 2016 13:03:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-599) New lifecycle event to handle deployment/statup errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Paluch updated CDI-599: ---------------------------- Description: With CDI 1.2 the only way to react to deployment/validation errors is to fail on the container start. Some exceptions could be handled/suppressed such as {{UnproxyableResolutionException}}. This ticket is to discuss a new lifecycle event which carries a deployment/validation error so a SPI developer can handle this problem. An example would be to allow unproxyable types in which case the error is reported, a portable extension tells the event to suppress the problem. This way the problem is handled and does not prevent the container start. For the concrete example of allowing proxying of classes with non-private final methods the user gets a mechanism to run an application which does not conform fully with the CDI spec rules but at least the user is able to use his application. was: With CDI 1.2 the only way to react to deployment/validation errors is to fail on the container start. Some exceptions could be handled/suppressed such as {{UnproxyableResolutionException}}. This ticket is to discuss a new lifecycle event which carries a deployment/validation error so a SPI developer can handle this problem. An example would be to allow unproxyable types in which case the error is reported, a portable extension tells the event to suppress the problem. This way the problem is handled and does not prevent the container start. For the concrete example of allowing proxy > New lifecycle event to handle deployment/statup errors > ------------------------------------------------------ > > Key: CDI-599 > URL: https://issues.jboss.org/browse/CDI-599 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Reporter: Mark Paluch > > With CDI 1.2 the only way to react to deployment/validation errors is to fail on the container start. Some exceptions could be handled/suppressed such as {{UnproxyableResolutionException}}. This ticket is to discuss a new lifecycle event which carries a deployment/validation error so a SPI developer can handle this problem. An example would be to allow unproxyable types in which case the error is reported, a portable extension tells the event to suppress the problem. This way the problem is handled and does not prevent the container start. > For the concrete example of allowing proxying of classes with non-private final methods the user gets a mechanism to run an application which does not conform fully with the CDI spec rules but at least the user is able to use his application. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From john.d.ament at gmail.com Tue Apr 12 13:05:45 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 12 Apr 2016 17:05:45 +0000 Subject: [cdi-dev] CDI 2.0 rodmap In-Reply-To: References: Message-ID: I'm curious, comparing this to the EE8 plans, how does it align? On Tue, Apr 12, 2016 at 2:58 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi guys, > > Just to share with you the official roadmap that was validated and > accepted by Red Hat until CDI 2.0 release. > > *Release date*: the target is December 2016 / January 2017 > > *Next early draft (EDR2)*: July 2016 > > *Next F2F*: tentatively in May/June or September (budget has to be > approved yet) > > Antoine > > > _______________________________________________ > 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/20160412/2ee16bd3/attachment.html From mkouba at redhat.com Thu Apr 14 09:14:50 2016 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 14 Apr 2016 15:14:50 +0200 Subject: [cdi-dev] CDI-494 (next attempt) Message-ID: <570F97CA.8060504@redhat.com> Hi all, this is my last attempt to push CDI-494 [1] forward. I'm not going to describe the problem again, there is ML thread [2], issue comments [3], pull request comments, etc. But, I've prepared a simple sample (arquillian test) [4] to: 1. Show the current behavior (Weld 1.1, Weld 2.3, OWB 1.2, OWB 1.6) 2. Demonstrate what exactly is not possible to write in a portable way today Interesting note: it seems OWB 1.6 partialy supports the behaviour I tend to prefer - i.e. a wildcard type is not considered an unresolvable type variable (although it does not always infer the parameterized type consistently). Feel free to comment the test, issue, etc. Any feedback is appreciated. Thanks, Martin [1] https://github.com/cdi-spec/cdi/pull/277 [2] http://lists.jboss.org/pipermail/cdi-dev/2016-February/007789.html [3] https://issues.jboss.org/browse/CDI-494 [4] https://github.com/mkouba/event-wildcard-test -- Martin Kouba Software Engineer Red Hat, Czech Republic From antoine at sabot-durand.net Mon Apr 18 03:03:53 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 18 Apr 2016 07:03:53 +0000 Subject: [cdi-dev] Busy with Devoxx France this week Message-ID: Hi guys, I'll be at Devoxx France this Week giving talk on CDI. I won't be able to attend our Tuesday meeting. I'll be on PTO next week with no connexion, so our next meeting will be in 2 weeks on may 3rd. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160418/ca23080b/attachment.html From issues at jboss.org Mon Apr 18 03:18:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 18 Apr 2016 03:18:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-494) Events - clarify that a type variable that resolves to a wildcard is not resolvable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13192868#comment-13192868 ] Martin Kouba commented on CDI-494: ---------------------------------- http://lists.jboss.org/pipermail/cdi-dev/2016-April/008163.html > Events - clarify that a type variable that resolves to a wildcard is not resolvable > ----------------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Mon Apr 18 04:54:16 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 18 Apr 2016 08:54:16 +0000 Subject: [cdi-dev] focusing on CDI 494 / PR277 Message-ID: Hi guys, I think we should work on the example Martin created for this PR and come to a decision. The PR is here: https://github.com/cdi-spec/cdi/pull/277 I'm in favor of adopting this PR as all people who officially gave their advice on this PR. So I propose that people who have concern about this raise their hand and give some feedback about the problem they see in adopting this PR. Without feedback before the end of the week I'll consider that nobody is against this feature. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160418/6e44792d/attachment.html From issues at jboss.org Tue Apr 19 07:01:00 2016 From: issues at jboss.org (Mark Paluch (JIRA)) Date: Tue, 19 Apr 2016 07:01:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-599) New lifecycle event to handle deployment/statup errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Paluch updated CDI-599: ---------------------------- Description: With CDI 1.2 the only way to react to deployment/validation errors is to fail on the container start. Some exceptions could be handled/suppressed such as {{UnproxyableResolutionException}}. This ticket is to discuss a new lifecycle event which carries a deployment/validation error so a SPI developer can handle this problem. An example would be to allow unproxyable types in which case the error is reported, a portable extension tells the event to suppress the problem. This way the problem is handled and does not prevent the container start. For the concrete example of allowing proxying of classes with non-private final methods the user gets a mechanism to run an application which does not conform fully with the CDI spec rules but at least the user is able to use his application. An example API could look like: {code} /** * The container fires an event of this type for each deployment validation problem. Unhandled validation problems lead to a * startup exception. Deployment validations can be handled so the container startup is no longer prevented by handled problems. */ public interface ProcessDeploymentValidation { } /** * The container fires an event of this type in case of multiple beans match a certain combination of required type and required * qualifiers and are eligible for injection. This problem can be handled by resolving a bean using {@link #resolve(Bean)}. */ public interface ProcessAmbiguousResolution extends ProcessDeploymentValidation { /** * * @return the affected InjectionPoint. */ InjectionPoint getInjectionPoint(); /** * * @return the set of matching beans for the InjectionPoint. */ Set> getMatchingBeans(); /** * Clarify bean resolution by specifying the bean to inject. * * @param bean */ void resolve(Bean bean); } /** * The container fires an event of this type in case no bean matches a certain combination of required type and required * qualifiers and is eligible for injection. This problem can be handled by providing a bean using {@link #resolve(Bean)}. */ public interface ProcessUnsatisfiedResolution extends ProcessDeploymentValidation { /** * * @return the affected InjectionPoint. */ InjectionPoint getInjectionPoint(); /** * Clarify bean resolution by specifying the bean to inject. * * @param bean */ void resolve(Bean bean); } /** * The container fires an event of this type in case a contextual reference for a bean with a normal scope and a certain bean * type cannot be obtained because the bean type cannot be proxied by the container. */ public interface ProcessUnproxyableResolution extends ProcessDeploymentValidation { /** * The unproxyable bean. * * @return */ Bean getBean(); /** * Suppres this problem and allow bean instances that are partially unproxied. */ void allowUnproxyable(); } {code} was: With CDI 1.2 the only way to react to deployment/validation errors is to fail on the container start. Some exceptions could be handled/suppressed such as {{UnproxyableResolutionException}}. This ticket is to discuss a new lifecycle event which carries a deployment/validation error so a SPI developer can handle this problem. An example would be to allow unproxyable types in which case the error is reported, a portable extension tells the event to suppress the problem. This way the problem is handled and does not prevent the container start. For the concrete example of allowing proxying of classes with non-private final methods the user gets a mechanism to run an application which does not conform fully with the CDI spec rules but at least the user is able to use his application. > New lifecycle event to handle deployment/statup errors > ------------------------------------------------------ > > Key: CDI-599 > URL: https://issues.jboss.org/browse/CDI-599 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Reporter: Mark Paluch > > With CDI 1.2 the only way to react to deployment/validation errors is to fail on the container start. Some exceptions could be handled/suppressed such as {{UnproxyableResolutionException}}. This ticket is to discuss a new lifecycle event which carries a deployment/validation error so a SPI developer can handle this problem. An example would be to allow unproxyable types in which case the error is reported, a portable extension tells the event to suppress the problem. This way the problem is handled and does not prevent the container start. > For the concrete example of allowing proxying of classes with non-private final methods the user gets a mechanism to run an application which does not conform fully with the CDI spec rules but at least the user is able to use his application. > An example API could look like: > {code} > /** > * The container fires an event of this type for each deployment validation problem. Unhandled validation problems lead to a > * startup exception. Deployment validations can be handled so the container startup is no longer prevented by handled problems. > */ > public interface ProcessDeploymentValidation { > } > /** > * The container fires an event of this type in case of multiple beans match a certain combination of required type and required > * qualifiers and are eligible for injection. This problem can be handled by resolving a bean using {@link #resolve(Bean)}. > */ > public interface ProcessAmbiguousResolution extends ProcessDeploymentValidation { > /** > * > * @return the affected InjectionPoint. > */ > InjectionPoint getInjectionPoint(); > /** > * > * @return the set of matching beans for the InjectionPoint. > */ > Set> getMatchingBeans(); > /** > * Clarify bean resolution by specifying the bean to inject. > * > * @param bean > */ > void resolve(Bean bean); > } > /** > * The container fires an event of this type in case no bean matches a certain combination of required type and required > * qualifiers and is eligible for injection. This problem can be handled by providing a bean using {@link #resolve(Bean)}. > */ > public interface ProcessUnsatisfiedResolution extends ProcessDeploymentValidation { > /** > * > * @return the affected InjectionPoint. > */ > InjectionPoint getInjectionPoint(); > /** > * Clarify bean resolution by specifying the bean to inject. > * > * @param bean > */ > void resolve(Bean bean); > } > /** > * The container fires an event of this type in case a contextual reference for a bean with a normal scope and a certain bean > * type cannot be obtained because the bean type cannot be proxied by the container. > */ > public interface ProcessUnproxyableResolution extends ProcessDeploymentValidation { > /** > * The unproxyable bean. > * > * @return > */ > Bean getBean(); > /** > * Suppres this problem and allow bean instances that are partially unproxied. > */ > void allowUnproxyable(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Sat Apr 23 05:36:28 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Sat, 23 Apr 2016 09:36:28 +0000 Subject: [cdi-dev] JSR 250 MR Message-ID: Hi all, I have some news from Linda about JSR 250 MR. It should be launched in the coming weeks. I don't have confirmation of the estimated release date yet, but it should be ok for our own release date. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160423/8bf96bf4/attachment.html From john.d.ament at gmail.com Sat Apr 23 06:56:30 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Sat, 23 Apr 2016 10:56:30 +0000 Subject: [cdi-dev] New builders API Message-ID: Hey guys Based on the last f2f I was in, I took an action item to look at how applications can leverage the new builder methods/classes from this PR: https://github.com/cdi-spec/cdi/pull/287 To do this, I took some existing OSS CDI extensions and converted parts to use the new APIs instead of the old ones. The results were iffy to be honest. Here's some of the key issues I noticed: - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean bean) In the latter, it's clearer to a developer which attributes are required vs optional. Builders typically use sensible defaults. Maybe that was the intention here, but I couldn't really get that sense when converting over. It also wasn't clear what to do when done. I suspect I just leave it, but without some kind of closing "build()" or "done()" method, it becomes ambiguous. - Annotated*Configurator TBH, I have no idea what I was configuring in this one at the first pass. I started with a method. I wanted to replace the method's annotations. It seemed like I could set that up using the configurator, but I ended up having to do setAnnotated at the end anyways, so I'm not sure what the configurator bought me. The one nice thing I saw was the simpler to use lambda functions. Being able to stream through things like annotated method made the code much cleaner. For the open source code, I'll try to get some gists together that show the changes. Maybe there's something I'm missing, so wouldn't mind a second set of eyes on the changes to see. John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160423/fff94436/attachment.html From arjan.tijms at gmail.com Sat Apr 23 11:47:57 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Sat, 23 Apr 2016 17:47:57 +0200 Subject: [cdi-dev] New builders API In-Reply-To: References: Message-ID: Hi, Interesting research really. If you'd like to have another example case, both Mojarra (JSF) and Soteria (Security) use a lot of dynamic bean building. See e.g. https://github.com/jsf-spec/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/cdi/FlashProducer.java and https://github.com/javaee-security-spec/soteria/blob/master/impl/src/main/java/org/glassfish/soteria/cdi/CdiExtension.java#L95 We were already eying the CDI 2.0 BeanBuilder API, but for the meantime have been using our own (less general) version. Kind regards, Arjan Tijms On Sat, Apr 23, 2016 at 12:56 PM, John D. Ament wrote: > Hey guys > > Based on the last f2f I was in, I took an action item to look at how > applications can leverage the new builder methods/classes from this PR: > https://github.com/cdi-spec/cdi/pull/287 > > To do this, I took some existing OSS CDI extensions and converted parts to > use the new APIs instead of the old ones. > > The results were iffy to be honest. Here's some of the key issues I > noticed: > > - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean bean) > In the latter, it's clearer to a developer which attributes are required > vs optional. Builders typically use sensible defaults. Maybe that was the > intention here, but I couldn't really get that sense when converting over. > It also wasn't clear what to do when done. I suspect I just leave it, but > without some kind of closing "build()" or "done()" method, it becomes > ambiguous. > > - Annotated*Configurator > TBH, I have no idea what I was configuring in this one at the first pass. > I started with a method. I wanted to replace the method's annotations. It > seemed like I could set that up using the configurator, but I ended up > having to do setAnnotated at the end anyways, so I'm not sure what the > configurator bought me. > > The one nice thing I saw was the simpler to use lambda functions. Being > able to stream through things like annotated method made the code much > cleaner. > > For the open source code, I'll try to get some gists together that show > the changes. Maybe there's something I'm missing, so wouldn't mind a > second set of eyes on the changes to see. > > John > > _______________________________________________ > 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/20160423/6182387e/attachment-0001.html From mkouba at redhat.com Mon Apr 25 03:30:06 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 25 Apr 2016 09:30:06 +0200 Subject: [cdi-dev] New builders API In-Reply-To: References: Message-ID: <571DC77E.5000606@redhat.com> Hi all, me and Matej, we've already tried to explain some points in cdi/pull/287 discussion. Anyway, we're going to release Weld 3.0.0.Alpha16 (base on 2.0.Alpha4) later this week so that everyone can start playing with the new API. And we'd like to prepare some simple examples to help people get started as well. Martin Dne 23.4.2016 v 12:56 John D. Ament napsal(a): > Hey guys > > Based on the last f2f I was in, I took an action item to look at how > applications can leverage the new builder methods/classes from this PR: > https://github.com/cdi-spec/cdi/pull/287 > > To do this, I took some existing OSS CDI extensions and converted parts > to use the new APIs instead of the old ones. > > The results were iffy to be honest. Here's some of the key issues I > noticed: > > - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean bean) > In the latter, it's clearer to a developer which attributes are required > vs optional. Builders typically use sensible defaults. Maybe that was > the intention here, but I couldn't really get that sense when converting > over. It also wasn't clear what to do when done. I suspect I just > leave it, but without some kind of closing "build()" or "done()" method, > it becomes ambiguous. > > - Annotated*Configurator > TBH, I have no idea what I was configuring in this one at the first > pass. I started with a method. I wanted to replace the method's > annotations. It seemed like I could set that up using the configurator, > but I ended up having to do setAnnotated at the end anyways, so I'm not > sure what the configurator bought me. > > The one nice thing I saw was the simpler to use lambda functions. Being > able to stream through things like annotated method made the code much > cleaner. > > For the open source code, I'll try to get some gists together that show > the changes. Maybe there's something I'm missing, so wouldn't mind a > second set of eyes on the changes to see. > > John > > > _______________________________________________ > 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 Software Engineer Red Hat, Czech Republic From antonin at stefanutti.fr Mon Apr 25 11:28:45 2016 From: antonin at stefanutti.fr (Antonin Stefanutti) Date: Mon, 25 Apr 2016 15:28:45 +0000 Subject: [cdi-dev] New builders API In-Reply-To: <571DC77E.5000606@redhat.com> References: <571DC77E.5000606@redhat.com> Message-ID: Hi All, Two points connected to that new builder API. In a number of use cases, for example the Camel CDI extension that John has looked at (https://github.com/cdi-spec/cdi/pull/287#issuecomment-213834213), a bean is added to actually mutate an existing bean in the AfterBeanDiscovery lifecycle event. Indeed, quite often, the information that?s necessary to mutate the bean isn?t available at the time the BeanAttributes lifecycle event is triggered. It is recurrent that a first phase is required to capture a set of information that?s larger than the sole bean to be changed. So the AfterBeanDiscovery is the perfect time to do that as the developer can query the bean manager. Unfortunately, there is no way to mutate an existing so the work-around is to actually veto the existing one and add a new one or an alternative to it. So I?m wondering whether a subset of the new builder API could be exposed so that the developer can mutate an existing bean, for example adding extra qualifiers to it. So in the second Camel CDI example that John has pointed out, instead of doing: https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L248-L255 having to just recreate an existing bean artificially: https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L301-L307 It would make a lot more sense just to iterate over the existing beans and add the qualifiers to them. Another point, less structuring: as the developers use the stream API over the CDI SPI, the need arises to have Predicate and other functional interfaces for it, like: - check the type of a Bean: https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L267-L268 https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L250 - check the type of a qualifier: https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L280-L284 https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L245 I?m wondering whether the CDI API could provide the more recurrent functional interfaces to avoid each developer having to redeclare her/his own pretty much as it used to be the case the build-in qualifier literals: https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiSpiHelper.java#L49-L57 Antonin > On 25 Apr 2016, at 09:30, Martin Kouba wrote: > > Hi all, > > me and Matej, we've already tried to explain some points in cdi/pull/287 > discussion. Anyway, we're going to release Weld 3.0.0.Alpha16 (base on > 2.0.Alpha4) later this week so that everyone can start playing with the > new API. And we'd like to prepare some simple examples to help people > get started as well. > > Martin > > > Dne 23.4.2016 v 12:56 John D. Ament napsal(a): >> Hey guys >> >> Based on the last f2f I was in, I took an action item to look at how >> applications can leverage the new builder methods/classes from this PR: >> https://github.com/cdi-spec/cdi/pull/287 >> >> To do this, I took some existing OSS CDI extensions and converted parts >> to use the new APIs instead of the old ones. >> >> The results were iffy to be honest. Here's some of the key issues I >> noticed: >> >> - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean bean) >> In the latter, it's clearer to a developer which attributes are required >> vs optional. Builders typically use sensible defaults. Maybe that was >> the intention here, but I couldn't really get that sense when converting >> over. It also wasn't clear what to do when done. I suspect I just >> leave it, but without some kind of closing "build()" or "done()" method, >> it becomes ambiguous. >> >> - Annotated*Configurator >> TBH, I have no idea what I was configuring in this one at the first >> pass. I started with a method. I wanted to replace the method's >> annotations. It seemed like I could set that up using the configurator, >> but I ended up having to do setAnnotated at the end anyways, so I'm not >> sure what the configurator bought me. >> >> The one nice thing I saw was the simpler to use lambda functions. Being >> able to stream through things like annotated method made the code much >> cleaner. >> >> For the open source code, I'll try to get some gists together that show >> the changes. Maybe there's something I'm missing, so wouldn't mind a >> second set of eyes on the changes to see. >> >> John >> >> >> _______________________________________________ >> 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 > 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. From pbenedict at apache.org Mon Apr 25 11:57:18 2016 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 25 Apr 2016 10:57:18 -0500 Subject: [cdi-dev] New builders API In-Reply-To: References: <571DC77E.5000606@redhat.com> Message-ID: This request sounds very familiar to Spring's post-processor framework. Spring allows post-processors to modify/augment bean definitions before the definition is locked for instantiation. Cheers, Paul On Mon, Apr 25, 2016 at 10:28 AM, Antonin Stefanutti wrote: > Hi All, > > Two points connected to that new builder API. > > In a number of use cases, for example the Camel CDI extension that John > has looked at ( > https://github.com/cdi-spec/cdi/pull/287#issuecomment-213834213), a bean > is added to actually mutate an existing bean in the AfterBeanDiscovery > lifecycle event. Indeed, quite often, the information that?s necessary to > mutate the bean isn?t available at the time the BeanAttributes lifecycle > event is triggered. It is recurrent that a first phase is required to > capture a set of information that?s larger than the sole bean to be > changed. So the AfterBeanDiscovery is the perfect time to do that as the > developer can query the bean manager. Unfortunately, there is no way to > mutate an existing so the work-around is to actually veto the existing one > and add a new one or an alternative to it. > > So I?m wondering whether a subset of the new builder API could be exposed > so that the developer can mutate an existing bean, for example adding extra > qualifiers to it. > > So in the second Camel CDI example that John has pointed out, instead of > doing: > > > https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L248-L255 > > having to just recreate an existing bean artificially: > > > https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L301-L307 > > It would make a lot more sense just to iterate over the existing beans and > add the qualifiers to them. > > Another point, less structuring: as the developers use the stream API over > the CDI SPI, the need arises to have Predicate and other functional > interfaces for it, like: > > - check the type of a Bean: > > https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L267-L268 > > https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L250 > - check the type of a qualifier: > > https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L280-L284 > > https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L245 > > I?m wondering whether the CDI API could provide the more recurrent > functional interfaces to avoid each developer having to redeclare her/his > own pretty much as it used to be the case the build-in qualifier literals: > > > https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiSpiHelper.java#L49-L57 > > Antonin > > > On 25 Apr 2016, at 09:30, Martin Kouba wrote: > > > > Hi all, > > > > me and Matej, we've already tried to explain some points in cdi/pull/287 > > discussion. Anyway, we're going to release Weld 3.0.0.Alpha16 (base on > > 2.0.Alpha4) later this week so that everyone can start playing with the > > new API. And we'd like to prepare some simple examples to help people > > get started as well. > > > > Martin > > > > > > Dne 23.4.2016 v 12:56 John D. Ament napsal(a): > >> Hey guys > >> > >> Based on the last f2f I was in, I took an action item to look at how > >> applications can leverage the new builder methods/classes from this PR: > >> https://github.com/cdi-spec/cdi/pull/287 > >> > >> To do this, I took some existing OSS CDI extensions and converted parts > >> to use the new APIs instead of the old ones. > >> > >> The results were iffy to be honest. Here's some of the key issues I > >> noticed: > >> > >> - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean > bean) > >> In the latter, it's clearer to a developer which attributes are required > >> vs optional. Builders typically use sensible defaults. Maybe that was > >> the intention here, but I couldn't really get that sense when converting > >> over. It also wasn't clear what to do when done. I suspect I just > >> leave it, but without some kind of closing "build()" or "done()" method, > >> it becomes ambiguous. > >> > >> - Annotated*Configurator > >> TBH, I have no idea what I was configuring in this one at the first > >> pass. I started with a method. I wanted to replace the method's > >> annotations. It seemed like I could set that up using the configurator, > >> but I ended up having to do setAnnotated at the end anyways, so I'm not > >> sure what the configurator bought me. > >> > >> The one nice thing I saw was the simpler to use lambda functions. Being > >> able to stream through things like annotated method made the code much > >> cleaner. > >> > >> For the open source code, I'll try to get some gists together that show > >> the changes. Maybe there's something I'm missing, so wouldn't mind a > >> second set of eyes on the changes to see. > >> > >> John > >> > >> > >> _______________________________________________ > >> 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 > > 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. > > > _______________________________________________ > 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/20160425/675f58f2/attachment-0001.html From mkouba at redhat.com Tue Apr 26 02:44:31 2016 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 26 Apr 2016 08:44:31 +0200 Subject: [cdi-dev] New builders API In-Reply-To: References: <571DC77E.5000606@redhat.com> Message-ID: <571F0E4F.70306@redhat.com> Hi Antonin, both ideas sound reasonable. However, I would rather focus on the current proposal of builders/configurators right now. Once we agree on basics we can think of other improvements ;-) Please create separate issues for both, the possibility to modify a bean during AfterBeanDiscovery and "functional helpers". Thanks, Martin Dne 25.4.2016 v 17:28 Antonin Stefanutti napsal(a): > Hi All, > > Two points connected to that new builder API. > > In a number of use cases, for example the Camel CDI extension that John has looked at (https://github.com/cdi-spec/cdi/pull/287#issuecomment-213834213), a bean is added to actually mutate an existing bean in the AfterBeanDiscovery lifecycle event. Indeed, quite often, the information that?s necessary to mutate the bean isn?t available at the time the BeanAttributes lifecycle event is triggered. It is recurrent that a first phase is required to capture a set of information that?s larger than the sole bean to be changed. So the AfterBeanDiscovery is the perfect time to do that as the developer can query the bean manager. Unfortunately, there is no way to mutate an existing so the work-around is to actually veto the existing one and add a new one or an alternative to it. > > So I?m wondering whether a subset of the new builder API could be exposed so that the developer can mutate an existing bean, for example adding extra qualifiers to it. > > So in the second Camel CDI example that John has pointed out, instead of doing: > > https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L248-L255 > > having to just recreate an existing bean artificially: > > https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L301-L307 > > It would make a lot more sense just to iterate over the existing beans and add the qualifiers to them. > > Another point, less structuring: as the developers use the stream API over the CDI SPI, the need arises to have Predicate and other functional interfaces for it, like: > > - check the type of a Bean: > https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L267-L268 > https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L250 > - check the type of a qualifier: > https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L280-L284 > https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L245 > > I?m wondering whether the CDI API could provide the more recurrent functional interfaces to avoid each developer having to redeclare her/his own pretty much as it used to be the case the build-in qualifier literals: > > https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiSpiHelper.java#L49-L57 > > Antonin > >> On 25 Apr 2016, at 09:30, Martin Kouba wrote: >> >> Hi all, >> >> me and Matej, we've already tried to explain some points in cdi/pull/287 >> discussion. Anyway, we're going to release Weld 3.0.0.Alpha16 (base on >> 2.0.Alpha4) later this week so that everyone can start playing with the >> new API. And we'd like to prepare some simple examples to help people >> get started as well. >> >> Martin >> >> >> Dne 23.4.2016 v 12:56 John D. Ament napsal(a): >>> Hey guys >>> >>> Based on the last f2f I was in, I took an action item to look at how >>> applications can leverage the new builder methods/classes from this PR: >>> https://github.com/cdi-spec/cdi/pull/287 >>> >>> To do this, I took some existing OSS CDI extensions and converted parts >>> to use the new APIs instead of the old ones. >>> >>> The results were iffy to be honest. Here's some of the key issues I >>> noticed: >>> >>> - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean bean) >>> In the latter, it's clearer to a developer which attributes are required >>> vs optional. Builders typically use sensible defaults. Maybe that was >>> the intention here, but I couldn't really get that sense when converting >>> over. It also wasn't clear what to do when done. I suspect I just >>> leave it, but without some kind of closing "build()" or "done()" method, >>> it becomes ambiguous. >>> >>> - Annotated*Configurator >>> TBH, I have no idea what I was configuring in this one at the first >>> pass. I started with a method. I wanted to replace the method's >>> annotations. It seemed like I could set that up using the configurator, >>> but I ended up having to do setAnnotated at the end anyways, so I'm not >>> sure what the configurator bought me. >>> >>> The one nice thing I saw was the simpler to use lambda functions. Being >>> able to stream through things like annotated method made the code much >>> cleaner. >>> >>> For the open source code, I'll try to get some gists together that show >>> the changes. Maybe there's something I'm missing, so wouldn't mind a >>> second set of eyes on the changes to see. >>> >>> John >>> >>> >>> _______________________________________________ >>> 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 >> 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 Software Engineer Red Hat, Czech Republic From antonin at stefanutti.fr Tue Apr 26 03:05:35 2016 From: antonin at stefanutti.fr (Antonin Stefanutti) Date: Tue, 26 Apr 2016 07:05:35 +0000 Subject: [cdi-dev] New builders API In-Reply-To: <571F0E4F.70306@redhat.com> References: <571DC77E.5000606@redhat.com> <571F0E4F.70306@redhat.com> Message-ID: <88DBCC49-9842-4A05-9F13-A316B9E1F4BC@stefanutti.fr> Hi Martin, You?re right. As backward compatibility is a major constraint in API evolvability though I preferred sharing my needs / ideas as I see there are connected to the current work and may not be possible to meet afterward. My point was that for the current new bean builder API that can be retrieved from AfterBeanDiscovery: NewBeanConfigurator AfterBeanDiscovery.addBean(); A subset could be accessed for discovered beans, e.g.: ExistingBeanConfigurator bean = AfterBeanDiscovery.forBean(manager.getBean(...)); bean.addQualifier(...); ... If the current design for the new bean builder API won?t impede that future evolution then all is good :) Antonin > On 26 Apr 2016, at 08:44, Martin Kouba wrote: > > Hi Antonin, > > both ideas sound reasonable. However, I would rather focus on the current proposal of builders/configurators right now. Once we agree on basics we can think of other improvements ;-) > > Please create separate issues for both, the possibility to modify a bean during AfterBeanDiscovery and "functional helpers". > > Thanks, > > Martin > > Dne 25.4.2016 v 17:28 Antonin Stefanutti napsal(a): >> Hi All, >> >> Two points connected to that new builder API. >> >> In a number of use cases, for example the Camel CDI extension that John has looked at (https://github.com/cdi-spec/cdi/pull/287#issuecomment-213834213), a bean is added to actually mutate an existing bean in the AfterBeanDiscovery lifecycle event. Indeed, quite often, the information that?s necessary to mutate the bean isn?t available at the time the BeanAttributes lifecycle event is triggered. It is recurrent that a first phase is required to capture a set of information that?s larger than the sole bean to be changed. So the AfterBeanDiscovery is the perfect time to do that as the developer can query the bean manager. Unfortunately, there is no way to mutate an existing so the work-around is to actually veto the existing one and add a new one or an alternative to it. >> >> So I?m wondering whether a subset of the new builder API could be exposed so that the developer can mutate an existing bean, for example adding extra qualifiers to it. >> >> So in the second Camel CDI example that John has pointed out, instead of doing: >> >> https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L248-L255 >> >> having to just recreate an existing bean artificially: >> >> https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L301-L307 >> >> It would make a lot more sense just to iterate over the existing beans and add the qualifiers to them. >> >> Another point, less structuring: as the developers use the stream API over the CDI SPI, the need arises to have Predicate and other functional interfaces for it, like: >> >> - check the type of a Bean: >> https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L267-L268 >> https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L250 >> - check the type of a qualifier: >> https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L280-L284 >> https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L245 >> >> I?m wondering whether the CDI API could provide the more recurrent functional interfaces to avoid each developer having to redeclare her/his own pretty much as it used to be the case the build-in qualifier literals: >> >> https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiSpiHelper.java#L49-L57 >> >> Antonin >> >>> On 25 Apr 2016, at 09:30, Martin Kouba wrote: >>> >>> Hi all, >>> >>> me and Matej, we've already tried to explain some points in cdi/pull/287 >>> discussion. Anyway, we're going to release Weld 3.0.0.Alpha16 (base on >>> 2.0.Alpha4) later this week so that everyone can start playing with the >>> new API. And we'd like to prepare some simple examples to help people >>> get started as well. >>> >>> Martin >>> >>> >>> Dne 23.4.2016 v 12:56 John D. Ament napsal(a): >>>> Hey guys >>>> >>>> Based on the last f2f I was in, I took an action item to look at how >>>> applications can leverage the new builder methods/classes from this PR: >>>> https://github.com/cdi-spec/cdi/pull/287 >>>> >>>> To do this, I took some existing OSS CDI extensions and converted parts >>>> to use the new APIs instead of the old ones. >>>> >>>> The results were iffy to be honest. Here's some of the key issues I >>>> noticed: >>>> >>>> - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean bean) >>>> In the latter, it's clearer to a developer which attributes are required >>>> vs optional. Builders typically use sensible defaults. Maybe that was >>>> the intention here, but I couldn't really get that sense when converting >>>> over. It also wasn't clear what to do when done. I suspect I just >>>> leave it, but without some kind of closing "build()" or "done()" method, >>>> it becomes ambiguous. >>>> >>>> - Annotated*Configurator >>>> TBH, I have no idea what I was configuring in this one at the first >>>> pass. I started with a method. I wanted to replace the method's >>>> annotations. It seemed like I could set that up using the configurator, >>>> but I ended up having to do setAnnotated at the end anyways, so I'm not >>>> sure what the configurator bought me. >>>> >>>> The one nice thing I saw was the simpler to use lambda functions. Being >>>> able to stream through things like annotated method made the code much >>>> cleaner. >>>> >>>> For the open source code, I'll try to get some gists together that show >>>> the changes. Maybe there's something I'm missing, so wouldn't mind a >>>> second set of eyes on the changes to see. >>>> >>>> John >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> 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 > Software Engineer > Red Hat, Czech Republic From struberg at yahoo.de Tue Apr 26 07:55:32 2016 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 26 Apr 2016 13:55:32 +0200 Subject: [cdi-dev] JSR 250 MR In-Reply-To: References: Message-ID: <04FCBE70-AD96-4858-AB69-E691C864CD92@yahoo.de> You are a hero! txs, strub > Am 23.04.2016 um 11:36 schrieb Antoine Sabot-Durand : > > Hi all, > > I have some news from Linda about JSR 250 MR. It should be launched in the coming weeks. I don't have confirmation of the estimated release date yet, but it should be ok for our own release date. > > Antoine > _______________________________________________ > 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 issues at jboss.org Thu Apr 28 04:12:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 28 Apr 2016 04:12:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-588) Adding missing annotation Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13198227#comment-13198227 ] Martin Kouba commented on CDI-588: ---------------------------------- This issue could be probably resolved. > Adding missing annotation Literals > ---------------------------------- > > Key: CDI-588 > URL: https://issues.jboss.org/browse/CDI-588 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > Assignee: Martin Kouba > > We forgot literals for {{Inject}} and more questionably literals for: > * {{Observes}} and {{ObservesAsync}} > * {{Produces}} and {{Disposes}} > * {{Specializes}} > * {{TransientReference}} > * {{Vetoed}} > Most of these can be used to help defining a new AnnotatedType to be added to set of discovered types. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Thu Apr 28 04:43:05 2016 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 28 Apr 2016 10:43:05 +0200 Subject: [cdi-dev] New builders API In-Reply-To: <571DC77E.5000606@redhat.com> References: <571DC77E.5000606@redhat.com> Message-ID: <5721CD19.2040603@redhat.com> Hi all, we've just released Weld 3.0.0.Alpha16. So anyone can start playing with the API, discover possibilities and find potential issues: http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ Any feedback is appreciated! Martin Dne 25.4.2016 v 09:30 Martin Kouba napsal(a): > Hi all, > > me and Matej, we've already tried to explain some points in cdi/pull/287 > discussion. Anyway, we're going to release Weld 3.0.0.Alpha16 (base on > 2.0.Alpha4) later this week so that everyone can start playing with the > new API. And we'd like to prepare some simple examples to help people > get started as well. > > Martin > > > Dne 23.4.2016 v 12:56 John D. Ament napsal(a): >> Hey guys >> >> Based on the last f2f I was in, I took an action item to look at how >> applications can leverage the new builder methods/classes from this PR: >> https://github.com/cdi-spec/cdi/pull/287 >> >> To do this, I took some existing OSS CDI extensions and converted parts >> to use the new APIs instead of the old ones. >> >> The results were iffy to be honest. Here's some of the key issues I >> noticed: >> >> - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean bean) >> In the latter, it's clearer to a developer which attributes are required >> vs optional. Builders typically use sensible defaults. Maybe that was >> the intention here, but I couldn't really get that sense when converting >> over. It also wasn't clear what to do when done. I suspect I just >> leave it, but without some kind of closing "build()" or "done()" method, >> it becomes ambiguous. >> >> - Annotated*Configurator >> TBH, I have no idea what I was configuring in this one at the first >> pass. I started with a method. I wanted to replace the method's >> annotations. It seemed like I could set that up using the configurator, >> but I ended up having to do setAnnotated at the end anyways, so I'm not >> sure what the configurator bought me. >> >> The one nice thing I saw was the simpler to use lambda functions. Being >> able to stream through things like annotated method made the code much >> cleaner. >> >> For the open source code, I'll try to get some gists together that show >> the changes. Maybe there's something I'm missing, so wouldn't mind a >> second set of eyes on the changes to see. >> >> John >> >> >> _______________________________________________ >> 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 Software Engineer Red Hat, Czech Republic From rmannibucau at gmail.com Thu Apr 28 04:46:53 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 28 Apr 2016 10:46:53 +0200 Subject: [cdi-dev] JSR 250 MR In-Reply-To: <04FCBE70-AD96-4858-AB69-E691C864CD92@yahoo.de> References: <04FCBE70-AD96-4858-AB69-E691C864CD92@yahoo.de> Message-ID: Hi guys (and the hero ;)) Do you think there is a hope we can move (copy for compatibility) TypeLiteral to JSR 250? Here is the rational behind it: - CDI and JAXRS have more or less the same class - JSONB needs it as well Each spec can duplicate it but it makes the overall EE API inconsistent and the learning curve harder. Since generics are really important in nowaday coding and the class itself if not that big I think JSR 250 can be a good place to put it. Let me know if there is no hope at all and i'll give this feedback to JSONB, if there is a hope please give me some pointers to move forward. My overall vision is to make TypeLiteral and GenericType (JAXRS) deprecated and support both current and JSR 250 new API to slowly support a single type in the whole stack. wdyt? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber | JavaEE Factory 2016-04-26 13:55 GMT+02:00 Mark Struberg : > You are a hero! > > txs, > strub > > > > Am 23.04.2016 um 11:36 schrieb Antoine Sabot-Durand < > antoine at sabot-durand.net>: > > > > Hi all, > > > > I have some news from Linda about JSR 250 MR. It should be launched in > the coming weeks. I don't have confirmation of the estimated release date > yet, but it should be ok for our own release date. > > > > Antoine > > _______________________________________________ > > 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/20160428/6d99bd93/attachment-0001.html From mpaluch at paluch.biz Thu Apr 28 04:49:57 2016 From: mpaluch at paluch.biz (Mark Paluch) Date: Thu, 28 Apr 2016 10:49:57 +0200 Subject: [cdi-dev] JSR 250 MR In-Reply-To: References: <04FCBE70-AD96-4858-AB69-E691C864CD92@yahoo.de> Message-ID: <9377DBE3-DC7B-4746-8E73-59A14BBE451D@paluch.biz> Congrats to the hero. +1 Having duplicated annotations/types using multiple modules is always painful. A unique type helps users a lot to pick the right class. Can we actually submit a PR somewhere to get our changes into JSR250 or will be this done by someone else? > Am 28.04.2016 um 10:46 schrieb Romain Manni-Bucau : > > Hi guys (and the hero ;)) > > Do you think there is a hope we can move (copy for compatibility) TypeLiteral to JSR 250? > > Here is the rational behind it: > > - CDI and JAXRS have more or less the same class > - JSONB needs it as well > > Each spec can duplicate it but it makes the overall EE API inconsistent and the learning curve harder. > > Since generics are really important in nowaday coding and the class itself if not that big I think JSR 250 can be a good place to put it. > > Let me know if there is no hope at all and i'll give this feedback to JSONB, if there is a hope please give me some pointers to move forward. > > My overall vision is to make TypeLiteral and GenericType (JAXRS) deprecated and support both current and JSR 250 new API to slowly support a single type in the whole stack. > > wdyt? > > > > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber | JavaEE Factory > 2016-04-26 13:55 GMT+02:00 Mark Struberg >: > You are a hero! > > txs, > strub > > > > Am 23.04.2016 um 11:36 schrieb Antoine Sabot-Durand >: > > > > Hi all, > > > > I have some news from Linda about JSR 250 MR. It should be launched in the coming weeks. I don't have confirmation of the estimated release date yet, but it should be ok for our own release date. > > > > Antoine > > _______________________________________________ > > 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. > > _______________________________________________ > 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/20160428/75d9243c/attachment.html From arjan.tijms at gmail.com Thu Apr 28 08:15:53 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 28 Apr 2016 14:15:53 +0200 Subject: [cdi-dev] CDI.current() vs initialContext.lookup("java:comp/BeanManager") in modular application servers Message-ID: Hi, I noticed a difference between using CDI.current() and initialContext.lookup("java:comp/BeanManager") when called from within a container jar (e.g. Mojarra) in a modular application server (e.g. JBoss/WildFly). With CDI.current() the bean manager I get when called from within Mojarra is: "Weld BeanManager for com.sun.jsf-impl:main.additionalClasses [bean count=44]" With initialContext.lookup("java:comp/BeanManager") it's: Weld BeanManager for example_app.ear/example_app.war/WEB-INF/classes [bean count=97] Where "example_app" is an EAR application that I used for testing. I wonder, is this difference intended and did I overlook something, or is it an unfortunate consequence of something? An additional problem is that not all (modular) application servers act the same here. E.g. in GlassFish/Payara I get the application bean manager in both cases. Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160428/3186e141/attachment.html From mkouba at redhat.com Fri Apr 29 03:30:33 2016 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 29 Apr 2016 09:30:33 +0200 Subject: [cdi-dev] CDI.current() vs initialContext.lookup("java:comp/BeanManager") in modular application servers In-Reply-To: References: Message-ID: <57230D99.3080407@redhat.com> Hi Arjan, Just few notes here: * A lot of users think that it's irrelevant what BeanManager instance they're working on. The truth is the spec does not define this, i.e. whether there are multiple BeanManager instances in application or single one. On the other hand, some BeanManager methods assume a specific context. See for example BeanManager.getBeans(Type, Annotation...): "Return the set of beans which have the given required type and qualifiers and are available for injection _in the module or library containing the class into which the BeanManager was injected or the Java EE component from whose JNDI environment namespace the BeanManager was obtained_, according to the rules of typesafe resolution." I believe this implies that a concrete BeanManager reference should never be used outside the "module" it was injected in. Otherwise, methods like getBeans() will not work correctly. * CDI.current().getBeanManager() is IMHO underspecified. Javadoc mentions "the current context" but it's not clear what does it mean. * In Weld, there is a BeanManager per bean archive, but as said above it's just an implementation detail. * WRT you use case - it's even more complicated, because you're referencing a JSF implicit dependency, which is not a regular application bean archive, nor a Java EE module, nor does it contain beans.xml (only extensions). org.jboss.as.weld.WeldProvider returns the BeanManager for the "synthetic" bean archive created for the JSF "module" as you're probably calling CDI.current() from a class located in the JSF lib. JNDI lookup returns the BeanManager for the EAR (I have no idea how JNDI works here). * Last but not least - EARs are problematic and always will be (see for example all the @ApplicationScoped and visibility discussions). Martin Dne 28.4.2016 v 14:15 arjan tijms napsal(a): > Hi, > > I noticed a difference between using CDI.current() > and initialContext.lookup("java:comp/BeanManager") when called from > within a container jar (e.g. Mojarra) in a modular application server > (e.g. JBoss/WildFly). > > With CDI.current() the bean manager I get when called from within > Mojarra is: > > "Weld BeanManager for com.sun.jsf-impl:main.additionalClasses [bean > count=44]" > > > With initialContext.lookup("java:comp/BeanManager") it's: > > Weld BeanManager for example_app.ear/example_app.war/WEB-INF/classes > [bean count=97] > > Where "example_app" is an EAR application that I used for testing. > > I wonder, is this difference intended and did I overlook something, or > is it an unfortunate consequence of something? An additional problem is > that not all (modular) application servers act the same here. E.g. in > GlassFish/Payara I get the application bean manager in both cases. > > Kind regards, > Arjan Tijms > > > > > > > > _______________________________________________ > 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 Software Engineer Red Hat, Czech Republic From issues at jboss.org Fri Apr 29 04:57:00 2016 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Fri, 29 Apr 2016 04:57:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-573) Review code of CDI class to switch to ServiceLoader In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13198888#comment-13198888 ] Antonin Stefanutti commented on CDI-573: ---------------------------------------- As I moved from {{2.0-EDR1}} to {{2.0-EDR2}} and the {{getCDIProvider}} method visibility changed to become private, is the following code the expected way for a client to get a reference to the container: {code} CDI container = StreamSupport.stream( ServiceLoader.load(CDIProvider.class, CDI.class.getClassLoader()).spliterator(), false) .findFirst() .map(CDIProvider::initialize) .orElseThrow(() -> new IllegalStateException("No CDIProvider found in the classpath!")); {code} Instead of {{CDI.getCDIProvider().initialize()}}? > Review code of CDI class to switch to ServiceLoader > --------------------------------------------------- > > Key: CDI-573 > URL: https://issues.jboss.org/browse/CDI-573 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method. > In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 29 05:07:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 29 Apr 2016 05:07:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-573) Review code of CDI class to switch to ServiceLoader In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13198896#comment-13198896 ] Martin Kouba commented on CDI-573: ---------------------------------- CDI SE Bootstrap API is not in a usable state since 2.0-EDR2. This is a regression introduced by this commit: https://github.com/cdi-spec/cdi/commit/7f34f41caa12075b625edd127bbff3d4fd1cd29f Note that the bootstrap API will be most probably completely replaced anyway. > Review code of CDI class to switch to ServiceLoader > --------------------------------------------------- > > Key: CDI-573 > URL: https://issues.jboss.org/browse/CDI-573 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method. > In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From arjan.tijms at gmail.com Fri Apr 29 05:39:38 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Fri, 29 Apr 2016 11:39:38 +0200 Subject: [cdi-dev] CDI.current() vs initialContext.lookup("java:comp/BeanManager") in modular application servers In-Reply-To: <57230D99.3080407@redhat.com> References: <57230D99.3080407@redhat.com> Message-ID: On Fri, Apr 29, 2016 at 9:30 AM, Martin Kouba wrote: > * WRT you use case - it's even more complicated, because you're > referencing a JSF implicit dependency, which is not a regular application > bean archive, nor a Java EE module, nor does it contain beans.xml (only > extensions). True, so if more specs are going to re-base on top of CDI, it may be important for the CDI spec to explicitly recognise this case? JSR 375 (Security JSR) and I think MVC would have the exact same problems. The general use case is that the framework specs need to obtain beans from the application, as those beans are the plug-in points so to speak for those frameworks. These can be (CDI) managed converters, validators, authentication mechanisms, identity stores and what have you. For now I guess avoiding CDI.current() and solely depending on initialContext.lookup("java:comp/BeanManager") is the safest choice then. > org.jboss.as.weld.WeldProvider returns the BeanManager for the "synthetic" > bean archive created for the JSF "module" as you're probably calling > CDI.current() from a class located in the JSF lib. Indeed, while debugging I noticed getBeanManager() internally fell through to a special case. > * Last but not least - EARs are problematic and always will be (see for > example all the @ApplicationScoped and visibility discussions). > I know :( I noticed that Weld uses a fallback bean manager, which seemingly is the one for just a completely random module in the EAR. And indeed, bean names and extensions not being isolated between war modules in the ear have caused many other problems. Kind regards, Arjan Tijms > > Martin > > Dne 28.4.2016 v 14:15 arjan tijms napsal(a): > >> Hi, >> >> I noticed a difference between using CDI.current() >> and initialContext.lookup("java:comp/BeanManager") when called from >> within a container jar (e.g. Mojarra) in a modular application server >> (e.g. JBoss/WildFly). >> >> With CDI.current() the bean manager I get when called from within >> Mojarra is: >> >> "Weld BeanManager for com.sun.jsf-impl:main.additionalClasses [bean >> count=44]" >> >> >> With initialContext.lookup("java:comp/BeanManager") it's: >> >> Weld BeanManager for example_app.ear/example_app.war/WEB-INF/classes >> [bean count=97] >> >> Where "example_app" is an EAR application that I used for testing. >> >> I wonder, is this difference intended and did I overlook something, or >> is it an unfortunate consequence of something? An additional problem is >> that not all (modular) application servers act the same here. E.g. in >> GlassFish/Payara I get the application bean manager in both cases. >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> >> >> >> _______________________________________________ >> 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 > Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160429/ed9e2308/attachment.html