From issues at jboss.org Sun Jul 3 09:16:01 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 3 Jul 2016 09:16:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-620) Not clear what the id for an annotated type is. In-Reply-To: References: Message-ID: John Ament created CDI-620: ------------------------------ Summary: Not clear what the id for an annotated type is. Key: CDI-620 URL: https://issues.jboss.org/browse/CDI-620 Project: CDI Specification Issues Issue Type: Clarification Reporter: John Ament The docs for AfterTypeDiscovery.addAnnotatedType(String, Class) do not state what the id is. In addition, it's odd that the addAnnotatedType(AnnotatedType, String) is in that order, and this method is in this order. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Jul 3 09:19:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 3 Jul 2016 09:19:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-621) removeAll method can lead to ambiguities In-Reply-To: References: Message-ID: John Ament created CDI-621: ------------------------------ Summary: removeAll method can lead to ambiguities Key: CDI-621 URL: https://issues.jboss.org/browse/CDI-621 Project: CDI Specification Issues Issue Type: Clarification Reporter: John Ament The method removeAll is ambiguous. This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe. The removeAll method presupposes that annotations are the only thing to configure. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Jul 3 10:53:00 2016 From: issues at jboss.org (arjan tijms (JIRA)) Date: Sun, 3 Jul 2016 10:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-620) Not clear what the id for an annotated type is. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261199#comment-13261199 ] arjan tijms commented on CDI-620: --------------------------------- +1 for this issue. In Soteria we were a bit confused too about what to provide here. Implementation detail; Weld accepts a null for the ID, while OWB throws an exception. {{BeforeBeanDiscovery#addAnnotatedType}} has a similar problem, although the javadoc at least mention the id there it's still not overly clear what "The id of the annotated type" should be. > Not clear what the id for an annotated type is. > ----------------------------------------------- > > Key: CDI-620 > URL: https://issues.jboss.org/browse/CDI-620 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > > The docs for AfterTypeDiscovery.addAnnotatedType(String, Class) do not state what the id is. > In addition, it's odd that the addAnnotatedType(AnnotatedType, String) is in that order, and this method is in this order. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Jul 3 11:59:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 3 Jul 2016 11:59:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-622) External post-configuration of a bean In-Reply-To: References: Message-ID: John Ament created CDI-622: ------------------------------ Summary: External post-configuration of a bean Key: CDI-622 URL: https://issues.jboss.org/browse/CDI-622 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament The use case here is that a framework has provided the application developer with some bean, X. While the framework can provide internal post construction support for this bean, the application developer has some need to set additional attributes on the bean prior to the bean being injected into its final target. The application developer currently has no way to do this. To accomplish this feat, the framework developer must put the burden on the application developer to do both configuration and bootstrapping of this bean. This is a bit of a pain point to be honest. One idea I had was to introduce a {{@Configures}} annotation that could be used, similar to observers. These methods (plural) could be called (based on priority) during the post construct phase and may exist in any managed bean. {code} @Configures public void setupWebServer(WebServer webserver, Configuration configuration) { webserver.setPort(configuration.getWebServerPort()); } {code} In this case, webserver is the bean being configured, configuration is some other bean that retains the configuration data. This should support normal qualifiers, and perhaps provide an injection point for the underlying {{InjectionTarget}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Jul 4 14:03:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 4 Jul 2016 14:03:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-621) removeAll method can lead to ambiguities In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261575#comment-13261575 ] Martin Kouba commented on CDI-621: ---------------------------------- [~meetoblivion] I assume you're talking about {{AnnotatedTypeConfigurator.removeAll()}} and similar methods. If so, then I don't see any ambiguity since the annotations ARE the only thing to configure there (e.g. the set of methods is immutable). > removeAll method can lead to ambiguities > ---------------------------------------- > > Key: CDI-621 > URL: https://issues.jboss.org/browse/CDI-621 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > > The method removeAll is ambiguous. This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe. The removeAll method presupposes that annotations are the only thing to configure. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Jul 4 14:57:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 4 Jul 2016 14:57:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-622) External post-configuration of a bean In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261578#comment-13261578 ] Martin Kouba commented on CDI-622: ---------------------------------- Why not use events/observers and {{@PostConstruct}}? The framework developer may even use some special "configuration holder" as a payload so that the final instance does not leak. > External post-configuration of a bean > ------------------------------------- > > Key: CDI-622 > URL: https://issues.jboss.org/browse/CDI-622 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > The use case here is that a framework has provided the application developer with some bean, X. While the framework can provide internal post construction support for this bean, the application developer has some need to set additional attributes on the bean prior to the bean being injected into its final target. > The application developer currently has no way to do this. To accomplish this feat, the framework developer must put the burden on the application developer to do both configuration and bootstrapping of this bean. This is a bit of a pain point to be honest. > One idea I had was to introduce a {{@Configures}} annotation that could be used, similar to observers. These methods (plural) could be called (based on priority) during the post construct phase and may exist in any managed bean. > {code} > @Configures > public void setupWebServer(WebServer webserver, Configuration configuration) { > webserver.setPort(configuration.getWebServerPort()); > } > {code} > In this case, webserver is the bean being configured, configuration is some other bean that retains the configuration data. This should support normal qualifiers, and perhaps provide an injection point for the underlying {{InjectionTarget}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Tue Jul 5 05:00:35 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 05 Jul 2016 09:00:35 +0000 Subject: [cdi-dev] Canceling today's meeting Message-ID: Hi All, I won't be able tot attend today's meeting but you continue reviewing the main PR for EDR2: https://github.com/cdi-spec/cdi/pull/290 https://github.com/cdi-spec/cdi/pull/296 Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160705/7e919e49/attachment.html From antoine at sabot-durand.net Tue Jul 5 05:07:02 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 05 Jul 2016 09:07:02 +0000 Subject: [cdi-dev] CDI F2F finale date : Sept 6-7 Message-ID: Hi all, Just closed the Doodle and choose the best date (with Java One in mind). So the f2f will take place Tuesday 6th and Wednesday 7th in Red Hat office in Brno (Czech Republic) If you didn't participate to the Doodle but wish to attend, please make me know. I'll post more information on the location and the program shortly. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160705/f9b50cff/attachment.html From john.d.ament at gmail.com Tue Jul 5 06:28:22 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 05 Jul 2016 10:28:22 +0000 Subject: [cdi-dev] Canceling today's meeting In-Reply-To: References: Message-ID: Hi Antoine, Any chance for a meeting later in the week? Based on the discussion occurring in #296, I'm concerned that we're missing something from that one-off discussion we had about the context management API. John On Tue, Jul 5, 2016 at 5:02 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi All, > > I won't be able tot attend today's meeting but you continue reviewing the > main PR for EDR2: > > https://github.com/cdi-spec/cdi/pull/290 > https://github.com/cdi-spec/cdi/pull/296 > > 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/20160705/02b5f648/attachment.html From antoine at sabot-durand.net Tue Jul 5 06:33:05 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 05 Jul 2016 10:33:05 +0000 Subject: [cdi-dev] Canceling today's meeting In-Reply-To: References: Message-ID: We can reschedule a meeting on Tuesday or Friday. Perhaps we could even plan an hangout. Wdyt ? Antoine Le mar. 5 juil. 2016 ? 12:28, John D. Ament a ?crit : > Hi Antoine, > > Any chance for a meeting later in the week? Based on the discussion > occurring in #296, I'm concerned that we're missing something from that > one-off discussion we had about the context management API. > > John > > On Tue, Jul 5, 2016 at 5:02 AM Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi All, >> >> I won't be able tot attend today's meeting but you continue reviewing the >> main PR for EDR2: >> >> https://github.com/cdi-spec/cdi/pull/290 >> https://github.com/cdi-spec/cdi/pull/296 >> >> 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/20160705/42a234b9/attachment-0001.html From john.d.ament at gmail.com Tue Jul 5 07:30:49 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 05 Jul 2016 11:30:49 +0000 Subject: [cdi-dev] Canceling today's meeting In-Reply-To: References: Message-ID: Assuming you meant Thursday/Friday, I'm OK with that. John On Tue, Jul 5, 2016 at 6:33 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > We can reschedule a meeting on Tuesday or Friday. Perhaps we could even > plan an hangout. > > Wdyt ? > > > Antoine > Le mar. 5 juil. 2016 ? 12:28, John D. Ament a > ?crit : > >> Hi Antoine, >> >> Any chance for a meeting later in the week? Based on the discussion >> occurring in #296, I'm concerned that we're missing something from that >> one-off discussion we had about the context management API. >> >> John >> >> On Tue, Jul 5, 2016 at 5:02 AM Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> >>> Hi All, >>> >>> I won't be able tot attend today's meeting but you continue reviewing >>> the main PR for EDR2: >>> >>> https://github.com/cdi-spec/cdi/pull/290 >>> https://github.com/cdi-spec/cdi/pull/296 >>> >>> 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/20160705/d1fe6877/attachment.html From antoine at sabot-durand.net Tue Jul 5 07:50:38 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 05 Jul 2016 11:50:38 +0000 Subject: [cdi-dev] Canceling today's meeting In-Reply-To: References: Message-ID: Ok, let's move the meeting on Thursday then on the IRC channel. Le mar. 5 juil. 2016 ? 13:30, John D. Ament a ?crit : > Assuming you meant Thursday/Friday, I'm OK with that. > > John > > On Tue, Jul 5, 2016 at 6:33 AM Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> We can reschedule a meeting on Tuesday or Friday. Perhaps we could even >> plan an hangout. >> >> Wdyt ? >> >> >> Antoine >> Le mar. 5 juil. 2016 ? 12:28, John D. Ament a >> ?crit : >> >>> Hi Antoine, >>> >>> Any chance for a meeting later in the week? Based on the discussion >>> occurring in #296, I'm concerned that we're missing something from that >>> one-off discussion we had about the context management API. >>> >>> John >>> >>> On Tue, Jul 5, 2016 at 5:02 AM Antoine Sabot-Durand < >>> antoine at sabot-durand.net> wrote: >>> >>>> Hi All, >>>> >>>> I won't be able tot attend today's meeting but you continue reviewing >>>> the main PR for EDR2: >>>> >>>> https://github.com/cdi-spec/cdi/pull/290 >>>> https://github.com/cdi-spec/cdi/pull/296 >>>> >>>> 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/20160705/827cf741/attachment.html From john.d.ament at gmail.com Wed Jul 6 21:55:42 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Thu, 07 Jul 2016 01:55:42 +0000 Subject: [cdi-dev] Canceling today's meeting In-Reply-To: References: Message-ID: Are we definitely having this meeting tomorrow? Unless Martin's available, I think we will need to postpone. John On Tue, Jul 5, 2016 at 7:50 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Ok, let's move the meeting on Thursday then on the IRC channel. > > Le mar. 5 juil. 2016 ? 13:30, John D. Ament a > ?crit : > >> Assuming you meant Thursday/Friday, I'm OK with that. >> >> John >> >> On Tue, Jul 5, 2016 at 6:33 AM Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> >>> We can reschedule a meeting on Tuesday or Friday. Perhaps we could even >>> plan an hangout. >>> >>> Wdyt ? >>> >>> >>> Antoine >>> Le mar. 5 juil. 2016 ? 12:28, John D. Ament a >>> ?crit : >>> >>>> Hi Antoine, >>>> >>>> Any chance for a meeting later in the week? Based on the discussion >>>> occurring in #296, I'm concerned that we're missing something from that >>>> one-off discussion we had about the context management API. >>>> >>>> John >>>> >>>> On Tue, Jul 5, 2016 at 5:02 AM Antoine Sabot-Durand < >>>> antoine at sabot-durand.net> wrote: >>>> >>>>> Hi All, >>>>> >>>>> I won't be able tot attend today's meeting but you continue reviewing >>>>> the main PR for EDR2: >>>>> >>>>> https://github.com/cdi-spec/cdi/pull/290 >>>>> https://github.com/cdi-spec/cdi/pull/296 >>>>> >>>>> 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/20160707/e0cd77fb/attachment.html From antoine at sabot-durand.net Wed Jul 6 22:57:03 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 07 Jul 2016 02:57:03 +0000 Subject: [cdi-dev] Canceling today's meeting In-Reply-To: References: Message-ID: Martin is in PTO this week and the next one. If you want to postpone if will take place on the week of the 18th. Le jeu. 7 juil. 2016 ? 03:55, John D. Ament a ?crit : > Are we definitely having this meeting tomorrow? Unless Martin's > available, I think we will need to postpone. > > John > > > On Tue, Jul 5, 2016 at 7:50 AM Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Ok, let's move the meeting on Thursday then on the IRC channel. >> >> Le mar. 5 juil. 2016 ? 13:30, John D. Ament a >> ?crit : >> >>> Assuming you meant Thursday/Friday, I'm OK with that. >>> >>> John >>> >>> On Tue, Jul 5, 2016 at 6:33 AM Antoine Sabot-Durand < >>> antoine at sabot-durand.net> wrote: >>> >>>> We can reschedule a meeting on Tuesday or Friday. Perhaps we could even >>>> plan an hangout. >>>> >>>> Wdyt ? >>>> >>>> >>>> Antoine >>>> Le mar. 5 juil. 2016 ? 12:28, John D. Ament a >>>> ?crit : >>>> >>>>> Hi Antoine, >>>>> >>>>> Any chance for a meeting later in the week? Based on the discussion >>>>> occurring in #296, I'm concerned that we're missing something from that >>>>> one-off discussion we had about the context management API. >>>>> >>>>> John >>>>> >>>>> On Tue, Jul 5, 2016 at 5:02 AM Antoine Sabot-Durand < >>>>> antoine at sabot-durand.net> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> I won't be able tot attend today's meeting but you continue reviewing >>>>>> the main PR for EDR2: >>>>>> >>>>>> https://github.com/cdi-spec/cdi/pull/290 >>>>>> https://github.com/cdi-spec/cdi/pull/296 >>>>>> >>>>>> 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/20160707/db98b047/attachment-0001.html From john.d.ament at gmail.com Wed Jul 6 22:59:14 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 6 Jul 2016 22:59:14 -0400 Subject: [cdi-dev] Canceling today's meeting In-Reply-To: References: Message-ID: Well does that mean this PR doesn't get merged until he's back? My concern is that his comments aren't clear and don't seem to be in alignment with the hangout we did on the topic unless someone disagrees. On Jul 6, 2016 22:57, "Antoine Sabot-Durand" wrote: > Martin is in PTO this week and the next one. If you want to postpone if > will take place on the week of the 18th. > Le jeu. 7 juil. 2016 ? 03:55, John D. Ament a > ?crit : > >> Are we definitely having this meeting tomorrow? Unless Martin's >> available, I think we will need to postpone. >> >> John >> >> >> On Tue, Jul 5, 2016 at 7:50 AM Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> >>> Ok, let's move the meeting on Thursday then on the IRC channel. >>> >>> Le mar. 5 juil. 2016 ? 13:30, John D. Ament a >>> ?crit : >>> >>>> Assuming you meant Thursday/Friday, I'm OK with that. >>>> >>>> John >>>> >>>> On Tue, Jul 5, 2016 at 6:33 AM Antoine Sabot-Durand < >>>> antoine at sabot-durand.net> wrote: >>>> >>>>> We can reschedule a meeting on Tuesday or Friday. Perhaps we could >>>>> even plan an hangout. >>>>> >>>>> Wdyt ? >>>>> >>>>> >>>>> Antoine >>>>> Le mar. 5 juil. 2016 ? 12:28, John D. Ament >>>>> a ?crit : >>>>> >>>>>> Hi Antoine, >>>>>> >>>>>> Any chance for a meeting later in the week? Based on the discussion >>>>>> occurring in #296, I'm concerned that we're missing something from that >>>>>> one-off discussion we had about the context management API. >>>>>> >>>>>> John >>>>>> >>>>>> On Tue, Jul 5, 2016 at 5:02 AM Antoine Sabot-Durand < >>>>>> antoine at sabot-durand.net> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> I won't be able tot attend today's meeting but you continue >>>>>>> reviewing the main PR for EDR2: >>>>>>> >>>>>>> https://github.com/cdi-spec/cdi/pull/290 >>>>>>> https://github.com/cdi-spec/cdi/pull/296 >>>>>>> >>>>>>> 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/20160706/070fb411/attachment.html From antoine at sabot-durand.net Wed Jul 6 23:07:33 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 07 Jul 2016 03:07:33 +0000 Subject: [cdi-dev] Canceling today's meeting In-Reply-To: References: Message-ID: I agree that it's not clear and too bad he made this comment the day he was leaving on vacation :-(. But perhaps Tomas or Matej have insight of what he meant? Waiting the 18th is not very good regarding integration of this in EDR2. Antoine Le jeu. 7 juil. 2016 ? 04:59, John D. Ament a ?crit : > Well does that mean this PR doesn't get merged until he's back? My > concern is that his comments aren't clear and don't seem to be in alignment > with the hangout we did on the topic unless someone disagrees. > On Jul 6, 2016 22:57, "Antoine Sabot-Durand" > wrote: > >> Martin is in PTO this week and the next one. If you want to postpone if >> will take place on the week of the 18th. >> Le jeu. 7 juil. 2016 ? 03:55, John D. Ament a >> ?crit : >> >>> Are we definitely having this meeting tomorrow? Unless Martin's >>> available, I think we will need to postpone. >>> >>> John >>> >>> >>> On Tue, Jul 5, 2016 at 7:50 AM Antoine Sabot-Durand < >>> antoine at sabot-durand.net> wrote: >>> >>>> Ok, let's move the meeting on Thursday then on the IRC channel. >>>> >>>> Le mar. 5 juil. 2016 ? 13:30, John D. Ament a >>>> ?crit : >>>> >>>>> Assuming you meant Thursday/Friday, I'm OK with that. >>>>> >>>>> John >>>>> >>>>> On Tue, Jul 5, 2016 at 6:33 AM Antoine Sabot-Durand < >>>>> antoine at sabot-durand.net> wrote: >>>>> >>>>>> We can reschedule a meeting on Tuesday or Friday. Perhaps we could >>>>>> even plan an hangout. >>>>>> >>>>>> Wdyt ? >>>>>> >>>>>> >>>>>> Antoine >>>>>> Le mar. 5 juil. 2016 ? 12:28, John D. Ament >>>>>> a ?crit : >>>>>> >>>>>>> Hi Antoine, >>>>>>> >>>>>>> Any chance for a meeting later in the week? Based on the discussion >>>>>>> occurring in #296, I'm concerned that we're missing something from that >>>>>>> one-off discussion we had about the context management API. >>>>>>> >>>>>>> John >>>>>>> >>>>>>> On Tue, Jul 5, 2016 at 5:02 AM Antoine Sabot-Durand < >>>>>>> antoine at sabot-durand.net> wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I won't be able tot attend today's meeting but you continue >>>>>>>> reviewing the main PR for EDR2: >>>>>>>> >>>>>>>> https://github.com/cdi-spec/cdi/pull/290 >>>>>>>> https://github.com/cdi-spec/cdi/pull/296 >>>>>>>> >>>>>>>> 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/20160707/cc234d7a/attachment.html From antoine at sabot-durand.net Thu Jul 7 11:00:15 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 07 Jul 2016 15:00:15 +0000 Subject: [cdi-dev] Will you attend today's meeting Message-ID: Hi all, So we have this planned meeting in one hour to discuss John PR: https://github.com/cdi-spec/cdi/pull/296 Who will join it ? Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160707/c25b26d6/attachment.html From john.d.ament at gmail.com Thu Jul 7 11:40:14 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Thu, 07 Jul 2016 15:40:14 +0000 Subject: [cdi-dev] Will you attend today's meeting In-Reply-To: References: Message-ID: I'll attend if some of the weld team can attend. On Thu, Jul 7, 2016 at 11:01 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > So we have this planned meeting in one hour to discuss John PR: > https://github.com/cdi-spec/cdi/pull/296 > > Who will join it ? > > 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/20160707/c7aa48d6/attachment-0001.html From issues at jboss.org Sun Jul 10 20:02:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 10 Jul 2016 20:02:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-623) Specify what happens when calling addObserverMethod or addBean alone In-Reply-To: References: Message-ID: John Ament created CDI-623: ------------------------------ Summary: Specify what happens when calling addObserverMethod or addBean alone Key: CDI-623 URL: https://issues.jboss.org/browse/CDI-623 Project: CDI Specification Issues Issue Type: Clarification Reporter: John Ament AfterBeanDiscovery exposes methods addObserverMethod and addBean. Both essentially leave dangling configurations that are not usable. I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From john.d.ament at gmail.com Sun Jul 10 20:50:23 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 11 Jul 2016 00:50:23 +0000 Subject: [cdi-dev] [VOTE] Name the class that can start/stop contexts Message-ID: All, It seems like one of the remaining issues with CDI-30 is the name for the class for the context management. This name isn't permanent, we can change after EDR2, but not after final. Here's the proposed renames for "UnmanagedContext": - ManagedContext - ManageableContext - ProgrammaticContext - ExternallyManagedContext - UserManagedContext Please respond back with your vote, I'll leave this open for 3 days ( I believe its Monday morning in central Europe), so I'll close it Thursday morning. Reference: http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2016/cdi-dev.2016-07-07-16.03.log.html - John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160711/c2a9052a/attachment.html From issues at jboss.org Mon Jul 11 03:17:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 11 Jul 2016 03:17:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-621) removeAll method can lead to ambiguities In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13263508#comment-13263508 ] Matej Novotny commented on CDI-621: ----------------------------------- I am also unsure of what the ambiguity is in this case. Do you mean you would rather rename the method to something like {{removeAllAnnotations}}? In that case you might say that all the methods are ambiguous... > removeAll method can lead to ambiguities > ---------------------------------------- > > Key: CDI-621 > URL: https://issues.jboss.org/browse/CDI-621 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > > The method removeAll is ambiguous. This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe. The removeAll method presupposes that annotations are the only thing to configure. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From manovotn at redhat.com Mon Jul 11 03:44:44 2016 From: manovotn at redhat.com (Matej Novotny) Date: Mon, 11 Jul 2016 03:44:44 -0400 (EDT) Subject: [cdi-dev] Will you attend today's meeting In-Reply-To: References: Message-ID: <322614038.4783726.1468223084060.JavaMail.zimbra@redhat.com> Hi, seems like whole Weld team was on a PTO (also there were two public holidays in Czech rep. last week). Once I make my way through pile of emails, I'll get back to this issue and see if I can shed some light on that. I should be available for meeting this week (and Tomas probably as well?). Matej ----- Original Message ----- > From: "John D. Ament" > To: "Antoine Sabot-Durand" , "cdi-dev" > Sent: Thursday, July 7, 2016 5:40:14 PM > Subject: Re: [cdi-dev] Will you attend today's meeting > > I'll attend if some of the weld team can attend. > > On Thu, Jul 7, 2016 at 11:01 AM Antoine Sabot-Durand < > antoine at sabot-durand.net > wrote: > > > > Hi all, > > So we have this planned meeting in one hour to discuss John PR: > https://github.com/cdi-spec/cdi/pull/296 > > Who will join it ? > > 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 issues at jboss.org Mon Jul 11 04:01:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 11 Jul 2016 04:01:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-623) Specify what happens when calling addObserverMethod or addBean alone In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13263520#comment-13263520 ] Matej Novotny commented on CDI-623: ----------------------------------- Are you talking about the spec doc or javadoc? It seems to me that the [javadoc|https://github.com/cdi-spec/cdi/blob/2.0-EDR2/api/src/main/java/javax/enterprise/inject/spi/AfterBeanDiscovery.java#L82] is pretty clear on this. The configuration is not reusable and that was talked through a thousand times. The idea is that every call of {{abd.add*()}} gives you a new configurator and once you exit the observer method call, it will create a respective bean or observer method. I cannot really see any 'dangling' configuration in this flow. Could you elaborate a bit please? > Specify what happens when calling addObserverMethod or addBean alone > -------------------------------------------------------------------- > > Key: CDI-623 > URL: https://issues.jboss.org/browse/CDI-623 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > > AfterBeanDiscovery exposes methods addObserverMethod and addBean. Both essentially leave dangling configurations that are not usable. > I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From manovotn at redhat.com Mon Jul 11 05:01:53 2016 From: manovotn at redhat.com (Matej Novotny) Date: Mon, 11 Jul 2016 05:01:53 -0400 (EDT) Subject: [cdi-dev] [VOTE] Name the class that can start/stop contexts In-Reply-To: References: Message-ID: <1616475709.4816174.1468227713774.JavaMail.zimbra@redhat.com> +1 for ManageableContext Personally I would still have UnmanagedContext, but since that seems ambiguous (as does ManagedContext), I chose ManageableContext. Matej ----- Original Message ----- > From: "John D. Ament" > To: cdi-dev at lists.jboss.org > Sent: Monday, July 11, 2016 2:50:23 AM > Subject: [cdi-dev] [VOTE] Name the class that can start/stop contexts > > All, > > It seems like one of the remaining issues with CDI-30 is the name for the > class for the context management. This name isn't permanent, we can change > after EDR2, but not after final. > > Here's the proposed renames for "UnmanagedContext": > > - ManagedContext > - ManageableContext > - ProgrammaticContext > - ExternallyManagedContext > - UserManagedContext > > Please respond back with your vote, I'll leave this open for 3 days ( I > believe its Monday morning in central Europe), so I'll close it Thursday > morning. > > Reference: > http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2016/cdi-dev.2016-07-07-16.03.log.html > > - 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. From antoine at sabot-durand.net Mon Jul 11 09:10:21 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 11 Jul 2016 13:10:21 +0000 Subject: [cdi-dev] [VOTE] Name the class that can start/stop contexts In-Reply-To: <1616475709.4816174.1468227713774.JavaMail.zimbra@redhat.com> References: <1616475709.4816174.1468227713774.JavaMail.zimbra@redhat.com> Message-ID: +1 for UserManagedContext, it says clearly that user is in charge of managing the context. ManageableContext is ok as fallback to me but the fact the the context is manageable does not says anything about who has the responsibility to manage it. Le lun. 11 juil. 2016 ? 11:02, Matej Novotny a ?crit : > +1 for ManageableContext > > Personally I would still have UnmanagedContext, but since that seems > ambiguous (as does ManagedContext), > I chose ManageableContext. > > Matej > > ----- Original Message ----- > > From: "John D. Ament" > > To: cdi-dev at lists.jboss.org > > Sent: Monday, July 11, 2016 2:50:23 AM > > Subject: [cdi-dev] [VOTE] Name the class that can start/stop contexts > > > > All, > > > > It seems like one of the remaining issues with CDI-30 is the name for the > > class for the context management. This name isn't permanent, we can > change > > after EDR2, but not after final. > > > > Here's the proposed renames for "UnmanagedContext": > > > > - ManagedContext > > - ManageableContext > > - ProgrammaticContext > > - ExternallyManagedContext > > - UserManagedContext > > > > Please respond back with your vote, I'll leave this open for 3 days ( I > > believe its Monday morning in central Europe), so I'll close it Thursday > > morning. > > > > Reference: > > > http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2016/cdi-dev.2016-07-07-16.03.log.html > > > > - 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. > _______________________________________________ > 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/20160711/eb7168b0/attachment.html From stephan at knitelius.com Mon Jul 11 09:15:21 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Mon, 11 Jul 2016 13:15:21 +0000 Subject: [cdi-dev] [VOTE] Name the class that can start/stop contexts In-Reply-To: <1616475709.4816174.1468227713774.JavaMail.zimbra@redhat.com> References: <1616475709.4816174.1468227713774.JavaMail.zimbra@redhat.com> Message-ID: +1 ManagedContext On Mon, 11 Jul 2016 at 11:02 Matej Novotny wrote: > +1 for ManageableContext > > Personally I would still have UnmanagedContext, but since that seems > ambiguous (as does ManagedContext), > I chose ManageableContext. > > Matej > > ----- Original Message ----- > > From: "John D. Ament" > > To: cdi-dev at lists.jboss.org > > Sent: Monday, July 11, 2016 2:50:23 AM > > Subject: [cdi-dev] [VOTE] Name the class that can start/stop contexts > > > > All, > > > > It seems like one of the remaining issues with CDI-30 is the name for the > > class for the context management. This name isn't permanent, we can > change > > after EDR2, but not after final. > > > > Here's the proposed renames for "UnmanagedContext": > > > > - ManagedContext > > - ManageableContext > > - ProgrammaticContext > > - ExternallyManagedContext > > - UserManagedContext > > > > Please respond back with your vote, I'll leave this open for 3 days ( I > > believe its Monday morning in central Europe), so I'll close it Thursday > > morning. > > > > Reference: > > > http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2016/cdi-dev.2016-07-07-16.03.log.html > > > > - 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. > _______________________________________________ > 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/20160711/18b545d4/attachment-0001.html From antoine at sabot-durand.net Mon Jul 11 09:56:10 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 11 Jul 2016 13:56:10 +0000 Subject: [cdi-dev] In F2F meeting all week Message-ID: Hi All, I'll be at a Red Hat F2F meeting from tomorrow to Friday. I'll check my mail but won't be available for our meeting. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160711/67f03909/attachment.html From john.d.ament at gmail.com Mon Jul 11 14:55:27 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 11 Jul 2016 18:55:27 +0000 Subject: [cdi-dev] In F2F meeting all week In-Reply-To: References: Message-ID: Hi Antoine, Are you saying that tomorrow's meeting is canceled? John On Mon, Jul 11, 2016 at 9:57 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi All, > > I'll be at a Red Hat F2F meeting from tomorrow to Friday. I'll check my > mail but won't be available for our meeting. > > 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/20160711/d3826074/attachment.html From antoine at sabot-durand.net Mon Jul 11 15:12:13 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 11 Jul 2016 19:12:13 +0000 Subject: [cdi-dev] In F2F meeting all week In-Reply-To: References: Message-ID: Yes, it is. Le lun. 11 juil. 2016 ? 20:55, John D. Ament a ?crit : > Hi Antoine, > > Are you saying that tomorrow's meeting is canceled? > > John > > On Mon, Jul 11, 2016 at 9:57 AM Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi All, >> >> I'll be at a Red Hat F2F meeting from tomorrow to Friday. I'll check my >> mail but won't be available for our meeting. >> >> 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/20160711/2968dded/attachment.html From EMIJIANG at uk.ibm.com Mon Jul 11 18:23:26 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Mon, 11 Jul 2016 23:23:26 +0100 Subject: [cdi-dev] [VOTE] Name the class that can start/stop contexts In-Reply-To: References: <1616475709.4816174.1468227713774.JavaMail.zimbra@redhat.com> Message-ID: We are trying to find a better name than UnManagedContext. ManagedContext is surely opposite to the option UnManagedContext:o. ManagableContext fits well with AlternableContext. In addition, ManagableContext should be managed by others, which is the same as UserManagedContext and it is shorter. Hence, +1 for ManagableContext. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Antoine Sabot-Durand To: Matej Novotny , "John D. Ament" , Cc: cdi-dev at lists.jboss.org Date: 11/07/2016 15:12 Subject: Re: [cdi-dev] [VOTE] Name the class that can start/stop contexts Sent by: cdi-dev-bounces at lists.jboss.org +1 for UserManagedContext, it says clearly that user is in charge of managing the context. ManageableContext is ok as fallback to me but the fact the the context is manageable does not says anything about who has the responsibility to manage it. Le lun. 11 juil. 2016 ? 11:02, Matej Novotny a ?crit : +1 for ManageableContext Personally I would still have UnmanagedContext, but since that seems ambiguous (as does ManagedContext), I chose ManageableContext. Matej ----- Original Message ----- > From: "John D. Ament" > To: cdi-dev at lists.jboss.org > Sent: Monday, July 11, 2016 2:50:23 AM > Subject: [cdi-dev] [VOTE] Name the class that can start/stop contexts > > All, > > It seems like one of the remaining issues with CDI-30 is the name for the > class for the context management. This name isn't permanent, we can change > after EDR2, but not after final. > > Here's the proposed renames for "UnmanagedContext": > > - ManagedContext > - ManageableContext > - ProgrammaticContext > - ExternallyManagedContext > - UserManagedContext > > Please respond back with your vote, I'll leave this open for 3 days ( I > believe its Monday morning in central Europe), so I'll close it Thursday > morning. > > Reference: > http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2016/cdi-dev.2016-07-07-16.03.log.html > > - 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. _______________________________________________ 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160711/5ce3b60e/attachment-0001.html From issues at jboss.org Tue Jul 12 06:22:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Tue, 12 Jul 2016 06:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-480) Introduce real link between spec doc and TCK In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13264092#comment-13264092 ] Tomas Remes commented on CDI-480: --------------------------------- Can we mark this as resolved now? > Introduce real link between spec doc and TCK > -------------------------------------------- > > Key: CDI-480 > URL: https://issues.jboss.org/browse/CDI-480 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.1.Final > Reporter: Antoine Sabot-Durand > > One of the nicest thing in CDI TCK is the audit files. These XML files (like : https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/resources/tck-audit-cdi.xml) list all challenges coming from the specification and allow to bind a given test to a given challenge thanks to {{@SpecAssertion}} annotation (see https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/definition/name/NameDefinitionTest.java#L54-L55 for instance). > This system is great to know what assertions are broken, retrieve what spec rule is tested from the code and have nice report on spec coverage in TCK. > The only weakness here is that these audit files are only maintained "by hand" when we could (perhaps) have an automatic or semi-automatic way of generating them or at least checking them against the spec. > Since the spec doc is generated with Asciidoctor, this could be done by creating an Asciidoctor macro or extension (not sure of the terminology) and add a meta data set to each rule written in the spec (allowing to have one or more test for one rule). These meta could be used to help generate the xml file for the TCK or at least check that they contains all rules from the spec. > The immediate benefit I see here would be : > # make the spec contributors more concerned about TCK > # reduce the risk of forgetting rules in TCK > # produce a version of the spec with links to TCK test > # reduce the fear of refactoring the spec if needed > > To make short, if this "unification" could be done, it would probably give us more efficiency and improve spec and TCK quality. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Wed Jul 13 03:00:52 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 13 Jul 2016 07:00:52 +0000 Subject: [cdi-dev] Last line before EDR2 Message-ID: Hi All, The release is still in 2 weeks and we have still 2 PR to close. I'm still waiting +1 or feedback on https://github.com/cdi-spec/cdi/pull/290 to merge it or amend it. There is still discussion going on John's PR : https://github.com/cdi-spec/cdi/pull/296 I propose that we set up an hangout meeting on Monday or Tuesday to solve this. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160713/867c47bf/attachment.html From EMIJIANG at uk.ibm.com Wed Jul 13 04:51:58 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Wed, 13 Jul 2016 09:51:58 +0100 Subject: [cdi-dev] Last line before EDR2 In-Reply-To: References: Message-ID: I am off on Monday. Can attend the hangout meeting on Tuesday. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Antoine Sabot-Durand To: cdi-dev , Date: 13/07/2016 08:02 Subject: [cdi-dev] Last line before EDR2 Sent by: cdi-dev-bounces at lists.jboss.org Hi All, The release is still in 2 weeks and we have still 2 PR to close. I'm still waiting +1 or feedback on https://github.com/cdi-spec/cdi/pull/290 to merge it or amend it. There is still discussion going on John's PR : https://github.com/cdi-spec/cdi/pull/296 I propose that we set up an hangout meeting on Monday or Tuesday to solve this. 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160713/49a68ac6/attachment.html From john.d.ament at gmail.com Wed Jul 13 06:44:39 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 13 Jul 2016 10:44:39 +0000 Subject: [cdi-dev] Last line before EDR2 In-Reply-To: References: Message-ID: At this point, I'm fine with #290, though I'm not sure why its introducing travis builds. I hope that no new issues pop up after renaming the class with #296, I plan to push up javadocs and spec changes this evening. John On Wed, Jul 13, 2016 at 3:01 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi All, > > The release is still in 2 weeks and we have still 2 PR to close. > > I'm still waiting +1 or feedback on > https://github.com/cdi-spec/cdi/pull/290 to merge it or amend it. > > There is still discussion going on John's PR : > https://github.com/cdi-spec/cdi/pull/296 > I propose that we set up an hangout meeting on Monday or Tuesday to solve > this. > > 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/20160713/35453e7e/attachment.html From antoine at sabot-durand.net Wed Jul 13 07:20:47 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 13 Jul 2016 11:20:47 +0000 Subject: [cdi-dev] Last line before EDR2 In-Reply-To: References: Message-ID: Travis build was introduced after discovering compilation error in our few tests after se boot refactoring. I plan to let it's introduction as any isolated commit when merging. It doesn't have any impact or API it spec content. Antoine Le mer. 13 juil. 2016 ? 11:44, John D. Ament a ?crit : > At this point, I'm fine with #290, though I'm not sure why its introducing > travis builds. I hope that no new issues pop up after renaming the class > with #296, I plan to push up javadocs and spec changes this evening. > > John > > On Wed, Jul 13, 2016 at 3:01 AM Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi All, >> >> The release is still in 2 weeks and we have still 2 PR to close. >> >> I'm still waiting +1 or feedback on >> https://github.com/cdi-spec/cdi/pull/290 to merge it or amend it. >> >> There is still discussion going on John's PR : >> https://github.com/cdi-spec/cdi/pull/296 >> I propose that we set up an hangout meeting on Monday or Tuesday to solve >> this. >> >> 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/20160713/5f6010e7/attachment-0001.html From john.d.ament at gmail.com Thu Jul 14 22:13:04 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Fri, 15 Jul 2016 02:13:04 +0000 Subject: [cdi-dev] [VOTE] Name the class that can start/stop contexts In-Reply-To: References: <1616475709.4816174.1468227713774.JavaMail.zimbra@redhat.com> Message-ID: All, Thanks for those who voted. 2 votes for ManageableContext 1 vote for ManagedContext 1 vote for UserManagedContext Therefore I'm declaring the winner ManageableContext. John On Mon, Jul 11, 2016 at 6:23 PM Emily Jiang wrote: > We are trying to find a better name than UnManagedContext. > > ManagedContext is surely opposite to the option UnManagedContext:o. > > ManagableContext fits well with AlternableContext. In addition, > ManagableContext should be managed by others, which is the same as > UserManagedContext and it is shorter. > > Hence, +1 for ManagableContext. > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: emijiang at uk.ibm.com > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Antoine Sabot-Durand > To: Matej Novotny , "John D. Ament" < > john.d.ament at gmail.com>, > Cc: cdi-dev at lists.jboss.org > Date: 11/07/2016 15:12 > Subject: Re: [cdi-dev] [VOTE] Name the class that can start/stop > contexts > Sent by: cdi-dev-bounces at lists.jboss.org > ------------------------------ > > > > +1 for UserManagedContext, it says clearly that user is in charge of > managing the context. > ManageableContext is ok as fallback to me but the fact the the context is > manageable does not says anything about who has the responsibility to > manage it. > > > Le lun. 11 juil. 2016 ? 11:02, Matej Novotny <*manovotn at redhat.com* > > a ?crit : > +1 for ManageableContext > > Personally I would still have UnmanagedContext, but since that seems > ambiguous (as does ManagedContext), > I chose ManageableContext. > > Matej > > ----- Original Message ----- > > From: "John D. Ament" <*john.d.ament at gmail.com* > > > > To: *cdi-dev at lists.jboss.org* > > Sent: Monday, July 11, 2016 2:50:23 AM > > Subject: [cdi-dev] [VOTE] Name the class that can start/stop contexts > > > > All, > > > > It seems like one of the remaining issues with CDI-30 is the name for the > > class for the context management. This name isn't permanent, we can > change > > after EDR2, but not after final. > > > > Here's the proposed renames for "UnmanagedContext": > > > > - ManagedContext > > - ManageableContext > > - ProgrammaticContext > > - ExternallyManagedContext > > - UserManagedContext > > > > Please respond back with your vote, I'll leave this open for 3 days ( I > > believe its Monday morning in central Europe), so I'll close it Thursday > > morning. > > > > Reference: > > > *http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2016/cdi-dev.2016-07-07-16.03.log.html* > > > > > - 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. > _______________________________________________ > 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. > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160715/7cfdde8c/attachment.html From john.d.ament at gmail.com Fri Jul 15 18:38:46 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Fri, 15 Jul 2016 22:38:46 +0000 Subject: [cdi-dev] ManageableContext hierarchy Message-ID: All, One of the items from our last conversation was to remove the hierarchy changes for ManageableContext. I'd like to propose that we re-evaluate the hierarchy post EDR2, to avoid too many changes. This is related to CDI-30. If agreed, I can create a follow up ticket. John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160715/8967178a/attachment.html From builds at travis-ci.org Mon Jul 18 05:59:20 2016 From: builds at travis-ci.org (Travis CI) Date: Mon, 18 Jul 2016 09:59:20 +0000 Subject: [cdi-dev] Passed: cdi-spec/cdi#22 (2.0-EDR2 - 5b77f45) In-Reply-To: Message-ID: <578ca878916ce_33f98a949d7bc8168af@17287723-a229-46ff-8c0f-465f15696c07.mail> Build Update for cdi-spec/cdi ------------------------------------- Build: #22 Status: Passed Duration: 8 minutes and 30 seconds Commit: 5b77f45 (2.0-EDR2) Author: Antoine Sabot-Durand Message: Adding travis CI config View the changeset: https://github.com/cdi-spec/cdi/compare/19a471aa497f...5b77f45d99d5 View the full build log and details: https://travis-ci.org/cdi-spec/cdi/builds/145494191 -- You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160718/f2041438/attachment-0001.html From antoine at sabot-durand.net Mon Jul 18 06:24:42 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 18 Jul 2016 10:24:42 +0000 Subject: [cdi-dev] Are we ok for an hangout meeting tomorrow in place of IRC meeting ? Message-ID: Hi All, To close PR 290 and work out different POV on PR 296, do we agree to have a video meeting tomorrow in place of our IRC meeting. John and Martin must of course agree since their different pov is the origin of the meeting. Thx, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160718/566fdaf7/attachment.html From john.d.ament at gmail.com Mon Jul 18 06:36:47 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 18 Jul 2016 10:36:47 +0000 Subject: [cdi-dev] Are we ok for an hangout meeting tomorrow in place of IRC meeting ? In-Reply-To: References: Message-ID: Probably not available sorry. Personally, if there are still issues with the class hierarchy, I'd like to continue on the email thread I started. John On Mon, Jul 18, 2016 at 6:25 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi All, > > To close PR 290 and work out different POV on PR 296, do we agree to have > a video meeting tomorrow in place of our IRC meeting. > > John and Martin must of course agree since their different pov is the > origin of the meeting. > > Thx, > > 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/20160718/4e65b9c2/attachment.html From john.d.ament at gmail.com Mon Jul 18 07:19:08 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 18 Jul 2016 11:19:08 +0000 Subject: [cdi-dev] Hierarchy of ManageableContext and Context Message-ID: All, I'm starting a discussion thread outside of the PR to avoid folks on the EG not receiving github notifications. I want to drive to get the opinions of the broader EG and use this as feedback on whether or not we change the hierarchy. I've been against having ManageableContext (MC) extend Context/AlterableContext (AC). There's a few reasons. First, semantically I can register a context, but I shouldn't be able to register a MC. That means from an inheritance standpoint MC does not pass the is-a check on AC. MC may be a composition style, or nothing at all since it may not be associated to any specific thread in the future. While we can put in spec verbiage and exceptions to cover the cases where someone does implement MC and try to register it, realistically if it's there as a compilation time option, I shouldn't get an error if it passes. I can agree that the bulk of the methods on MC should match AC. That's where I introduced a new base class for the two and had MC extend that. The base class provided no behavior, just method signatures. The second key thing for me is in this area. AC is more like a definition, where as MC is a running instance of that definition. Since these are different, it shows that MC doesn't inherit the use-case of the parent AC. Third issue I have with extending is that AC is meant to be implemented by developers to create custom contexts. Developers aren't intended to implement MC. The container should provide these instances, since they are intended only for built in contexts. We allow developers who implement AC to control their activation, as a result we've already provided a means to disassociate a custom AC from any thread. I want to get others opinions on whether these reasons make sense and if they guide to the same conclusion about not extending AC. For what its worth, I've shown these classes to some of my own developers to get their feedback, who have had to do things like quartz integration or responding to netty requests and activate contexts. The concerns I raise are based on questions they've asked me. John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160718/6360f2e9/attachment.html From antoine at sabot-durand.net Mon Jul 18 09:15:28 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 18 Jul 2016 13:15:28 +0000 Subject: [cdi-dev] How will attend tomorrow's meeting on IRC Message-ID: Hi all, As it's summer time, I'm checking who'll be availabale for our tomorrow's meeting (video's meeting being canceled). Thx to answer. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160718/ba97d520/attachment.html From mkouba at redhat.com Mon Jul 18 09:19:43 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 18 Jul 2016 15:19:43 +0200 Subject: [cdi-dev] How will attend tomorrow's meeting on IRC In-Reply-To: References: Message-ID: <578CD76F.8@redhat.com> I will be there. Martin Dne 18.7.2016 v 15:15 Antoine Sabot-Durand napsal(a): > Hi all, > > As it's summer time, I'm checking who'll be availabale for our > tomorrow's meeting (video's meeting being canceled). Thx to answer. > > 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. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From john.d.ament at gmail.com Mon Jul 18 09:20:10 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 18 Jul 2016 09:20:10 -0400 Subject: [cdi-dev] How will attend tomorrow's meeting on IRC In-Reply-To: References: Message-ID: Unfortunately I had a family issue on Friday which is now consuming much of this week. On Jul 18, 2016 09:16, "Antoine Sabot-Durand" wrote: > Hi all, > > As it's summer time, I'm checking who'll be availabale for our tomorrow's > meeting (video's meeting being canceled). Thx to answer. > > 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/20160718/2d8da2ca/attachment.html From werner.keil at gmail.com Mon Jul 18 09:36:51 2016 From: werner.keil at gmail.com (Werner Keil) Date: Mon, 18 Jul 2016 15:36:51 +0200 Subject: [cdi-dev] [VOTE] Name the class that can start/stop contexts Message-ID: Seems the vote got swamped among many other messages both here and in my mailbox;-O The arguments leading towards the winning name sound good and logical, so that would be my vote, too. Werner On Mon, Jul 18, 2016 at 12:02 PM, wrote: > Send cdi-dev mailing list submissions to > cdi-dev at lists.jboss.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.jboss.org/mailman/listinfo/cdi-dev > or, via email, send a message with subject or body 'help' to > cdi-dev-request at lists.jboss.org > > You can reach the person managing the list at > cdi-dev-owner at lists.jboss.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cdi-dev digest..." > > > Today's Topics: > > 1. Re: [VOTE] Name the class that can start/stop contexts > (John D. Ament) > 2. ManageableContext hierarchy (John D. Ament) > 3. Passed: cdi-spec/cdi#22 (2.0-EDR2 - 5b77f45) (Travis CI) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 15 Jul 2016 02:13:04 +0000 > From: "John D. Ament" > Subject: Re: [cdi-dev] [VOTE] Name the class that can start/stop > contexts > To: Emily Jiang , Antoine Sabot-Durand > > Cc: cdi-dev at lists.jboss.org > Message-ID: > < > CAOqetn_E0u6HCOyb5mm7hv-NRqxBKjwykz7v1YW0ynvYxtZPBw at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > All, > > Thanks for those who voted. > > 2 votes for ManageableContext > 1 vote for ManagedContext > 1 vote for UserManagedContext > > Therefore I'm declaring the winner ManageableContext. > > John > > On Mon, Jul 11, 2016 at 6:23 PM Emily Jiang wrote: > > > We are trying to find a better name than UnManagedContext. > > > > ManagedContext is surely opposite to the option UnManagedContext:o. > > > > ManagableContext fits well with AlternableContext. In addition, > > ManagableContext should be managed by others, which is the same as > > UserManagedContext and it is shorter. > > > > Hence, +1 for ManagableContext. > > > > Many thanks, > > Emily > > =========================== > > Emily Jiang > > WebSphere Application Server, CDI Development Lead > > > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > > Phone: +44 (0)1962 816278 Internal: 246278 > > > > Email: emijiang at uk.ibm.com > > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > > > > > > From: Antoine Sabot-Durand > > To: Matej Novotny , "John D. Ament" < > > john.d.ament at gmail.com>, > > Cc: cdi-dev at lists.jboss.org > > Date: 11/07/2016 15:12 > > Subject: Re: [cdi-dev] [VOTE] Name the class that can start/stop > > contexts > > Sent by: cdi-dev-bounces at lists.jboss.org > > ------------------------------ > > > > > > > > +1 for UserManagedContext, it says clearly that user is in charge of > > managing the context. > > ManageableContext is ok as fallback to me but the fact the the context is > > manageable does not says anything about who has the responsibility to > > manage it. > > > > > > Le lun. 11 juil. 2016 ? 11:02, Matej Novotny <*manovotn at redhat.com* > > > a ?crit : > > +1 for ManageableContext > > > > Personally I would still have UnmanagedContext, but since that seems > > ambiguous (as does ManagedContext), > > I chose ManageableContext. > > > > Matej > > > > ----- Original Message ----- > > > From: "John D. Ament" <*john.d.ament at gmail.com* < > john.d.ament at gmail.com> > > > > > > To: *cdi-dev at lists.jboss.org* > > > Sent: Monday, July 11, 2016 2:50:23 AM > > > Subject: [cdi-dev] [VOTE] Name the class that can start/stop contexts > > > > > > All, > > > > > > It seems like one of the remaining issues with CDI-30 is the name for > the > > > class for the context management. This name isn't permanent, we can > > change > > > after EDR2, but not after final. > > > > > > Here's the proposed renames for "UnmanagedContext": > > > > > > - ManagedContext > > > - ManageableContext > > > - ProgrammaticContext > > > - ExternallyManagedContext > > > - UserManagedContext > > > > > > Please respond back with your vote, I'll leave this open for 3 days ( I > > > believe its Monday morning in central Europe), so I'll close it > Thursday > > > morning. > > > > > > Reference: > > > > > * > http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2016/cdi-dev.2016-07-07-16.03.log.html* > > < > http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2016/cdi-dev.2016-07-07-16.03.log.html > > > > > > > > - 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. > > _______________________________________________ > > 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. > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20160715/7cfdde8c/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Fri, 15 Jul 2016 22:38:46 +0000 > From: "John D. Ament" > Subject: [cdi-dev] ManageableContext hierarchy > To: "cdi-dev at lists.jboss.org" > Message-ID: > UyFm2Ng at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > All, > > One of the items from our last conversation was to remove the hierarchy > changes for ManageableContext. > > I'd like to propose that we re-evaluate the hierarchy post EDR2, to avoid > too many changes. This is related to CDI-30. > > If agreed, I can create a follow up ticket. > > John > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20160715/8967178a/attachment-0001.html > > ------------------------------ > > Message: 3 > Date: Mon, 18 Jul 2016 09:59:20 +0000 > From: Travis CI > Subject: [cdi-dev] Passed: cdi-spec/cdi#22 (2.0-EDR2 - 5b77f45) > To: > Message-ID: > > <578ca878916ce_33f98a949d7bc8168af at 17287723-a229-46ff-8c0f-465f15696c07.mail > > > > Content-Type: text/plain; charset="utf-8" > > Build Update for cdi-spec/cdi > ------------------------------------- > > Build: #22 > Status: Passed > > Duration: 8 minutes and 30 seconds > Commit: 5b77f45 (2.0-EDR2) > Author: Antoine Sabot-Durand > Message: Adding travis CI config > > View the changeset: > https://github.com/cdi-spec/cdi/compare/19a471aa497f...5b77f45d99d5 > > View the full build log and details: > https://travis-ci.org/cdi-spec/cdi/builds/145494191 > > -- > > You can configure recipients for build notifications in your .travis.yml > file. See https://docs.travis-ci.com/user/notifications > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20160718/f2041438/attachment.html > > ------------------------------ > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > End of cdi-dev Digest, Vol 68, Issue 8 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160718/e9bb7264/attachment-0001.html From stephan at knitelius.com Mon Jul 18 10:03:50 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Mon, 18 Jul 2016 14:03:50 +0000 Subject: [cdi-dev] How will attend tomorrow's meeting on IRC In-Reply-To: References: Message-ID: I can't make it either. On Mon, 18 Jul 2016 at 15:21 John D. Ament wrote: > Unfortunately I had a family issue on Friday which is now consuming much > of this week. > > On Jul 18, 2016 09:16, "Antoine Sabot-Durand" > wrote: > >> Hi all, >> >> As it's summer time, I'm checking who'll be availabale for our tomorrow's >> meeting (video's meeting being canceled). Thx to answer. >> >> 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/20160718/b58d3cdb/attachment.html From issues at jboss.org Tue Jul 19 02:57:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 19 Jul 2016 02:57:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-620) Not clear what the id for an annotated type is. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267200#comment-13267200 ] Martin Kouba commented on CDI-620: ---------------------------------- Yep, the ordering of {{AfterTypeDiscovery.addAnnotatedType(String, Class)}} should be the same as {{AfterTypeDiscovery.addAnnotatedType(AnnotatedType, String)}}. The identifier is used to distinguish multiple AnnotatedTypes per the same Java class. See also the javadoc: {quote} This method allows multiple annotated types, based on the same underlying type, to be defined. {{AnnotatedType}}s discovered by the container use the fully qualified class name of {{AnnotatedType#getJavaClass()}} to identify the type. {quote} For more details see also https://issues.jboss.org/browse/CDI-58. WRT impl. detail of {{AfterTypeDiscovery.addAnnotatedType(AnnotatedType, String)}} - Weld generates a unique id for an annotated type if the id is null. > Not clear what the id for an annotated type is. > ----------------------------------------------- > > Key: CDI-620 > URL: https://issues.jboss.org/browse/CDI-620 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > > The docs for AfterTypeDiscovery.addAnnotatedType(String, Class) do not state what the id is. > In addition, it's odd that the addAnnotatedType(AnnotatedType, String) is in that order, and this method is in this order. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Jul 19 03:00:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 19 Jul 2016 03:00:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-620) Not clear what the id for an annotated type is. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-620: ----------------------------- Fix Version/s: 2.0-EDR2 > Not clear what the id for an annotated type is. > ----------------------------------------------- > > Key: CDI-620 > URL: https://issues.jboss.org/browse/CDI-620 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > Fix For: 2.0-EDR2 > > > The docs for AfterTypeDiscovery.addAnnotatedType(String, Class) do not state what the id is. > In addition, it's odd that the addAnnotatedType(AnnotatedType, String) is in that order, and this method is in this order. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From stephan at knitelius.com Tue Jul 19 03:24:18 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Tue, 19 Jul 2016 07:24:18 +0000 Subject: [cdi-dev] CDI-616 Injection point declared as transient is not useful Message-ID: Hi, I frequently encounter injections marked transient in client projects. I really think it would be of great help if we where to define Error/Warning when injection fields are marked transient. As Mark pointed out there may be a valid use cases for non normal-scoped bean injections to be made transient. My suggestion is: - ERROR - when normal scoped injects are marked transient. - WARNING - when non-normal scoped injects are marked transient. Looking forward to your feedback. Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160719/c814081e/attachment.html From mkouba at redhat.com Tue Jul 19 03:26:25 2016 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 19 Jul 2016 09:26:25 +0200 Subject: [cdi-dev] Hierarchy of ManageableContext and Context In-Reply-To: References: Message-ID: <3907dd7e-2cf9-a7c4-6a7e-5f12aa15b0dc@redhat.com> Hi John, I don't see a problem if we introduce a ManageableContext interface (with activate/deactivate) and a custom context implements it. In other words, I don't think it has to be used only for built-in contexts. Also the context definition is clear (6.2. The Context interface) and again, if these are two different things then we should not call it a context at all [1]. Martin [1] https://github.com/cdi-spec/cdi/pull/296#issuecomment-229942823 Dne 18.7.2016 v 13:19 John D. Ament napsal(a): > All, > > I'm starting a discussion thread outside of the PR to avoid folks on the > EG not receiving github notifications. I want to drive to get the > opinions of the broader EG and use this as feedback on whether or not we > change the hierarchy. > > I've been against having ManageableContext (MC) extend > Context/AlterableContext (AC). There's a few reasons. First, > semantically I can register a context, but I shouldn't be able to > register a MC. That means from an inheritance standpoint MC does not > pass the is-a check on AC. MC may be a composition style, or nothing at > all since it may not be associated to any specific thread in the > future. While we can put in spec verbiage and exceptions to cover the > cases where someone does implement MC and try to register it, > realistically if it's there as a compilation time option, I shouldn't > get an error if it passes. > > I can agree that the bulk of the methods on MC should match AC. That's > where I introduced a new base class for the two and had MC extend that. > The base class provided no behavior, just method signatures. The second > key thing for me is in this area. AC is more like a definition, where > as MC is a running instance of that definition. Since these are > different, it shows that MC doesn't inherit the use-case of the parent AC. > > Third issue I have with extending is that AC is meant to be implemented > by developers to create custom contexts. Developers aren't intended to > implement MC. The container should provide these instances, since they > are intended only for built in contexts. We allow developers who > implement AC to control their activation, as a result we've already > provided a means to disassociate a custom AC from any thread. > > I want to get others opinions on whether these reasons make sense and if > they guide to the same conclusion about not extending AC. For what its > worth, I've shown these classes to some of my own developers to get > their feedback, who have had to do things like quartz integration or > responding to netty requests and activate contexts. The concerns I > raise are based on questions they've asked me. > > 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. > From EMIJIANG at uk.ibm.com Tue Jul 19 05:43:39 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Tue, 19 Jul 2016 10:43:39 +0100 Subject: [cdi-dev] How will attend tomorrow's meeting on IRC In-Reply-To: <578CD76F.8@redhat.com> References: <578CD76F.8@redhat.com> Message-ID: I will attend. Is it irc then? Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Martin Kouba To: cdi-dev at lists.jboss.org, Date: 18/07/2016 14:20 Subject: Re: [cdi-dev] How will attend tomorrow's meeting on IRC Sent by: cdi-dev-bounces at lists.jboss.org I will be there. Martin Dne 18.7.2016 v 15:15 Antoine Sabot-Durand napsal(a): > Hi all, > > As it's summer time, I'm checking who'll be availabale for our > tomorrow's meeting (video's meeting being canceled). Thx to answer. > > 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. > -- 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160719/6a9458a7/attachment-0001.html From EMIJIANG at uk.ibm.com Tue Jul 19 05:43:39 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Tue, 19 Jul 2016 10:43:39 +0100 Subject: [cdi-dev] Hierarchy of ManageableContext and Context In-Reply-To: <3907dd7e-2cf9-a7c4-6a7e-5f12aa15b0dc@redhat.com> References: <3907dd7e-2cf9-a7c4-6a7e-5f12aa15b0dc@redhat.com> Message-ID: +1 on creating a separate interface. If ManagedContext is not a context, I agree with Martin to give it a different name. How about ManagableState etc? Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Martin Kouba To: cdi-dev at lists.jboss.org, Date: 19/07/2016 08:28 Subject: Re: [cdi-dev] Hierarchy of ManageableContext and Context Sent by: cdi-dev-bounces at lists.jboss.org Hi John, I don't see a problem if we introduce a ManageableContext interface (with activate/deactivate) and a custom context implements it. In other words, I don't think it has to be used only for built-in contexts. Also the context definition is clear (6.2. The Context interface) and again, if these are two different things then we should not call it a context at all [1]. Martin [1] https://github.com/cdi-spec/cdi/pull/296#issuecomment-229942823 Dne 18.7.2016 v 13:19 John D. Ament napsal(a): > All, > > I'm starting a discussion thread outside of the PR to avoid folks on the > EG not receiving github notifications. I want to drive to get the > opinions of the broader EG and use this as feedback on whether or not we > change the hierarchy. > > I've been against having ManageableContext (MC) extend > Context/AlterableContext (AC). There's a few reasons. First, > semantically I can register a context, but I shouldn't be able to > register a MC. That means from an inheritance standpoint MC does not > pass the is-a check on AC. MC may be a composition style, or nothing at > all since it may not be associated to any specific thread in the > future. While we can put in spec verbiage and exceptions to cover the > cases where someone does implement MC and try to register it, > realistically if it's there as a compilation time option, I shouldn't > get an error if it passes. > > I can agree that the bulk of the methods on MC should match AC. That's > where I introduced a new base class for the two and had MC extend that. > The base class provided no behavior, just method signatures. The second > key thing for me is in this area. AC is more like a definition, where > as MC is a running instance of that definition. Since these are > different, it shows that MC doesn't inherit the use-case of the parent AC. > > Third issue I have with extending is that AC is meant to be implemented > by developers to create custom contexts. Developers aren't intended to > implement MC. The container should provide these instances, since they > are intended only for built in contexts. We allow developers who > implement AC to control their activation, as a result we've already > provided a means to disassociate a custom AC from any thread. > > I want to get others opinions on whether these reasons make sense and if > they guide to the same conclusion about not extending AC. For what its > worth, I've shown these classes to some of my own developers to get > their feedback, who have had to do things like quartz integration or > responding to netty requests and activate contexts. The concerns I > raise are based on questions they've asked me. > > 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. > _______________________________________________ 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160719/920034bd/attachment.html From EMIJIANG at uk.ibm.com Tue Jul 19 06:12:12 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Tue, 19 Jul 2016 11:12:12 +0100 Subject: [cdi-dev] CDI-616 Injection point declared as transient is not useful In-Reply-To: References: Message-ID: If we define an error, we will introduce a backward compatibility issue. Some app will stop starting. Will this cause a big problem? If this is not a concern, +1 on defining a DefinitionError on this case: ERROR - when normal scoped injects are marked transient. and a warning on WARNING - when non-normal scoped injects are marked transient. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Stephan Knitelius To: cdi-dev , Date: 19/07/2016 08:26 Subject: [cdi-dev] CDI-616 Injection point declared as transient is not useful Sent by: cdi-dev-bounces at lists.jboss.org Hi, I frequently encounter injections marked transient in client projects. I really think it would be of great help if we where to define Error/Warning when injection fields are marked transient. As Mark pointed out there may be a valid use cases for non normal-scoped bean injections to be made transient. My suggestion is: ERROR - when normal scoped injects are marked transient. WARNING - when non-normal scoped injects are marked transient. Looking forward to your feedback. Stephan_______________________________________________ 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160719/681e6ed4/attachment.html From stephan at knitelius.com Tue Jul 19 06:52:16 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Tue, 19 Jul 2016 10:52:16 +0000 Subject: [cdi-dev] CDI-616 Injection point declared as transient is not useful In-Reply-To: References: Message-ID: Yes it will cause start up issues for applications which define transient normal scoped injections, however these Apps currently have runtime issues after dezieralization of passivatable scoped bean. Trading an easily fixable start-up issue for a hard to reproduce runtime issue seems like a good trade off to me. Stephan On Tue, 19 Jul 2016 at 12:12 Emily Jiang wrote: > If we define an error, we will introduce a backward compatibility issue. > Some app will stop starting. Will this cause a big problem? If this is not > a concern, +1 on defining a DefinitionError on this case: ERROR - when > normal scoped injects are marked transient. and a warning on WARNING - > when non-normal scoped injects are marked transient. > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: emijiang at uk.ibm.com > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Stephan Knitelius > To: cdi-dev , > Date: 19/07/2016 08:26 > Subject: [cdi-dev] CDI-616 Injection point declared as transient > is not useful > Sent by: cdi-dev-bounces at lists.jboss.org > ------------------------------ > > > > Hi, > > I frequently encounter injections marked transient in client projects. I > really think it would be of great help if we where to define Error/Warning > when injection fields are marked transient. > > As Mark pointed out there may be a valid use cases for non normal-scoped > bean injections to be made transient. > > My suggestion is: > > - ERROR - when normal scoped injects are marked transient. > > > - > - WARNING - when non-normal scoped injects are marked transient. > > Looking forward to your feedback. > > > > - > - Stephan_______________________________________________ > 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. > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160719/a56bee1f/attachment-0001.html From manovotn at redhat.com Tue Jul 19 08:14:23 2016 From: manovotn at redhat.com (Matej Novotny) Date: Tue, 19 Jul 2016 08:14:23 -0400 (EDT) Subject: [cdi-dev] Hierarchy of ManageableContext and Context In-Reply-To: <3907dd7e-2cf9-a7c4-6a7e-5f12aa15b0dc@redhat.com> References: <3907dd7e-2cf9-a7c4-6a7e-5f12aa15b0dc@redhat.com> Message-ID: <1370759534.7346639.1468930463355.JavaMail.zimbra@redhat.com> Hi all, here are my two cents on this (pretty much covered that in the PR comments, just didn't get much attention there): * I am also standing behind the idea to keep ManageableContext (MC) in the current hierarchy. It should extend AlterableContext and obviously we will need to add activate/deactivate methods there. ** In short... Yes, I see this as a _Context_ :) * As an entry point, BeanManager seems a good way. ** BM.getContext() can stay as it is now, therefore we won't break any compatibility. It will return the running context, throw exception otherwise ** We should add BM.getManageableContext (or something along those lines) which will give you an instance of ManageableContext which you can then activate * As for people implementing this on their own (and registering via extension which was the argument against it) ** There might not really be any harm in it; or at least I see none, though I may be missing something ** And if you feel otherwise, we might still change the doc and say that this is forbidden ** Again, such doc change will not cause any backward compatibility because there are not apps which would have it now. Matej ----- Original Message ----- > From: "Martin Kouba" > To: cdi-dev at lists.jboss.org > Sent: Tuesday, July 19, 2016 9:26:25 AM > Subject: Re: [cdi-dev] Hierarchy of ManageableContext and Context > > Hi John, > > I don't see a problem if we introduce a ManageableContext interface > (with activate/deactivate) and a custom context implements it. In other > words, I don't think it has to be used only for built-in contexts. > > Also the context definition is clear (6.2. The Context interface) and > again, if these are two different things then we should not call it a > context at all [1]. > > Martin > > [1] > https://github.com/cdi-spec/cdi/pull/296#issuecomment-229942823 > > > Dne 18.7.2016 v 13:19 John D. Ament napsal(a): > > All, > > > > I'm starting a discussion thread outside of the PR to avoid folks on the > > EG not receiving github notifications. I want to drive to get the > > opinions of the broader EG and use this as feedback on whether or not we > > change the hierarchy. > > > > I've been against having ManageableContext (MC) extend > > Context/AlterableContext (AC). There's a few reasons. First, > > semantically I can register a context, but I shouldn't be able to > > register a MC. That means from an inheritance standpoint MC does not > > pass the is-a check on AC. MC may be a composition style, or nothing at > > all since it may not be associated to any specific thread in the > > future. While we can put in spec verbiage and exceptions to cover the > > cases where someone does implement MC and try to register it, > > realistically if it's there as a compilation time option, I shouldn't > > get an error if it passes. > > > > I can agree that the bulk of the methods on MC should match AC. That's > > where I introduced a new base class for the two and had MC extend that. > > The base class provided no behavior, just method signatures. The second > > key thing for me is in this area. AC is more like a definition, where > > as MC is a running instance of that definition. Since these are > > different, it shows that MC doesn't inherit the use-case of the parent AC. > > > > Third issue I have with extending is that AC is meant to be implemented > > by developers to create custom contexts. Developers aren't intended to > > implement MC. The container should provide these instances, since they > > are intended only for built in contexts. We allow developers who > > implement AC to control their activation, as a result we've already > > provided a means to disassociate a custom AC from any thread. > > > > I want to get others opinions on whether these reasons make sense and if > > they guide to the same conclusion about not extending AC. For what its > > worth, I've shown these classes to some of my own developers to get > > their feedback, who have had to do things like quartz integration or > > responding to netty requests and activate contexts. The concerns I > > raise are based on questions they've asked me. > > > > 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. > > > _______________________________________________ > 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 stephan at knitelius.com Tue Jul 19 08:38:50 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Tue, 19 Jul 2016 12:38:50 +0000 Subject: [cdi-dev] How will attend tomorrow's meeting on IRC In-Reply-To: References: <578CD76F.8@redhat.com> Message-ID: Hi all, what is on the agenda? Think CDI-616 should be discussed sooner or later. I am still not sure if I can make it today, but I think my view and idea on this is pretty clear and Emily opened the ticket to start with anyway. Stephan On Tue, 19 Jul 2016 at 11:44 Emily Jiang wrote: > I will attend. Is it irc then? > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: emijiang at uk.ibm.com > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Martin Kouba > To: cdi-dev at lists.jboss.org, > Date: 18/07/2016 14:20 > Subject: Re: [cdi-dev] How will attend tomorrow's meeting on IRC > Sent by: cdi-dev-bounces at lists.jboss.org > ------------------------------ > > > > I will be there. > > Martin > > Dne 18.7.2016 v 15:15 Antoine Sabot-Durand napsal(a): > > Hi all, > > > > As it's summer time, I'm checking who'll be availabale for our > > tomorrow's meeting (video's meeting being canceled). Thx to answer. > > > > 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. > > > > -- > 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. > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > _______________________________________________ > 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/20160719/22440693/attachment.html From antoine at sabot-durand.net Tue Jul 19 08:51:12 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 19 Jul 2016 12:51:12 +0000 Subject: [cdi-dev] How will attend tomorrow's meeting on IRC In-Reply-To: References: <578CD76F.8@redhat.com> Message-ID: It'll be on irc. Agenda is focused on on PRs since we had to release EDR2 next week. If we have time we'll discuss other tickets. Antoine Le mar. 19 juil. 2016 ? 14:39, Stephan Knitelius a ?crit : > Hi all, > > what is on the agenda? > > Think CDI-616 should be discussed sooner or later. > > I am still not sure if I can make it today, but I think my view and idea > on this is pretty clear and Emily opened the ticket to start with anyway. > > Stephan > > > > > > On Tue, 19 Jul 2016 at 11:44 Emily Jiang wrote: > >> I will attend. Is it irc then? >> >> Many thanks, >> Emily >> =========================== >> Emily Jiang >> WebSphere Application Server, CDI Development Lead >> >> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN >> Phone: +44 (0)1962 816278 Internal: 246278 >> >> Email: emijiang at uk.ibm.com >> Lotus Notes: Emily Jiang/UK/IBM at IBMGB >> >> >> >> >> From: Martin Kouba >> To: cdi-dev at lists.jboss.org, >> Date: 18/07/2016 14:20 >> Subject: Re: [cdi-dev] How will attend tomorrow's meeting on IRC >> Sent by: cdi-dev-bounces at lists.jboss.org >> ------------------------------ >> >> >> >> I will be there. >> >> Martin >> >> Dne 18.7.2016 v 15:15 Antoine Sabot-Durand napsal(a): >> > Hi all, >> > >> > As it's summer time, I'm checking who'll be availabale for our >> > tomorrow's meeting (video's meeting being canceled). Thx to answer. >> > >> > 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. >> > >> >> -- >> 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. >> >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> _______________________________________________ >> 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/20160719/081ce085/attachment-0001.html From mkouba at redhat.com Wed Jul 20 10:36:15 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 20 Jul 2016 16:36:15 +0200 Subject: [cdi-dev] CDI-616 Injection point declared as transient is not useful In-Reply-To: References: Message-ID: Do you suggest to log an ERROR message or to treat it as a definition error? Altough I don't have any real use case, I'm not so sure this should be a definition error. It reminds me unproxyable types with non-private final methods (CDI-527) - right now it is a definition error (and I think it's good) but the EG decided to change this, although it could result in runtime errors (and both Weld and OWB allow to relax this restriction). As to WARNING - the spec currently does not define anything like logging or logging levels. IIRC the only mention is in 10.5. Observer notification: "If the observer method is a transactional observer method, any exception is caught and logged by the container." And I believe we should not introduce logging levels in the spec. Martin Dne 19.7.2016 v 12:52 Stephan Knitelius napsal(a): > Yes it will cause start up issues for applications which define > transient normal scoped injections, however these Apps currently have > runtime issues after dezieralization of passivatable scoped bean. > > Trading an easily fixable start-up issue for a hard to reproduce runtime > issue seems like a good trade off to me. > > Stephan > > > > > > On Tue, 19 Jul 2016 at 12:12 Emily Jiang > wrote: > > If we define an error, we will introduce a backward compatibility > issue. Some app will stop starting. Will this cause a big problem? > If this is not a concern, +1 on defining a DefinitionError on this > case: ERROR - when normal scoped injects are marked transient.and a > warning on WARNING - when non-normal scoped injects are marked > transient. > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: emijiang at uk.ibm.com > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Stephan Knitelius > > To: cdi-dev >, > Date: 19/07/2016 08:26 > Subject: [cdi-dev] CDI-616 Injection point declared as > transient is not useful > Sent by: cdi-dev-bounces at lists.jboss.org > > ------------------------------------------------------------------------ > > > > Hi, > > I frequently encounter injections marked transient in client > projects. I really think it would be of great help if we where to > define Error/Warning when injection fields are marked transient. > > As Mark pointed out there may be a valid use cases for non > normal-scoped bean injections to be made transient. > > My suggestion is: > > * ERROR - when normal scoped injects are marked transient. > > * > * WARNING - when non-normal scoped injects are marked transient. > > Looking forward to your feedback. > > * > * Stephan_______________________________________________ > 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. > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales > with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, > Hampshire PO6 3AU > > > > _______________________________________________ > 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 EMIJIANG at uk.ibm.com Wed Jul 20 11:43:59 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Wed, 20 Jul 2016 16:43:59 +0100 Subject: [cdi-dev] CDI-616 Injection point declared as transient is not useful In-Reply-To: References: Message-ID: I prefer to classify a definition error if when normal scoped injects are marked transient as I agree logging an error or warning are implementation details. I am still struggling to find user case for "non-normal scoped injects are marked transient". If it is not useful and problematic, why don't we just declare a Definition Error if an injection field defined transient? Easy and straightforward. Thoughts? Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Martin Kouba To: cdi-dev at lists.jboss.org, Date: 20/07/2016 15:38 Subject: Re: [cdi-dev] CDI-616 Injection point declared as transient is not useful Sent by: cdi-dev-bounces at lists.jboss.org Do you suggest to log an ERROR message or to treat it as a definition error? Altough I don't have any real use case, I'm not so sure this should be a definition error. It reminds me unproxyable types with non-private final methods (CDI-527) - right now it is a definition error (and I think it's good) but the EG decided to change this, although it could result in runtime errors (and both Weld and OWB allow to relax this restriction). As to WARNING - the spec currently does not define anything like logging or logging levels. IIRC the only mention is in 10.5. Observer notification: "If the observer method is a transactional observer method, any exception is caught and logged by the container." And I believe we should not introduce logging levels in the spec. Martin Dne 19.7.2016 v 12:52 Stephan Knitelius napsal(a): > Yes it will cause start up issues for applications which define > transient normal scoped injections, however these Apps currently have > runtime issues after dezieralization of passivatable scoped bean. > > Trading an easily fixable start-up issue for a hard to reproduce runtime > issue seems like a good trade off to me. > > Stephan > > > > > > On Tue, 19 Jul 2016 at 12:12 Emily Jiang > wrote: > > If we define an error, we will introduce a backward compatibility > issue. Some app will stop starting. Will this cause a big problem? > If this is not a concern, +1 on defining a DefinitionError on this > case: ERROR - when normal scoped injects are marked transient.and a > warning on WARNING - when non-normal scoped injects are marked > transient. > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: emijiang at uk.ibm.com > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Stephan Knitelius > > To: cdi-dev >, > Date: 19/07/2016 08:26 > Subject: [cdi-dev] CDI-616 Injection point declared as > transient is not useful > Sent by: cdi-dev-bounces at lists.jboss.org > > ------------------------------------------------------------------------ > > > > Hi, > > I frequently encounter injections marked transient in client > projects. I really think it would be of great help if we where to > define Error/Warning when injection fields are marked transient. > > As Mark pointed out there may be a valid use cases for non > normal-scoped bean injections to be made transient. > > My suggestion is: > > * ERROR - when normal scoped injects are marked transient. > > * > * WARNING - when non-normal scoped injects are marked transient. > > Looking forward to your feedback. > > * > * Stephan_______________________________________________ > 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. > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales > with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, > Hampshire PO6 3AU > > > > _______________________________________________ > 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160720/c2d8f022/attachment.html From tremes at redhat.com Thu Jul 21 02:12:10 2016 From: tremes at redhat.com (Tomas Remes) Date: Thu, 21 Jul 2016 02:12:10 -0400 (EDT) Subject: [cdi-dev] CDI-616 Injection point declared as transient is not useful In-Reply-To: References: Message-ID: <1747932510.11213872.1469081530157.JavaMail.zimbra@redhat.com> As you said. If we introduce definition error for this it won't be backward compatible so warning could be sufficient I think and therefore (maybe) I wouldn't solve this at specification level but only at implementation level. That's my current feeling. Tom ----- Original Message ----- From: "Emily Jiang" To: "Martin Kouba" Cc: cdi-dev at lists.jboss.org Sent: Wednesday, July 20, 2016 5:43:59 PM Subject: Re: [cdi-dev] CDI-616 Injection point declared as transient is not useful I prefer to classify a definition error if when normal scoped injects are marked transient as I agree logging an error or warning are implementation details. I am still struggling to find user case for "non-normal scoped injects are marked transient". If it is not useful and problematic, why don't we just declare a Definition Error if an injection field defined transient? Easy and straightforward. Thoughts? Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Martin Kouba To: cdi-dev at lists.jboss.org, Date: 20/07/2016 15:38 Subject: Re: [cdi-dev] CDI-616 Injection point declared as transient is not useful Sent by: cdi-dev-bounces at lists.jboss.org Do you suggest to log an ERROR message or to treat it as a definition error? Altough I don't have any real use case, I'm not so sure this should be a definition error. It reminds me unproxyable types with non-private final methods (CDI-527) - right now it is a definition error (and I think it's good) but the EG decided to change this, although it could result in runtime errors (and both Weld and OWB allow to relax this restriction). As to WARNING - the spec currently does not define anything like logging or logging levels. IIRC the only mention is in 10.5. Observer notification: "If the observer method is a transactional observer method, any exception is caught and logged by the container." And I believe we should not introduce logging levels in the spec. Martin Dne 19.7.2016 v 12:52 Stephan Knitelius napsal(a): > Yes it will cause start up issues for applications which define > transient normal scoped injections, however these Apps currently have > runtime issues after dezieralization of passivatable scoped bean. > > Trading an easily fixable start-up issue for a hard to reproduce runtime > issue seems like a good trade off to me. > > Stephan > > > > > > On Tue, 19 Jul 2016 at 12:12 Emily Jiang < mailto:EMIJIANG at uk.ibm.com >> wrote: > > If we define an error, we will introduce a backward compatibility > issue. Some app will stop starting. Will this cause a big problem? > If this is not a concern, +1 on defining a DefinitionError on this > case: ERROR - when normal scoped injects are marked transient.and a > warning on WARNING - when non-normal scoped injects are marked > transient. > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: emijiang at uk.ibm.com < mailto:emijiang at uk.ibm.com > > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Stephan Knitelius < mailto:stephan at knitelius.com >> > To: cdi-dev < mailto:cdi-dev at lists.jboss.org >>, > Date: 19/07/2016 08:26 > Subject: [cdi-dev] CDI-616 Injection point declared as > transient is not useful > Sent by: cdi-dev-bounces at lists.jboss.org > < mailto:cdi-dev-bounces at lists.jboss.org > > ------------------------------------------------------------------------ > > > > Hi, > > I frequently encounter injections marked transient in client > projects. I really think it would be of great help if we where to > define Error/Warning when injection fields are marked transient. > > As Mark pointed out there may be a valid use cases for non > normal-scoped bean injections to be made transient. > > My suggestion is: > > * ERROR - when normal scoped injects are marked transient. > > * > * WARNING - when non-normal scoped injects are marked transient. > > Looking forward to your feedback. > > * > * Stephan_______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org < mailto: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. > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales > with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, > Hampshire PO6 3AU > > > > _______________________________________________ > 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU _______________________________________________ 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 EMIJIANG at uk.ibm.com Thu Jul 21 05:10:34 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Thu, 21 Jul 2016 10:10:34 +0100 Subject: [cdi-dev] CDI-616 Injection point declared as transient is not useful In-Reply-To: <1747932510.11213872.1469081530157.JavaMail.zimbra@redhat.com> References: <1747932510.11213872.1469081530157.JavaMail.zimbra@redhat.com> Message-ID: As Stephen points out if the "when normal scoped injects are marked transient", it will fail at runtime anyway. I am kind of thinking to throw a definition error when injection field marks as transient. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Tomas Remes To: Emily Jiang/UK/IBM at IBMGB, Cc: cdi-dev at lists.jboss.org Date: 21/07/2016 07:13 Subject: Re: [cdi-dev] CDI-616 Injection point declared as transient is not useful Sent by: cdi-dev-bounces at lists.jboss.org As you said. If we introduce definition error for this it won't be backward compatible so warning could be sufficient I think and therefore (maybe) I wouldn't solve this at specification level but only at implementation level. That's my current feeling. Tom ----- Original Message ----- From: "Emily Jiang" To: "Martin Kouba" Cc: cdi-dev at lists.jboss.org Sent: Wednesday, July 20, 2016 5:43:59 PM Subject: Re: [cdi-dev] CDI-616 Injection point declared as transient is not useful I prefer to classify a definition error if when normal scoped injects are marked transient as I agree logging an error or warning are implementation details. I am still struggling to find user case for "non-normal scoped injects are marked transient". If it is not useful and problematic, why don't we just declare a Definition Error if an injection field defined transient? Easy and straightforward. Thoughts? Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Martin Kouba To: cdi-dev at lists.jboss.org, Date: 20/07/2016 15:38 Subject: Re: [cdi-dev] CDI-616 Injection point declared as transient is not useful Sent by: cdi-dev-bounces at lists.jboss.org Do you suggest to log an ERROR message or to treat it as a definition error? Altough I don't have any real use case, I'm not so sure this should be a definition error. It reminds me unproxyable types with non-private final methods (CDI-527) - right now it is a definition error (and I think it's good) but the EG decided to change this, although it could result in runtime errors (and both Weld and OWB allow to relax this restriction). As to WARNING - the spec currently does not define anything like logging or logging levels. IIRC the only mention is in 10.5. Observer notification: "If the observer method is a transactional observer method, any exception is caught and logged by the container." And I believe we should not introduce logging levels in the spec. Martin Dne 19.7.2016 v 12:52 Stephan Knitelius napsal(a): > Yes it will cause start up issues for applications which define > transient normal scoped injections, however these Apps currently have > runtime issues after dezieralization of passivatable scoped bean. > > Trading an easily fixable start-up issue for a hard to reproduce runtime > issue seems like a good trade off to me. > > Stephan > > > > > > On Tue, 19 Jul 2016 at 12:12 Emily Jiang < mailto:EMIJIANG at uk.ibm.com >> wrote: > > If we define an error, we will introduce a backward compatibility > issue. Some app will stop starting. Will this cause a big problem? > If this is not a concern, +1 on defining a DefinitionError on this > case: ERROR - when normal scoped injects are marked transient.and a > warning on WARNING - when non-normal scoped injects are marked > transient. > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: emijiang at uk.ibm.com < mailto:emijiang at uk.ibm.com > > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Stephan Knitelius < mailto:stephan at knitelius.com >> > To: cdi-dev < mailto:cdi-dev at lists.jboss.org >>, > Date: 19/07/2016 08:26 > Subject: [cdi-dev] CDI-616 Injection point declared as > transient is not useful > Sent by: cdi-dev-bounces at lists.jboss.org > < mailto:cdi-dev-bounces at lists.jboss.org > > ------------------------------------------------------------------------ > > > > Hi, > > I frequently encounter injections marked transient in client > projects. I really think it would be of great help if we where to > define Error/Warning when injection fields are marked transient. > > As Mark pointed out there may be a valid use cases for non > normal-scoped bean injections to be made transient. > > My suggestion is: > > * ERROR - when normal scoped injects are marked transient. > > * > * WARNING - when non-normal scoped injects are marked transient. > > Looking forward to your feedback. > > * > * Stephan_______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org < mailto: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. > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales > with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, > Hampshire PO6 3AU > > > > _______________________________________________ > 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU _______________________________________________ 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160721/a34354bc/attachment.html From stephan at knitelius.com Thu Jul 21 05:28:26 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Thu, 21 Jul 2016 09:28:26 +0000 Subject: [cdi-dev] CDI-616 Injection point declared as transient is not useful In-Reply-To: References: <1747932510.11213872.1469081530157.JavaMail.zimbra@redhat.com> Message-ID: +1 on the definition error Emily suggests. Especially since transient will cause exceptions random hard to reproduce exceptions at runtime. Unproxiable Type due to non private final methods and the like will be encountered as soon as some tries to use it during development. In so far its different, since the transient will only cause a problem when passivatable scopes are deserialized, which is unlikely during development and even if it occurs it will be probably be considered as development glitch. Also in my experience implementation specific warnings and the like cause more confusions then anything else. Also in the context in of the application server the console warnings will be lost in the flood of startup outputs. On Thu, 21 Jul 2016 at 11:12 Emily Jiang wrote: > As Stephen points out if the "when normal scoped injects are marked > transient", it will fail at runtime anyway. I am kind of thinking to > throw a definition error when injection field marks as transient. > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: emijiang at uk.ibm.com > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Tomas Remes > To: Emily Jiang/UK/IBM at IBMGB, > Cc: cdi-dev at lists.jboss.org > Date: 21/07/2016 07:13 > Subject: Re: [cdi-dev] CDI-616 Injection point declared as > transient is not useful > Sent by: cdi-dev-bounces at lists.jboss.org > > > > > As you said. If we introduce definition error for this it won't be > backward compatible so warning could be sufficient I think and therefore > (maybe) I wouldn't solve this at specification level but only at > implementation level. That's my current feeling. > > Tom > > ----- Original Message ----- > From: "Emily Jiang" > To: "Martin Kouba" > Cc: cdi-dev at lists.jboss.org > Sent: Wednesday, July 20, 2016 5:43:59 PM > Subject: Re: [cdi-dev] CDI-616 Injection point declared as transient is > not useful > > I prefer to classify a definition error if when normal scoped injects are > marked transient as I agree logging an error or warning are implementation > details. > > I am still struggling to find user case for "non-normal scoped injects are > marked transient". > > If it is not useful and problematic, why don't we just declare a > Definition Error if an injection field defined transient? Easy and > straightforward. Thoughts? > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: emijiang at uk.ibm.com > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Martin Kouba > To: cdi-dev at lists.jboss.org, > Date: 20/07/2016 15:38 > Subject: Re: [cdi-dev] CDI-616 Injection point declared as transient is > not useful > Sent by: cdi-dev-bounces at lists.jboss.org > > > > > Do you suggest to log an ERROR message or to treat it as a definition > error? > > Altough I don't have any real use case, I'm not so sure this should be a > definition error. It reminds me unproxyable types with non-private final > methods (CDI-527) - right now it is a definition error (and I think it's > good) but the EG decided to change this, although it could result in > runtime errors (and both Weld and OWB allow to relax this restriction). > > As to WARNING - the spec currently does not define anything like logging > or logging levels. IIRC the only mention is in 10.5. Observer > notification: > "If the observer method is a transactional observer method, any > exception is caught and logged by the container." > > And I believe we should not introduce logging levels in the spec. > > Martin > > Dne 19.7.2016 v 12:52 Stephan Knitelius napsal(a): > > Yes it will cause start up issues for applications which define > > transient normal scoped injections, however these Apps currently have > > runtime issues after dezieralization of passivatable scoped bean. > > > > Trading an easily fixable start-up issue for a hard to reproduce runtime > > issue seems like a good trade off to me. > > > > Stephan > > > > > > > > > > > > On Tue, 19 Jul 2016 at 12:12 Emily Jiang > < mailto:EMIJIANG at uk.ibm.com >> wrote: > > > > If we define an error, we will introduce a backward compatibility > > issue. Some app will stop starting. Will this cause a big problem? > > If this is not a concern, +1 on defining a DefinitionError on this > > case: ERROR - when normal scoped injects are marked transient.and a > > warning on WARNING - when non-normal scoped injects are marked > > transient. > > > > Many thanks, > > Emily > > =========================== > > Emily Jiang > > WebSphere Application Server, CDI Development Lead > > > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > > Phone: +44 (0)1962 816278 Internal: 246278 > > > > Email: emijiang at uk.ibm.com < mailto:emijiang at uk.ibm.com > > > > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > > > > > > From: Stephan Knitelius > < mailto:stephan at knitelius.com >> > > To: cdi-dev > < mailto:cdi-dev at lists.jboss.org >>, > > Date: 19/07/2016 08:26 > > Subject: [cdi-dev] CDI-616 Injection point declared as > > transient is not useful > > Sent by: cdi-dev-bounces at lists.jboss.org > > < mailto:cdi-dev-bounces at lists.jboss.org > > > > ------------------------------------------------------------------------ > > > > > > > > Hi, > > > > I frequently encounter injections marked transient in client > > projects. I really think it would be of great help if we where to > > define Error/Warning when injection fields are marked transient. > > > > As Mark pointed out there may be a valid use cases for non > > normal-scoped bean injections to be made transient. > > > > My suggestion is: > > > > * ERROR - when normal scoped injects are marked transient. > > > > * > > * WARNING - when non-normal scoped injects are marked transient. > > > > Looking forward to your feedback. > > > > * > > * Stephan_______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org < mailto: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. > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales > > with number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, > > Hampshire PO6 3AU > > > > > > > > _______________________________________________ > > 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. > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > _______________________________________________ > 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. > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > _______________________________________________ > 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/20160721/90fc92b7/attachment-0001.html From antoine at sabot-durand.net Thu Jul 21 10:19:25 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 21 Jul 2016 14:19:25 +0000 Subject: [cdi-dev] F2F preparation Message-ID: Hi all, You'll find all the needed information regarding F2F meeting in the following google doc: https://docs.google.com/document/d/1elWUB8G2deFj4Asch5jjkcfVh2XyGat-_rBrtpEHeVE/edit?usp=sharing I also create a spreadsheet to gather whites regarding agenda for this meeting: https://docs.google.com/spreadsheets/d/1vX3ajo_qDhf_vzZ8P-QZlmJ5Ieel-0Be13f4-SLWig8/edit?usp=sharing Thanks for your feedback, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160721/5c711b49/attachment.html From issues at jboss.org Mon Jul 25 03:21:00 2016 From: issues at jboss.org (Lucas Ventura Carro (JIRA)) Date: Mon, 25 Jul 2016 03:21:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection or intercepted self invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269681#comment-13269681 ] Lucas Ventura Carro commented on CDI-414: ----------------------------------------- {{Instance}} solution from [~paulie-paulie] is memory-leak prone: the produced instances should be destroyed after being used. Is there any plan to introduce the self-interception in next CDI release, in any way? > Support for "self" injection or intercepted self invocation > ----------------------------------------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > Fix For: 2.0 (discussion) > > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From arjan.tijms at gmail.com Tue Jul 26 05:59:08 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 26 Jul 2016 11:59:08 +0200 Subject: [cdi-dev] Enabling programmatic/synthetic decorators added by extension In-Reply-To: References: Message-ID: Hi, Just wondering, has there been any progress made for this topic? Having the ability to dynamically add interceptors and/or add them when building a Bean using the programmatic APIs would still be incredibly useful. Kind regards, Arjan Tijms On Fri, Mar 4, 2016 at 5:18 PM, arjan tijms wrote: > ProxyFactory sounds like a perfect solution indeed. > > I now got something working, more or less, emphasis on less. > > I first make a "normal" (but effectively dummy) decorator with @Priority > available: > > @Decorator > @Priority(PLATFORM_BEFORE + 200) > public abstract class HttpAuthenticationBaseDecorator implements > HttpAuthenticationMechanism, Serializable { > > private static final long serialVersionUID = 1L; > > @Inject > @Delegate > HttpAuthenticationMechanism delegateMechanism; > > @Override > public AuthStatus validateRequest(HttpServletRequest request, > HttpServletResponse response, HttpMessageContext httpMessageContext) throws > AuthException { > return delegateMechanism.validateRequest(request, response, > httpMessageContext); > } > // ... > } > > > Then I create a "dynamic/programmatic" decorator: > > > public class DynamicHttpAuthenticationDecorator implements > Decorator { > > private final Set types = new > HashSet(asList(HttpAuthenticationBaseDecorator.class, Object.class)); > private final Set decoratedTypes = > singleton(HttpAuthenticationMechanism.class); > > private final BeanManager beanManager; > private final InjectionPoint decoratorInjectionPoint; > private final Set injectionPoints; > > public DynamicHttpAuthenticationDecorator(BeanManager beanManager) { > > decoratorInjectionPoint = new DecoratorInjectionPoint( > HttpAuthenticationMechanism.class, > > beanManager.createAnnotatedType(HttpAuthenticationBaseDecorator.class).getFields().iterator().next(), > this); > > injectionPoints = singleton(decoratorInjectionPoint); > > this.beanManager = beanManager; > } > > public HttpAuthenticationBaseDecorator > create(CreationalContext > creationalContext) { > return new AutoApplySessionDecorator( > (HttpAuthenticationMechanism) > beanManager.getInjectableReference(decoratorInjectionPoint, > creationalContext)); > } > > public void destroy(HttpAuthenticationBaseDecorator instance, > CreationalContext creationalContext) { > creationalContext.release(); > } > > public Set getTypes() { > return types; > } > > public Set getDecoratedTypes() { > return decoratedTypes; > } > > public Class getBeanClass() { > return HttpAuthenticationBaseDecorator.class; > } > > public Type getDelegateType() { > return HttpAuthenticationMechanism.class; > } > > public Set getInjectionPoints() { > return injectionPoints; > } > } > > This Decorator "pretends" that it's for the dummy decorator, via the > getTypes(), but in create() it returns another actual Decorator. Then I > create the delegate injection point of that decorator by grabbing the > @Delegate annotated field from the real decorator, wrapping that basically > in an InjectionPoint and then using that later with > beanManager#getInjectableReference. > > Now after adding this via afterBeanDiscovery.addBean(new > DynamicHttpAuthenticationDecorator(beanManager)), and it actually gets > called at runtime (tested on Weld). > > Disadvantages are a fixed priority and the fact that the dummy decorator > is called as well. > > Have to say that implementing the javax.enterprise.inject.spi.Decorator > interface, especially the part for grabbing the @Delegate is quite > non-obvious. > > What do you think, is this guaranteed to work, or did I abuse the CDI APIs > too much here? > > Kind regards, > Arjan Tijms > > > > > > > > > > > > > > > On Wed, Mar 2, 2016 at 11:14 PM, Thomas Andraschko < > andraschko.thomas at gmail.com> wrote: > >> +1 >> >> in DeltaSpike we implemented an own mechanism + proxy to invoke >> interceptors for partial beans. >> We will probably enhance this for such usecases or even producers: >> https://issues.apache.org/jira/browse/DELTASPIKE-1069 >> >> >> 2016-03-02 22:51 GMT+01:00 Romain Manni-Bucau : >> >>> +1, seems it is the way to fix several issues without introducing a lot >>> of new concepts/API and in term of technical stack it is just standardizing >>> what is there. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2016-03-02 22:48 GMT+01:00 Mark Struberg : >>> >>>> ProxyFactory? >>>> >>>> I?m really thinking about introducing something like javax.proxy, maybe >>>> as own sub-spec PDF? >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> > Am 02.03.2016 um 16:31 schrieb arjan tijms : >>>> > >>>> > Hi, >>>> > >>>> > I'm trying to add decorators and/or interceptors to a Bean that's >>>> added via an extension. There doesn't seem to be any way to add >>>> interceptors, but decorators seem almost possible. >>>> > >>>> > I've added a decorator in the following way: >>>> > >>>> > >>>> > AnnotatedType annotatedType = >>>> beanManager.createAnnotatedType(AutoApplySessionDecorator.class); >>>> > >>>> > BeanAttributes beanAttributes = >>>> beanManager.createBeanAttributes(annotatedType); >>>> > >>>> > Bean bean = >>>> beanManager.createBean(beanAttributes, AutoApplySessionDecorator.class, >>>> beanManager.getInjectionTargetFactory(annotatedType)); >>>> > >>>> > afterBeanDiscovery.addBean(bean); >>>> > >>>> > Where the "AutoApplySessionDecorator" is an existing (non-scanned) >>>> decorator just used as an example. >>>> > >>>> > >>>> > While this seems to work, the problem is with the enablement. >>>> @Priority is not processed in this way, since it's only read from an >>>> AnnotatedType that's been added to the deployment (see e.g. in Weld >>>> org.jboss.weld.bootstrap.BeanDeployer.processPriority(AnnotatedType)). >>>> > >>>> > beans.xml is not really an option here due to the static nature of >>>> that and the fact that the decorator needs to be enabled dynamically here, >>>> plus that the implementation class of the decorator is a detail I would not >>>> like to expose to the application. >>>> > >>>> > >>>> > Is there any other way to either enable a (synthetic) decorator >>>> programmatically, or to add Interceptors to a programmatically added >>>> Bean? >>>> > >>>> > 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. >>>> >>>> >>>> _______________________________________________ >>>> 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/20160726/f917f948/attachment-0001.html From antoine at sabot-durand.net Tue Jul 26 08:48:13 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 26 Jul 2016 12:48:13 +0000 Subject: [cdi-dev] Last PR to close before EDR2 Message-ID: Hi all, PR283, 290, & 295 are ready to be merge from my POV. Please do a last review and add +1 if you agree for this merge. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/13092163/attachment.html From antoine at sabot-durand.net Tue Jul 26 08:50:35 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 26 Jul 2016 12:50:35 +0000 Subject: [cdi-dev] Status of PR296 Message-ID: Hi, PR296 (CDI-30) is nearly ready IMO. The last big agreement is about ManageableContext inheriting AlterableContext as it was discussed during last meeting. @John will you have time to discuss this point and rework on it before the end of the week? Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/cd41ce13/attachment.html From antoine at sabot-durand.net Tue Jul 26 08:55:22 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 26 Jul 2016 12:55:22 +0000 Subject: [cdi-dev] Face to Face meeting agenda Message-ID: Hi all, Just to remind you that your contribution is most welcome to the Agenda for next F2F meeting: https://docs.google.com/spreadsheets/d/1vX3ajo_qDhf_vzZ8P-QZlmJ5Ieel-0Be13f4-SLWig8/edit?usp=sharing Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/a21bfbba/attachment.html From john.d.ament at gmail.com Tue Jul 26 08:56:10 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 26 Jul 2016 12:56:10 +0000 Subject: [cdi-dev] Status of PR296 In-Reply-To: References: Message-ID: Assuming that no new issues pop up. On Tue, Jul 26, 2016 at 8:50 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi, > > PR296 (CDI-30) is nearly ready IMO. The last big agreement is about > ManageableContext inheriting AlterableContext as it was discussed during > last meeting. > > @John will you have time to discuss this point and rework on it before the > end of the week? > > Antoine > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/62b3964c/attachment.html From antoine at sabot-durand.net Tue Jul 26 08:57:54 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 26 Jul 2016 12:57:54 +0000 Subject: [cdi-dev] Status of PR296 In-Reply-To: References: Message-ID: Great, thank you for your fast answer John. Do you think we can set up the last point on the ML and IRC or do you need an hangout meeting ? Le mar. 26 juil. 2016 ? 14:56, John D. Ament a ?crit : > Assuming that no new issues pop up. > > On Tue, Jul 26, 2016 at 8:50 AM Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi, >> >> PR296 (CDI-30) is nearly ready IMO. The last big agreement is about >> ManageableContext inheriting AlterableContext as it was discussed during >> last meeting. >> >> @John will you have time to discuss this point and rework on it before >> the end of the week? >> >> Antoine >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/ed4a98da/attachment.html From john.d.ament at gmail.com Tue Jul 26 09:00:11 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 26 Jul 2016 13:00:11 +0000 Subject: [cdi-dev] Status of PR296 In-Reply-To: References: Message-ID: Won't know until the PR gets updated. Seems like no matter the change, opinions flip-flop frequently on this. :-) On Tue, Jul 26, 2016 at 8:58 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Great, thank you for your fast answer John. Do you think we can set up the > last point on the ML and IRC or do you need an hangout meeting ? > > Le mar. 26 juil. 2016 ? 14:56, John D. Ament a > ?crit : > >> Assuming that no new issues pop up. >> >> On Tue, Jul 26, 2016 at 8:50 AM Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> >>> Hi, >>> >>> PR296 (CDI-30) is nearly ready IMO. The last big agreement is about >>> ManageableContext inheriting AlterableContext as it was discussed during >>> last meeting. >>> >>> @John will you have time to discuss this point and rework on it before >>> the end of the week? >>> >>> Antoine >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/ddb40c53/attachment.html From antoine at sabot-durand.net Tue Jul 26 10:21:33 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 26 Jul 2016 14:21:33 +0000 Subject: [cdi-dev] JSR 250 MR approved Message-ID: Hi all, Just to point you the result ballot for JSR 250 MR including @Priority modification: https://jcp.org/en/jsr/results?id=5857 I still don't have any confirmation regarding the official release date... Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/65babd28/attachment.html From rahman.usta.88 at gmail.com Tue Jul 26 11:05:26 2016 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Tue, 26 Jul 2016 18:05:26 +0300 Subject: [cdi-dev] JSR 250 MR approved In-Reply-To: References: Message-ID: Hi Antoine; It could be good to use @Priority annotation on CDI producers methods like below; @Produces @Priority(100) public AClass procudeA(){ } What do you think for that? Thanks 2016-07-26 17:21 GMT+03:00 Antoine Sabot-Durand : > Hi all, > > Just to point you the result ballot for JSR 250 MR including @Priority > modification: > > https://jcp.org/en/jsr/results?id=5857 > > I still don't have any confirmation regarding the official 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. > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/f63616be/attachment-0001.html From antoine at sabot-durand.net Tue Jul 26 11:35:55 2016 From: antoine at sabot-durand.net (antoine at sabot-durand.net) Date: Tue, 26 Jul 2016 15:35:55 +0000 Subject: [cdi-dev] =?utf-8?q?Invitation_mise_=C3=A0_jour=3A_CDI_weekly_mee?= =?utf-8?q?ting_-_Toutes_les_semaines_entre_18=3A00_et_19=3A00_le_m?= =?utf-8?q?ardi_=28CET=29_=28ASD_Perso=29?= Message-ID: <001a11c2832c2272ef05388ba8d0@google.com> Cet ?v?nement a ?t? modifi?. Titre : CDI weekly meeting Weekly meeting of the CDI EG and other community members discussing CDI 2.0 specification. Date?: Toutes les semaines entre 18:00 et 19:00 le mardi Paris (modifi?) Lieu : IRC #cdi-dev channel on freenode Agenda?: ASD Perso Participants?: * Antoine Sabot-Durand- organisateur * cdi-dev D?tails de l'?v?nement : https://www.google.com/calendar/event?action=VIEW&eid=XzcxMGpnZ3BrNjEwamliOXA2OHNrNGI5azY0cjM0YmExOGNzajBiOW02MTIzYWgxZzcwb2phZ2hsNm8gY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0Y2Q1YmEzMjU2NzNhZjM4MTFkMDQ5MWU4MjhiYzg2NWUyYjU4YWJhYg&ctz=Europe/Paris&hl=fr Invitation de Google?Agenda?: https://www.google.com/calendar/ Vous recevez ce message ? l'adresse cdi-dev at lists.jboss.org, car vous participez ? cet ?v?nement. Refusez cet ?v?nement pour ne plus recevoir de notifications le concernant. Vous avez ?galement la possibilit? de cr?er un compte Google ? l'adresse https://www.google.com/calendar/ et de d?finir vous-m?me les param?tres de notification pour l'int?gralit? de votre agenda. En transf?rant cette invitation, vous risquez d'autoriser tous les destinataires ? modifier votre r?ponse ? l'invitation. Pour en savoir plus, consultez la page suivante?: https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/6dc7ad8c/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2031 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/6dc7ad8c/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2091 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/6dc7ad8c/attachment-0001.bin From mkouba at redhat.com Wed Jul 27 01:56:48 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 27 Jul 2016 07:56:48 +0200 Subject: [cdi-dev] Enabling programmatic/synthetic decorators added by extension In-Reply-To: References: Message-ID: <10bcc54a-777a-5931-1738-cdaeb5a7a593@redhat.com> For the record - in CDI 2.0 we have javax.enterprise.inject.spi.Prioritized interface (currently used for ObserverMethod). But since Weld 3.0.0.Alpha13 prioritized custom beans, interceptors and decorators are also supported, i.e. Weld treats them as if annotated with @Priority (see also WELD-2000 [1]). I think this approach is also worth standardizing. Martin [1] https://issues.jboss.org/browse/WELD-2000 Dne 26.7.2016 v 11:59 arjan tijms napsal(a): > Hi, > > Just wondering, has there been any progress made for this topic? > > Having the ability to dynamically add interceptors and/or add them when > building a Bean using the programmatic APIs would still be incredibly > useful. > > Kind regards, > Arjan Tijms > > > On Fri, Mar 4, 2016 at 5:18 PM, arjan tijms > wrote: > > ProxyFactory sounds like a perfect solution indeed. > > I now got something working, more or less, emphasis on less. > > I first make a "normal" (but effectively dummy) decorator with > @Priority available: > > @Decorator > @Priority(PLATFORM_BEFORE + 200) > public abstract class HttpAuthenticationBaseDecorator implements > HttpAuthenticationMechanism, Serializable { > > private static final long serialVersionUID = 1L; > > @Inject > @Delegate > HttpAuthenticationMechanism delegateMechanism; > > @Override > public AuthStatus validateRequest(HttpServletRequest request, > HttpServletResponse response, HttpMessageContext httpMessageContext) > throws AuthException { > return delegateMechanism.validateRequest(request, response, > httpMessageContext); > } > // ... > } > > > Then I create a "dynamic/programmatic" decorator: > > > public class DynamicHttpAuthenticationDecorator implements > Decorator { > > private final Set types = new > HashSet(asList(HttpAuthenticationBaseDecorator.class, > Object.class)); > private final Set decoratedTypes = > singleton(HttpAuthenticationMechanism.class); > > private final BeanManager beanManager; > private final InjectionPoint decoratorInjectionPoint; > private final Set injectionPoints; > > public DynamicHttpAuthenticationDecorator(BeanManager beanManager) { > > decoratorInjectionPoint = new DecoratorInjectionPoint( > HttpAuthenticationMechanism.class, > > beanManager.createAnnotatedType(HttpAuthenticationBaseDecorator.class).getFields().iterator().next(), > this); > > injectionPoints = singleton(decoratorInjectionPoint); > > this.beanManager = beanManager; > } > > public HttpAuthenticationBaseDecorator > create(CreationalContext > creationalContext) { > return new AutoApplySessionDecorator( > (HttpAuthenticationMechanism) > beanManager.getInjectableReference(decoratorInjectionPoint, > creationalContext)); > } > > public void destroy(HttpAuthenticationBaseDecorator instance, > CreationalContext creationalContext) { > creationalContext.release(); > } > > public Set getTypes() { > return types; > } > > public Set getDecoratedTypes() { > return decoratedTypes; > } > > public Class getBeanClass() { > return HttpAuthenticationBaseDecorator.class; > } > > public Type getDelegateType() { > return HttpAuthenticationMechanism.class; > } > > public Set getInjectionPoints() { > return injectionPoints; > } > } > > This Decorator "pretends" that it's for the dummy decorator, via > the getTypes(), but in create() it returns another actual Decorator. > Then I create the delegate injection point of that decorator by > grabbing the @Delegate annotated field from the real decorator, > wrapping that basically in an InjectionPoint and then using that > later with beanManager#getInjectableReference. > > Now after adding this via afterBeanDiscovery.addBean(new > DynamicHttpAuthenticationDecorator(beanManager)), and it actually > gets called at runtime (tested on Weld). > > Disadvantages are a fixed priority and the fact that the dummy > decorator is called as well. > > Have to say that implementing > the javax.enterprise.inject.spi.Decorator interface, especially the > part for grabbing the @Delegate is quite non-obvious. > > What do you think, is this guaranteed to work, or did I abuse the > CDI APIs too much here? > > Kind regards, > Arjan Tijms > > > > > > > > > > > > > > > On Wed, Mar 2, 2016 at 11:14 PM, Thomas Andraschko > > > wrote: > > +1 > > in DeltaSpike we implemented an own mechanism + proxy to invoke > interceptors for partial beans. > We will probably enhance this for such usecases or even > producers: https://issues.apache.org/jira/browse/DELTASPIKE-1069 > > > 2016-03-02 22:51 GMT+01:00 Romain Manni-Bucau > >: > > +1, seems it is the way to fix several issues without > introducing a lot of new concepts/API and in term of > technical stack it is just standardizing what is there. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2016-03-02 22:48 GMT+01:00 Mark Struberg >: > > ProxyFactory? > > I?m really thinking about introducing something like > javax.proxy, maybe as own sub-spec PDF? > > LieGrue, > strub > > > > Am 02.03.2016 um 16:31 schrieb arjan tijms > >: > > > > Hi, > > > > I'm trying to add decorators and/or interceptors to a > Bean that's added via an extension. There doesn't > seem to be any way to add interceptors, but decorators > seem almost possible. > > > > I've added a decorator in the following way: > > > > > > AnnotatedType annotatedType > = > beanManager.createAnnotatedType(AutoApplySessionDecorator.class); > > > > BeanAttributes > beanAttributes = > beanManager.createBeanAttributes(annotatedType); > > > > Bean bean = > beanManager.createBean(beanAttributes, > AutoApplySessionDecorator.class, > beanManager.getInjectionTargetFactory(annotatedType)); > > > > afterBeanDiscovery.addBean(bean); > > > > Where the "AutoApplySessionDecorator" is an existing > (non-scanned) decorator just used as an example. > > > > > > While this seems to work, the problem is with the > enablement. @Priority is not processed in this way, > since it's only read from an AnnotatedType that's been > added to the deployment (see e.g. in Weld > org.jboss.weld.bootstrap.BeanDeployer.processPriority(AnnotatedType)). > > > > beans.xml is not really an option here due to the > static nature of that and the fact that the decorator > needs to be enabled dynamically here, plus that the > implementation class of the decorator is a detail I > would not like to expose to the application. > > > > > > Is there any other way to either enable a (synthetic) > decorator programmatically, or to add Interceptors to a > programmatically added Bean? > > > > 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. > > > _______________________________________________ > 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. > > > > > > _______________________________________________ > 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 werner.keil at gmail.com Wed Jul 27 03:50:12 2016 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 27 Jul 2016 09:50:12 +0200 Subject: [cdi-dev] F2F at JavaOne? Message-ID: Hi, I know for those in Europe, especially France or Czech Republic a F2F seems planned even in the same month (Sep) which is why I cannot travel aside from nearly 2 full work weeks that'll cost me and my clients. Antoine and some of his colleagues have a few sessions related to CDI as such and "somewhat related topics" including Docker, Microservices, etc. Are enough others (I know Anatole has a talk, Otavio also does, at least the one related to JSR 363 I plan to join) from the EG there who have time to meet? Hopefully the JCP gets a room in the Hilton again, otherwise I'm sure we could meet somewhere else. WDYT? Werner On Wed, Jul 27, 2016 at 7:56 AM, wrote: > Send cdi-dev mailing list submissions to > cdi-dev at lists.jboss.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.jboss.org/mailman/listinfo/cdi-dev > or, via email, send a message with subject or body 'help' to > cdi-dev-request at lists.jboss.org > > You can reach the person managing the list at > cdi-dev-owner at lists.jboss.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cdi-dev digest..." > > > Today's Topics: > > 1. Invitation mise ? jour: CDI weekly meeting - Toutes les > semaines entre 18:00 et 19:00 le mardi (CET) (ASD Perso) > (antoine at sabot-durand.net) > 2. Re: Enabling programmatic/synthetic decorators added by > extension (Martin Kouba) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 26 Jul 2016 15:35:55 +0000 > From: antoine at sabot-durand.net > Subject: [cdi-dev] Invitation mise ? jour: CDI weekly meeting - Toutes > les semaines entre 18:00 et 19:00 le mardi (CET) (ASD Perso) > To: cdi-dev > Message-ID: <001a11c2832c2272ef05388ba8d0 at google.com> > Content-Type: text/plain; charset="utf-8" > > Cet ?v?nement a ?t? modifi?. > > Titre : CDI weekly meeting > Weekly meeting of the CDI EG and other community members discussing CDI 2.0 > specification. > Date?: Toutes les semaines entre 18:00 et 19:00 le mardi Paris (modifi?) > Lieu : IRC #cdi-dev channel on freenode > Agenda?: ASD Perso > Participants?: > * Antoine Sabot-Durand- organisateur > * cdi-dev > > D?tails de l'?v?nement : > > https://www.google.com/calendar/event?action=VIEW&eid=XzcxMGpnZ3BrNjEwamliOXA2OHNrNGI5azY0cjM0YmExOGNzajBiOW02MTIzYWgxZzcwb2phZ2hsNm8gY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0Y2Q1YmEzMjU2NzNhZjM4MTFkMDQ5MWU4MjhiYzg2NWUyYjU4YWJhYg&ctz=Europe/Paris&hl=fr > > Invitation de Google?Agenda?: https://www.google.com/calendar/ > > Vous recevez ce message ? l'adresse cdi-dev at lists.jboss.org, car vous > participez ? cet ?v?nement. > > Refusez cet ?v?nement pour ne plus recevoir de notifications le concernant. > Vous avez ?galement la possibilit? de cr?er un compte Google ? l'adresse > https://www.google.com/calendar/ et de d?finir vous-m?me les param?tres de > notification pour l'int?gralit? de votre agenda. > > En transf?rant cette invitation, vous risquez d'autoriser tous les > destinataires ? modifier votre r?ponse ? l'invitation. Pour en savoir plus, > consultez la page suivante?: > https://support.google.com/calendar/answer/37135#forwarding > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/6dc7ad8c/attachment-0001.html > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: text/calendar > Size: 2031 bytes > Desc: not available > Url : > http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/6dc7ad8c/attachment-0002.bin > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: invite.ics > Type: application/ics > Size: 2091 bytes > Desc: not available > Url : > http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/6dc7ad8c/attachment-0003.bin > > ------------------------------ > > Message: 2 > Date: Wed, 27 Jul 2016 07:56:48 +0200 > From: Martin Kouba > Subject: Re: [cdi-dev] Enabling programmatic/synthetic decorators > added by extension > To: cdi-dev at lists.jboss.org > Message-ID: <10bcc54a-777a-5931-1738-cdaeb5a7a593 at redhat.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > For the record - in CDI 2.0 we have > javax.enterprise.inject.spi.Prioritized interface (currently used for > ObserverMethod). > > But since Weld 3.0.0.Alpha13 prioritized custom beans, interceptors and > decorators are also supported, i.e. Weld treats them as if annotated > with @Priority (see also WELD-2000 [1]). I think this approach is also > worth standardizing. > > Martin > > [1] > https://issues.jboss.org/browse/WELD-2000 > > Dne 26.7.2016 v 11:59 arjan tijms napsal(a): > > Hi, > > > > Just wondering, has there been any progress made for this topic? > > > > Having the ability to dynamically add interceptors and/or add them when > > building a Bean using the programmatic APIs would still be incredibly > > useful. > > > > Kind regards, > > Arjan Tijms > > > > > > On Fri, Mar 4, 2016 at 5:18 PM, arjan tijms > > wrote: > > > > ProxyFactory sounds like a perfect solution indeed. > > > > I now got something working, more or less, emphasis on less. > > > > I first make a "normal" (but effectively dummy) decorator with > > @Priority available: > > > > @Decorator > > @Priority(PLATFORM_BEFORE + 200) > > public abstract class HttpAuthenticationBaseDecorator implements > > HttpAuthenticationMechanism, Serializable { > > > > private static final long serialVersionUID = 1L; > > > > @Inject > > @Delegate > > HttpAuthenticationMechanism delegateMechanism; > > > > @Override > > public AuthStatus validateRequest(HttpServletRequest request, > > HttpServletResponse response, HttpMessageContext httpMessageContext) > > throws AuthException { > > return delegateMechanism.validateRequest(request, response, > > httpMessageContext); > > } > > // ... > > } > > > > > > Then I create a "dynamic/programmatic" decorator: > > > > > > public class DynamicHttpAuthenticationDecorator implements > > Decorator { > > > > private final Set types = new > > HashSet(asList(HttpAuthenticationBaseDecorator.class, > > Object.class)); > > private final Set decoratedTypes = > > singleton(HttpAuthenticationMechanism.class); > > > > private final BeanManager beanManager; > > private final InjectionPoint decoratorInjectionPoint; > > private final Set injectionPoints; > > > > public DynamicHttpAuthenticationDecorator(BeanManager > beanManager) { > > > > decoratorInjectionPoint = new DecoratorInjectionPoint( > > HttpAuthenticationMechanism.class, > > > > > beanManager.createAnnotatedType(HttpAuthenticationBaseDecorator.class).getFields().iterator().next(), > > this); > > > > injectionPoints = singleton(decoratorInjectionPoint); > > > > this.beanManager = beanManager; > > } > > > > public HttpAuthenticationBaseDecorator > > create(CreationalContext > > creationalContext) { > > return new AutoApplySessionDecorator( > > (HttpAuthenticationMechanism) > > beanManager.getInjectableReference(decoratorInjectionPoint, > > creationalContext)); > > } > > > > public void destroy(HttpAuthenticationBaseDecorator instance, > > CreationalContext > creationalContext) { > > creationalContext.release(); > > } > > > > public Set getTypes() { > > return types; > > } > > > > public Set getDecoratedTypes() { > > return decoratedTypes; > > } > > > > public Class getBeanClass() { > > return HttpAuthenticationBaseDecorator.class; > > } > > > > public Type getDelegateType() { > > return HttpAuthenticationMechanism.class; > > } > > > > public Set getInjectionPoints() { > > return injectionPoints; > > } > > } > > > > This Decorator "pretends" that it's for the dummy decorator, via > > the getTypes(), but in create() it returns another actual Decorator. > > Then I create the delegate injection point of that decorator by > > grabbing the @Delegate annotated field from the real decorator, > > wrapping that basically in an InjectionPoint and then using that > > later with beanManager#getInjectableReference. > > > > Now after adding this via afterBeanDiscovery.addBean(new > > DynamicHttpAuthenticationDecorator(beanManager)), and it actually > > gets called at runtime (tested on Weld). > > > > Disadvantages are a fixed priority and the fact that the dummy > > decorator is called as well. > > > > Have to say that implementing > > the javax.enterprise.inject.spi.Decorator interface, especially the > > part for grabbing the @Delegate is quite non-obvious. > > > > What do you think, is this guaranteed to work, or did I abuse the > > CDI APIs too much here? > > > > Kind regards, > > Arjan Tijms > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 2, 2016 at 11:14 PM, Thomas Andraschko > > > > > wrote: > > > > +1 > > > > in DeltaSpike we implemented an own mechanism + proxy to invoke > > interceptors for partial beans. > > We will probably enhance this for such usecases or even > > producers: https://issues.apache.org/jira/browse/DELTASPIKE-1069 > > > > > > 2016-03-02 22:51 GMT+01:00 Romain Manni-Bucau > > >: > > > > +1, seems it is the way to fix several issues without > > introducing a lot of new concepts/API and in term of > > technical stack it is just standardizing what is there. > > > > > > Romain Manni-Bucau > > @rmannibucau | Blog > > | Github > > | LinkedIn > > | Tomitriber > > > > > > 2016-03-02 22:48 GMT+01:00 Mark Struberg > >: > > > > ProxyFactory? > > > > I?m really thinking about introducing something like > > javax.proxy, maybe as own sub-spec PDF? > > > > LieGrue, > > strub > > > > > > > Am 02.03.2016 um 16:31 schrieb arjan tijms > > >: > > > > > > Hi, > > > > > > I'm trying to add decorators and/or interceptors to a > > Bean that's added via an extension. There doesn't > > seem to be any way to add interceptors, but decorators > > seem almost possible. > > > > > > I've added a decorator in the following way: > > > > > > > > > AnnotatedType annotatedType > > = > > > beanManager.createAnnotatedType(AutoApplySessionDecorator.class); > > > > > > BeanAttributes > > beanAttributes = > > beanManager.createBeanAttributes(annotatedType); > > > > > > Bean bean = > > beanManager.createBean(beanAttributes, > > AutoApplySessionDecorator.class, > > beanManager.getInjectionTargetFactory(annotatedType)); > > > > > > afterBeanDiscovery.addBean(bean); > > > > > > Where the "AutoApplySessionDecorator" is an existing > > (non-scanned) decorator just used as an example. > > > > > > > > > While this seems to work, the problem is with the > > enablement. @Priority is not processed in this way, > > since it's only read from an AnnotatedType that's been > > added to the deployment (see e.g. in Weld > > > org.jboss.weld.bootstrap.BeanDeployer.processPriority(AnnotatedType)). > > > > > > beans.xml is not really an option here due to the > > static nature of that and the fact that the decorator > > needs to be enabled dynamically here, plus that the > > implementation class of the decorator is a detail I > > would not like to expose to the application. > > > > > > > > > Is there any other way to either enable a (synthetic) > > decorator programmatically, or to add Interceptors to a > > programmatically added Bean? > > > > > > Kind regards, > > > Arjan Tijms > > > > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at lists.jboss.org 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. > > > > > > > > _______________________________________________ > > 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. > > > > -- > 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. > > End of cdi-dev Digest, Vol 68, Issue 17 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160727/799e8ad6/attachment-0001.html From issues at jboss.org Wed Jul 27 04:49:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 27 Jul 2016 04:49:01 -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=13271060#comment-13271060 ] Martin Kouba commented on CDI-494: ---------------------------------- For the record, the resolution of this issue is: *_"A wildcard type is not considered an unresolvable type variable"_* (the opposite of the original proposal). > 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 > Assignee: Martin Kouba > Fix For: 2.0-EDR2 > > > 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 Thu Jul 28 04:36:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 28 Jul 2016 04:36: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 ] Antoine Sabot-Durand updated CDI-596: ------------------------------------- Fix Version/s: 2.0-EDR2 (was: 2.0 (discussion)) > 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-EDR2 > > > 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 Thu Jul 28 04:36:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 28 Jul 2016 04:36: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 ] Antoine Sabot-Durand reassigned CDI-596: ---------------------------------------- Assignee: Antoine Sabot-Durand > 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 > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > 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 Thu Jul 28 04:38:08 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 28 Jul 2016 04:38:08 -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 ] Work on CDI-596 started by Antoine Sabot-Durand. ------------------------------------------------ > 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 > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > 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 Thu Jul 28 06:27:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 28 Jul 2016 06:27:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-602) Unmanaged.UnmanagedInstance.disposed is never set to true In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-602: ------------------------------------- Fix Version/s: 2.0-EDR2 > Unmanaged.UnmanagedInstance.disposed is never set to true > --------------------------------------------------------- > > Key: CDI-602 > URL: https://issues.jboss.org/browse/CDI-602 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final, 2.0-EDR1 > Reporter: Martin Kouba > Fix For: 2.0-EDR2 > > > As a result an {{IllegalStateException}} is never thrown if any method is called on an instance that has already been disposed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 07:24:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 28 Jul 2016 07:24:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271990#comment-13271990 ] Martin Kouba commented on CDI-601: ---------------------------------- Yes, sounds better. Maybe even {{ApplicationStopped}}? bq. My original notion was for @ApplicationScoped beans not to be destroyed while other beans still hold contextual references to them... This might be pretty complext, if even possible for non-inject cases ({{BeanManager.getReference()}}, {{Instance.get()}}) and unmanaged contextual instances. What I had in mind when creating this ticket was that it might be useful to introduce some generic event fired *when an application is stopped before all contexts are destroyed* and which would allow a bean to perform cleanup using the dependencies, i.e. fired before {{@PreDestroy}} and {{@Destroyed(X.class)}}. [~chrisjr] WRT your use case - your "@Dependent worker bean" would just observe {{ApplicationStopped}} and do all the cleanup ({{@ApplicationScoped}} beans would not be destroyed yet). {code:java} @Dependent class Worker { @Inject Service service; void shutdown(@Observes ApplicationStopped event) { // At this point Service is not destroyed yet, nor is its @PreDestroy called service.doSomeStuff(); } } @ApplicationScoped class Service { @PreDestroy void destroy() { // Perform local cleanup } void doSomeStuff() { } } {code} > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 07:33:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 28 Jul 2016 07:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-589) Programmatic lookup - add Instance.release() method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272003#comment-13272003 ] Martin Kouba commented on CDI-589: ---------------------------------- https://github.com/weld/api/blob/2.4/weld/src/main/java/org/jboss/weld/inject/WeldInstance.java > Programmatic lookup - add Instance.release() method > --------------------------------------------------- > > Key: CDI-589 > URL: https://issues.jboss.org/browse/CDI-589 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > * destroys {{@Dependent}} bean instances obtained from the same {{Instance}} object > * ignores client proxies > See also https://github.com/cdi-spec/cdi/pull/273. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 07:34:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 28 Jul 2016 07:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-540) Clarify CDI container initialization in Java SE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba resolved CDI-540. ------------------------------ Resolution: Out of Date > Clarify CDI container initialization in Java SE > ----------------------------------------------- > > Key: CDI-540 > URL: https://issues.jboss.org/browse/CDI-540 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java SE Integration > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > > {{CDIProvider.isInitialized()}} javadoc should be clarified. I believe the spec should be more specific and define what it means for a CDIProvider to be initialized. E.g. _"a {{CDIProvider}} is initialized if at least one CDI container was started and is still running"_. > {{CDI.shutdown()}} currently must throw an {{IllegalStateException}} if the container is already stopped (actually, the javadoc is missing this piece of information). However, there is no way how to find out whether a CDI container is running or not. {{CDIProvider.isInitialized()}} would be usable if multiple running containers were forbidden (which I hope will not be). Also it wouldn't make sense to ask an instance of {{CDIProvider}} whether a concrete {{CDI}} instance is running... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 07:49:00 2016 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Thu, 28 Jul 2016 07:49:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272015#comment-13272015 ] Chris Rankin commented on CDI-601: ---------------------------------- But doesn't this imply that a new {{@Dependent Worker}} bean would then be _created_ in order to handle this {{ApplicationStopped}} event? This seems like "non-obvious" behaviour when I'm trying to destroy existing beans and shut the application down. > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 08:09:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 28 Jul 2016 08:09:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272032#comment-13272032 ] Martin Kouba commented on CDI-601: ---------------------------------- Oops, you're right! {{@Dependent}} beans may not have conditional observer methods. So the observer method would have to be defined on some kind of "holder" bean - any bean which holds references to the relevant {{@Dependent}} bean instances and delegate the notification - but that's basically the solution you describe, right? > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 08:27:00 2016 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Thu, 28 Jul 2016 08:27:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272053#comment-13272053 ] Chris Rankin commented on CDI-601: ---------------------------------- That does sound like the solution that I ended up implementing, yes. Except that I had to observe a {{@Destroyed(ApplicationScoped.class)}} event on the basis that it was fired before any beans were destroyed. And fortunately I had only one bean that needed this kind of special handling - I had no way of controlling the order in which {{@Destroyed(ApplicationScoped.class)}} events were handled. > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 09:21:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 28 Jul 2016 09:21:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-589) Enhance programmatic lookup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-589: ----------------------------- Summary: Enhance programmatic lookup (was: Programmatic lookup - add Instance.release() method) > Enhance programmatic lookup > --------------------------- > > Key: CDI-589 > URL: https://issues.jboss.org/browse/CDI-589 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > * destroys {{@Dependent}} bean instances obtained from the same {{Instance}} object > * ignores client proxies > See also https://github.com/cdi-spec/cdi/pull/273. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 09:23:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 28 Jul 2016 09:23:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-589) Enhance programmatic lookup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-589: ----------------------------- Description: The original intent was to allow to obtain bean metadata from {{javax.enterprise.inject.Instance}} (see also CDI-515). The new proposal is to enhance Instance similarly to Weld API: was: * destroys {{@Dependent}} bean instances obtained from the same {{Instance}} object * ignores client proxies See also https://github.com/cdi-spec/cdi/pull/273. > Enhance programmatic lookup > --------------------------- > > Key: CDI-589 > URL: https://issues.jboss.org/browse/CDI-589 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > The original intent was to allow to obtain bean metadata from {{javax.enterprise.inject.Instance}} (see also CDI-515). > The new proposal is to enhance Instance similarly to Weld API: -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 09:24:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 28 Jul 2016 09:24:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-589) Enhance programmatic lookup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-589: ----------------------------- Description: The original intent was to allow to obtain bean metadata from {{javax.enterprise.inject.Instance}} (see also CDI-515). The new proposal is to enhance {{Instance}} similarly as Weld API does: https://github.com/weld/api/blob/2.4/weld/src/main/java/org/jboss/weld/inject/WeldInstance.java was: The original intent was to allow to obtain bean metadata from {{javax.enterprise.inject.Instance}} (see also CDI-515). The new proposal is to enhance Instance similarly to Weld API: > Enhance programmatic lookup > --------------------------- > > Key: CDI-589 > URL: https://issues.jboss.org/browse/CDI-589 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > The original intent was to allow to obtain bean metadata from {{javax.enterprise.inject.Instance}} (see also CDI-515). > The new proposal is to enhance {{Instance}} similarly as Weld API does: > https://github.com/weld/api/blob/2.4/weld/src/main/java/org/jboss/weld/inject/WeldInstance.java -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 09:24:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 28 Jul 2016 09:24:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-589) Enhance programmatic lookup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-589: ----------------------------- Comment: was deleted (was: https://github.com/weld/api/blob/2.4/weld/src/main/java/org/jboss/weld/inject/WeldInstance.java) > Enhance programmatic lookup > --------------------------- > > Key: CDI-589 > URL: https://issues.jboss.org/browse/CDI-589 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > The original intent was to allow to obtain bean metadata from {{javax.enterprise.inject.Instance}} (see also CDI-515). > The new proposal is to enhance {{Instance}} similarly as Weld API does: > https://github.com/weld/api/blob/2.4/weld/src/main/java/org/jboss/weld/inject/WeldInstance.java -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 09:46:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 28 Jul 2016 09:46:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-441) Enhance wording for indirect specialization in 4.3.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-441: ------------------------------------- Fix Version/s: 2.0-EDR2 > Enhance wording for indirect specialization in 4.3.1 > ---------------------------------------------------- > > Key: CDI-441 > URL: https://issues.jboss.org/browse/CDI-441 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Inheritance and Specialization > Affects Versions: 1.2.Final > Reporter: Tomas Remes > Fix For: 2.0-EDR2 > > > In the 4.3.1. Direct and indirect specialization is following: > {quote} > Formally, a bean X is said to specialize another bean Y if either: > ? X directly specializes Y, or > ? a bean Z exists, such that X directly specializes Z and Z specializes Y. > {quote} > It is not fully straightforward to deduce that the second point here is not just redundant first case, but rather transitive relationship in indirect specialization. > Therefore I think the wording for indirect specialization should be enhanced. Explanation from Jozef is at http://lists.jboss.org/pipermail/cdi-dev/2014-June/005082.html. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 09:48:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 28 Jul 2016 09:48:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-548) FireAsyncException conflicting with CompletionStage definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reopened CDI-548: -------------------------------------- > FireAsyncException conflicting with CompletionStage definition > -------------------------------------------------------------- > > Key: CDI-548 > URL: https://issues.jboss.org/browse/CDI-548 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Jozef Hartinger > > CompletionStage documentation says: > {quote} > if a stage's computation terminates abruptly with an (unchecked) exception or error, then all dependent stages requiring its completion complete exceptionally as well, with a {@link CompletionException} holding the exception as its cause. > {quote} > On the other hand, the CDI spec suggests that if an observer notification fails, the CompletionStage fails with FireAsyncException directly (not wrapped within CompletionException). This creates a conflict as the CDI spec uses the CompletionStage API without fully conforming to its contract. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 09:48:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 28 Jul 2016 09:48:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-548) FireAsyncException conflicting with CompletionStage definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-548. ------------------------------------ Resolution: Out of Date async event don't use a specific exception anymore > FireAsyncException conflicting with CompletionStage definition > -------------------------------------------------------------- > > Key: CDI-548 > URL: https://issues.jboss.org/browse/CDI-548 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Jozef Hartinger > > CompletionStage documentation says: > {quote} > if a stage's computation terminates abruptly with an (unchecked) exception or error, then all dependent stages requiring its completion complete exceptionally as well, with a {@link CompletionException} holding the exception as its cause. > {quote} > On the other hand, the CDI spec suggests that if an observer notification fails, the CompletionStage fails with FireAsyncException directly (not wrapped within CompletionException). This creates a conflict as the CDI spec uses the CompletionStage API without fully conforming to its contract. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 09:49:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 28 Jul 2016 09:49:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-600) Specialization code sample is misleading In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-600: ------------------------------------- Fix Version/s: 2.0-EDR2 > Specialization code sample is misleading > ---------------------------------------- > > Key: CDI-600 > URL: https://issues.jboss.org/browse/CDI-600 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Inheritance and Specialization > Affects Versions: 2.0-EDR1 > Reporter: Matej Novotny > Fix For: 2.0-EDR2 > > > In the spec, there is following code sample explaining how to achieve specialization: > {code} > @Alternative @Specializes > public class MockAsynchronousService extends AsynchronousService { > ... > } > {code} > This is IMHO misleading as the {{@Alternative}} annotation is not needed for specialization to work and hence should be removed from this sample. In fact one user approached me recently, asking me some questions regarding CDI specialization, and this sample was a source of his confusion. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 09:49:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 28 Jul 2016 09:49:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-548) FireAsyncException conflicting with CompletionStage definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reopened CDI-548: -------------------------------------- > FireAsyncException conflicting with CompletionStage definition > -------------------------------------------------------------- > > Key: CDI-548 > URL: https://issues.jboss.org/browse/CDI-548 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Jozef Hartinger > > CompletionStage documentation says: > {quote} > if a stage's computation terminates abruptly with an (unchecked) exception or error, then all dependent stages requiring its completion complete exceptionally as well, with a {@link CompletionException} holding the exception as its cause. > {quote} > On the other hand, the CDI spec suggests that if an observer notification fails, the CompletionStage fails with FireAsyncException directly (not wrapped within CompletionException). This creates a conflict as the CDI spec uses the CompletionStage API without fully conforming to its contract. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 09:49:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 28 Jul 2016 09:49:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-548) FireAsyncException conflicting with CompletionStage definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-548: ------------------------------------- Fix Version/s: 2.0 (proposed) > FireAsyncException conflicting with CompletionStage definition > -------------------------------------------------------------- > > Key: CDI-548 > URL: https://issues.jboss.org/browse/CDI-548 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Jozef Hartinger > Fix For: 2.0 (proposed) > > > CompletionStage documentation says: > {quote} > if a stage's computation terminates abruptly with an (unchecked) exception or error, then all dependent stages requiring its completion complete exceptionally as well, with a {@link CompletionException} holding the exception as its cause. > {quote} > On the other hand, the CDI spec suggests that if an observer notification fails, the CompletionStage fails with FireAsyncException directly (not wrapped within CompletionException). This creates a conflict as the CDI spec uses the CompletionStage API without fully conforming to its contract. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 09:49:04 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 28 Jul 2016 09:49:04 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-548) FireAsyncException conflicting with CompletionStage definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-548. ------------------------------------ Resolution: Out of Date > FireAsyncException conflicting with CompletionStage definition > -------------------------------------------------------------- > > Key: CDI-548 > URL: https://issues.jboss.org/browse/CDI-548 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Jozef Hartinger > Fix For: 2.0 (proposed) > > > CompletionStage documentation says: > {quote} > if a stage's computation terminates abruptly with an (unchecked) exception or error, then all dependent stages requiring its completion complete exceptionally as well, with a {@link CompletionException} holding the exception as its cause. > {quote} > On the other hand, the CDI spec suggests that if an observer notification fails, the CompletionStage fails with FireAsyncException directly (not wrapped within CompletionException). This creates a conflict as the CDI spec uses the CompletionStage API without fully conforming to its contract. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 09:50:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 28 Jul 2016 09:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-611) Enhance 10.3.3. Multiple event qualifiers section In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-611: ------------------------------------- Fix Version/s: 2.0-EDR2 > Enhance 10.3.3. Multiple event qualifiers section > ------------------------------------------------- > > Key: CDI-611 > URL: https://issues.jboss.org/browse/CDI-611 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Matej Novotny > Fix For: 2.0-EDR2 > > > While the current spec is in fact correct, it is quite hard to decipher what it is actually trying to convey. > Elsewhere in the spec, we talk about subsets of qualifiers while here we don't. There is a code sample and a sentence saying *"Then this observer method will only be notified if all the observed event qualifiers are specified when the event is fired:"* > This can be interpreted as: > * _"I must fire an event with exactly the same qualifiers as this observer has in order to notify it"_ (*wrong assumption* - it can have more qualifiers) > * _"I must fire an event which will contain at least the same qualifiers as this observer has in order to notify it"_ (*correct* - yet not so obvious) > I will try to come up with some improvement to make this clear. As it is, it always takes me several reading to soak it in. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Jul 28 09:51:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 28 Jul 2016 09:51:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-560) A bean archive does not have to contain a beans.xml file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-560: ------------------------------------- Fix Version/s: (was: 2.0 (proposed)) > A bean archive does not have to contain a beans.xml file > -------------------------------------------------------- > > Key: CDI-560 > URL: https://issues.jboss.org/browse/CDI-560 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 2.0-EDR1 > Environment: Section 5.1 Modularity: The library is a bean archive if it contains > a beans.xml file, as defined in Bean archives. > It contradicts with the section 12.1 > An archive which: > contains a beans.xml file with the bean-discovery-mode of none, or, > contains an extension and no beans.xml file > is not a bean archive. > Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". > I think it is better to be "The library may be a bean archive, as defined in Bean archives." > Reporter: Emily Jiang > Priority: Minor > Fix For: 2.0-EDR2 > > > Section 5.1 Modularity: The library is a bean archive if it contains > a beans.xml file, as defined in Bean archives. > It contradicts with the section 12.1 > {quote} > An archive which: > * contains a beans.xml file with the bean-discovery-mode of none, or, > * contains an extension and no beans.xml file > is not a bean archive. > {quote} > Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". > I think it is better to be "The library may be a bean archive, as defined in Bean archives." -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Jul 29 00:55:00 2016 From: issues at jboss.org (Pavel Pscheidl (JIRA)) Date: Fri, 29 Jul 2016 00:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection or intercepted self invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272498#comment-13272498 ] Pavel Pscheidl commented on CDI-414: ------------------------------------ [~lucasvc] Do you mean the case where destructor is not called and should be ? Or are there any other cases for potential memory leaks on your mind ? > Support for "self" injection or intercepted self invocation > ----------------------------------------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > Fix For: 2.0 (discussion) > > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Jul 29 01:51:00 2016 From: issues at jboss.org (Lucas Ventura Carro (JIRA)) Date: Fri, 29 Jul 2016 01:51:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection or intercepted self invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272510#comment-13272510 ] Lucas Ventura Carro commented on CDI-414: ----------------------------------------- Is the only one I have in mind, but I usually avoid {{Instance}} because I've found it really hard to understand how works internally and really dependent on how al the involved beans are. > Support for "self" injection or intercepted self invocation > ----------------------------------------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > Fix For: 2.0 (discussion) > > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Fri Jul 29 05:07:36 2016 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 29 Jul 2016 11:07:36 +0200 Subject: [cdi-dev] Weld experimental APIs and related spec issues Message-ID: <5c2d13b6-80ac-fcd1-beba-2f01e8d29baa@redhat.com> Hi all, I'm just looking at Weld 3 experimental APIs and I believe some of the related issues might deserve more attention of the CDI EG: Interceptor bindings available via InvocationContext ==================================================== - https://issues.jboss.org/browse/CDI-468 - http://weld.cdi-spec.org/news/2014/10/02/weld-300Alpha1/#_interceptor_bindings_in_invocation_context - does anybody know whether an interceptors spec update will be part of EE 8? Support repeating annotations ============================= - https://issues.jboss.org/browse/CDI-460 - https://issues.jboss.org/browse/CDI-471 - http://weld.cdi-spec.org/news/2014/10/02/weld-300Alpha1/#_repeatable_qualifiers_and_interceptor_bindings - https://issues.apache.org/jira/browse/OWB-1004 InterceptorBuilder ================== - allows to create an interceptor bean without the need to create a class: http://weld.cdi-spec.org/news/2016/02/04/weld-300Alpha15/ - https://issues.jboss.org/browse/WELD-2008 Thanks, Martin