From issues at jboss.org Mon Oct 3 04:36:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 3 Oct 2016 04:36:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-634) Clarify contextual reference validity to a bean with a normal scope in Java SE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301424#comment-13301424 ] Matej Novotny commented on CDI-634: ----------------------------------- +1 for clarification Although it is 'deducible' for us, it won't hurt to mention it as it indeed can be tempting. > Clarify contextual reference validity to a bean with a normal scope in Java SE > ------------------------------------------------------------------------------ > > Key: CDI-634 > URL: https://issues.jboss.org/browse/CDI-634 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > > In Java SE, a user might be tempted to share a contextual reference for a normal scoped bean (client proxy) between multiple "deployments" of a single application, e.g.: > # start CDI container > # get a reference > # stop CDI container > # start CDI container again and try to use the stored reference. > I believe such a reference should not be valid after an application stopped (contexts are destroyed, etc.). Right now, it seems to be undefined. > See also WELD-2190. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 3 06:43:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 3 Oct 2016 06:43:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-634) Clarify contextual reference validity to a bean with a normal scope in Java SE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301424#comment-13301424 ] Matej Novotny edited comment on CDI-634 at 10/3/16 6:42 AM: ------------------------------------------------------------ +1 for clarification Although it is 'deducible' for us, it won't hurt to mention it as it indeed can be tempting. EDIT: drafted a PR for this - https://github.com/cdi-spec/cdi/pull/304 was (Author: manovotn): +1 for clarification Although it is 'deducible' for us, it won't hurt to mention it as it indeed can be tempting. > Clarify contextual reference validity to a bean with a normal scope in Java SE > ------------------------------------------------------------------------------ > > Key: CDI-634 > URL: https://issues.jboss.org/browse/CDI-634 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > > In Java SE, a user might be tempted to share a contextual reference for a normal scoped bean (client proxy) between multiple "deployments" of a single application, e.g.: > # start CDI container > # get a reference > # stop CDI container > # start CDI container again and try to use the stored reference. > I believe such a reference should not be valid after an application stopped (contexts are destroyed, etc.). Right now, it seems to be undefined. > See also WELD-2190. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Mon Oct 3 10:41:06 2016 From: antoine at sabot-durand.net (antoine at sabot-durand.net) Date: Mon, 03 Oct 2016 14:41:06 +0000 Subject: [cdi-dev] Canceled Event: CDI weekly meeting @ Weekly from 18:00 to 19:00 on Tuesday (CET) (ASD Perso) Message-ID: <001a1142b3461cc0cd053df6ef94@google.com> This event has been canceled and removed from your calendar. Title: CDI weekly meeting Weekly meeting of the CDI EG and other community members discussing CDI 2.0 specification. When: Weekly from 18:00 to 19:00 on Tuesday Paris Where: IRC #cdi-dev channel on freenode Calendar: ASD Perso Who: * Antoine Sabot-Durand - organizer * cdi-dev Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev at lists.jboss.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161003/cdf83a42/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1681 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20161003/cdf83a42/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1737 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20161003/cdf83a42/attachment-0003.bin From asd at redhat.com Mon Oct 3 10:42:43 2016 From: asd at redhat.com (Antoine Sabot-Durand) Date: Mon, 03 Oct 2016 07:42:43 -0700 (PDT) Subject: [cdi-dev] =?utf-8?b?SW52aXRhdGlvbiDDoCBs4oCZw6l2w6luZW1lbnTCoDog?= =?utf-8?q?CDI_weekly_meeting?= Message-ID: An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161003/219b7761/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: iCal-Request.ics Type: text/calendar Size: 1849 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20161003/219b7761/attachment.bin From asabotdu at redhat.com Mon Oct 3 10:43:15 2016 From: asabotdu at redhat.com (asabotdu at redhat.com) Date: Mon, 03 Oct 2016 14:43:15 +0000 Subject: [cdi-dev] Invitation: CDI weekly meeting @ Weekly from 6pm to 7pm on Tuesday (CET) (asabotdu@redhat.com) Message-ID: <94eb2c0db40acf85a5053df6f630@google.com> You have been invited to the following event. Title: CDI weekly meeting Weekly meeting of the CDI EG and other community members discussing CDI 2.0 specification. When: Weekly from 6pm to 7pm on Tuesday Paris Where: IRC #cdi-dev channel on freenode Calendar: asabotdu at redhat.com Who: * asabotdu at redhat.com- organiser * cdi-dev Event details: https://www.google.com/calendar/event?action=VIEW&eid=XzZjcDQ4Z3BoNjBwa2FiOWo3MHMzOGI5azhkMzNjYjlwNjhxNGNiOWk4OTBrY2dwaDg0cDM4Z3BoNjQgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MTkjYXNhYm90ZHVAcmVkaGF0LmNvbTg5OGMwZjU1ZWQ4MGNlOTM4Y2Y5NmY2OTkwYTNhMjRjYWRiNjdjMTU&ctz=Europe/Paris&hl=en_GB Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev at lists.jboss.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161003/ba9c66c5/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2108 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20161003/ba9c66c5/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2173 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20161003/ba9c66c5/attachment-0001.bin From issues at jboss.org Tue Oct 4 09:09:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 4 Oct 2016 09:09:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-435) cdi-spec.org/faq outdated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-435: ----------------------------- Fix Version/s: (was: 2.0 (proposed)) > cdi-spec.org/faq outdated > ------------------------- > > Key: CDI-435 > URL: https://issues.jboss.org/browse/CDI-435 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > > Frequently asked questions at http://www.cdi-spec.org/faq/ are outdated - mostly in sync with CDI 1.0 or CDI 1.1. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 4 09:10:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 4 Oct 2016 09:10:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-435) cdi-spec.org/faq outdated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba resolved CDI-435. ------------------------------ Resolution: Migrated to another ITS https://github.com/cdi-spec/cdi-spec.org/issues/32 > cdi-spec.org/faq outdated > ------------------------- > > Key: CDI-435 > URL: https://issues.jboss.org/browse/CDI-435 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > > Frequently asked questions at http://www.cdi-spec.org/faq/ are outdated - mostly in sync with CDI 1.0 or CDI 1.1. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 4 20:02:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 4 Oct 2016 20:02:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-635) Session context activation In-Reply-To: References: Message-ID: John Ament created CDI-635: ------------------------------ Summary: Session context activation Key: CDI-635 URL: https://issues.jboss.org/browse/CDI-635 Project: CDI Specification Issues Issue Type: Feature Request Components: Contexts Affects Versions: 1.2.Final Reporter: John Ament This is split from discussions around CDI-30. It was agreed that session context management and request context management are two different things. CDI-30 is now targeted to just managing request contexts, this ticket is to manage session contexts. When considering this ticket, think of the following: - How to associate a context with multiple threads - How to look up a session context -- This message was sent by Atlassian JIRA (v6.4.11#64026) From john.ament at spartasystems.com Tue Oct 4 20:03:38 2016 From: john.ament at spartasystems.com (John Ament) Date: Wed, 5 Oct 2016 00:03:38 +0000 Subject: [cdi-dev] CDI-30 - Request Context management Message-ID: After discussions from last week where it was decided to split session and request context management, I've raised a PR https://github.com/cdi-spec/cdi/pull/305/files to introduce new controller, and entered a JIRA ticket https://issues.jboss.org/browse/CDI-635 to handle session context management John ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161005/7737ceed/attachment.html From issues at jboss.org Tue Oct 4 20:08:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 4 Oct 2016 20:08:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302601#comment-13302601 ] John Ament commented on CDI-535: -------------------------------- If you want sorting, shouldn't {{MyBeanInstance}} have some ordering capability? > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} > {code} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 4 20:09:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 4 Oct 2016 20:09:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-636) Add Instance.stream() In-Reply-To: References: Message-ID: John Ament created CDI-636: ------------------------------ Summary: Add Instance.stream() Key: CDI-636 URL: https://issues.jboss.org/browse/CDI-636 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.2.Final Reporter: John Ament Add the ability to stream all bean instances from an Instance. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 4 20:13:00 2016 From: issues at jboss.org (George Gastaldi (JIRA)) Date: Tue, 4 Oct 2016 20:13:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302603#comment-13302603 ] George Gastaldi commented on CDI-535: ------------------------------------- Why? Isn't that what priority is for? Or are you referring to implementing Comparable in this object? > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} > {code} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 02:15:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 5 Oct 2016 02:15:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302653#comment-13302653 ] Martin Kouba commented on CDI-535: ---------------------------------- [~meetoblivion] [~gastaldi] With priority annotation (or similar stuff) you could order the eligible beans even without instantiation. This might be useful in case of bean creation is rather expensive. But I'm not sure it's worth standardizing, esp. if {{@Priority}} currently cannot be used for all cases. > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} > {code} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 02:21:00 2016 From: issues at jboss.org (George Gastaldi (JIRA)) Date: Wed, 5 Oct 2016 02:21:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302654#comment-13302654 ] George Gastaldi commented on CDI-535: ------------------------------------- I think {{@Priority}} must be extended to support producer methods and fields, but for now I believe it?s fine to support it in a type-level usage only, WDYT?. For example, how different would a bean be from an interceptor that uses this same approach? > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} > {code} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 02:29:00 2016 From: issues at jboss.org (George Gastaldi (JIRA)) Date: Wed, 5 Oct 2016 02:29:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302661#comment-13302661 ] George Gastaldi commented on CDI-535: ------------------------------------- OTOH maybe we could look into a different approach by asking for ordering in the injection point itself (eg. {{@Inject @OrderBy(SOMETHING GOES HERE) Instance}}), but I?m not sure how would that work. Something to keep in the back of your mind :) > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} > {code} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 02:35:00 2016 From: issues at jboss.org (George Gastaldi (JIRA)) Date: Wed, 5 Oct 2016 02:35:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302654#comment-13302654 ] George Gastaldi edited comment on CDI-535 at 10/5/16 2:34 AM: -------------------------------------------------------------- I think {{@Priority}} must be extended to support producer methods and fields, but for now I believe it?s fine to support it in a type-level usage only, WDYT?. For example, how different would a bean be from an interceptor (or an Alternative) that uses this same approach? was (Author: gastaldi): I think {{@Priority}} must be extended to support producer methods and fields, but for now I believe it?s fine to support it in a type-level usage only, WDYT?. For example, how different would a bean be from an interceptor that uses this same approach? > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} > {code} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 02:38:00 2016 From: issues at jboss.org (Ochieng Marembo (JIRA)) Date: Wed, 5 Oct 2016 02:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302666#comment-13302666 ] Ochieng Marembo commented on CDI-535: ------------------------------------- I think using the ```@OrderBy``` qualifier would be more suited to situations where you have no control of all possible interface implementations. Depending on when the OrderBy is executed, it could be called the first time the instance list is actually requested for iteration, hence delaying instantiating expensive implementationd. Strictly the OrderBy cannot be a normal qualifier as it will force all instances to be so qualified, which for purposes of considering 3rd party implementations, would simply not work. We could have as an implicit qualifier. > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} > {code} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 02:43:00 2016 From: issues at jboss.org (George Gastaldi (JIRA)) Date: Wed, 5 Oct 2016 02:43:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302671#comment-13302671 ] George Gastaldi commented on CDI-535: ------------------------------------- [~marembo2008], I agree, so in order to avoid instantiating the objects and comparing against each other, I think using {{@Priority}} or another kind of comparison (eg. annotation) in the type declaration would be a better choice. > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} > {code} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 02:48:00 2016 From: issues at jboss.org (George Gastaldi (JIRA)) Date: Wed, 5 Oct 2016 02:48:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Gastaldi updated CDI-535: -------------------------------- Description: We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. h3. Use case: Developer always define a kind of chain of processor beans, which may need to run in specific order. h3. Current scenario: Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: #1 {code:java} private Iterable myBeans; @Inject void injectBeans(@Any Instance myBeans) { //the create order does some kind of ordering on the beans. this.myBeans = createOrder(myBeans); } {code} #2 This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. {code:java} @Any @Inject private Instance myBeans; public void doSomething() { Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); } {code} h3. Our Proposal We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} {code:java} public interface MyBeanInterface {} @MyQualifier @Priority(0) public class MyFirstBean implements MyBeanInterface{ } @MyQualifier @Priority(2) public class MySecondBean implements MyBeanInterface{ } @ApplicationScoped public class MyBeanProcessor { //We expect that this injected instances shall be in order based on the @Priority annotation @Any @Inject private Instance myBeans; } {code} was: We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. h3. Use case: Developer always define a kind of chain of processor beans, which may need to run in specific order. h3. Current scenario: Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: #1 {code} private Iterable myBeans; @Inject void injectBeans(@Any Instance myBeans) { //the create order does some kind of ordering on the beans. this.myBeans = createOrder(myBeans); } {code} #2 This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. {code} @Any @Inject private Instance myBeans; public void doSomething() { Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); } {code} h3. Our Proposal We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} {code} public interface MyBeanInterface {} @MyQualifier @Priority(0) public class MyFirstBean implements MyBeanInterface{ } @MyQualifier @Priority(2) public class MySecondBean implements MyBeanInterface{ } @ApplicationScoped public class MyBeanProcessor { //We expect that this injected instances shall be in order based on the @Priority annotation @Any @Inject private Instance myBeans; } {code} > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code:java} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code:java} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} > {code:java} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 02:50:00 2016 From: issues at jboss.org (George Gastaldi (JIRA)) Date: Wed, 5 Oct 2016 02:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Gastaldi updated CDI-535: -------------------------------- Description: We should allow ordering of bean instance injection using the {{Instance}} when an instance injection is used. h3. Use case: Developer always define a kind of chain of processor beans, which may need to run in specific order. h3. Current scenario: Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: #1 {code:java} private Iterable myBeans; @Inject void injectBeans(@Any Instance myBeans) { //the create order does some kind of ordering on the beans. this.myBeans = createOrder(myBeans); } {code} #2 This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. {code:java} @Any @Inject private Instance myBeans; public void doSomething() { Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); } {code} h3. Our Proposal We already have {{javax.annotation.Priority}} or any cdi specific annotation which we can add to {{MyBeanInterfaceImpl}} so that on injection of an {{Instance}}, all possible injection values are sorted based on the {{Priority.value()}} and if no annotation is defined, defaults to {{Priority.value = Integer.MAX_VALUE}} {code:java} public interface MyBeanInterface {} @MyQualifier @Priority(0) public class MyFirstBean implements MyBeanInterface{ } @MyQualifier @Priority(2) public class MySecondBean implements MyBeanInterface{ } @ApplicationScoped public class MyBeanProcessor { //We expect that this injected instances shall be in order based on the @Priority annotation @Any @Inject private Instance myBeans; } {code} was: We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. h3. Use case: Developer always define a kind of chain of processor beans, which may need to run in specific order. h3. Current scenario: Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: #1 {code:java} private Iterable myBeans; @Inject void injectBeans(@Any Instance myBeans) { //the create order does some kind of ordering on the beans. this.myBeans = createOrder(myBeans); } {code} #2 This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. {code:java} @Any @Inject private Instance myBeans; public void doSomething() { Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); } {code} h3. Our Proposal We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} {code:java} public interface MyBeanInterface {} @MyQualifier @Priority(0) public class MyFirstBean implements MyBeanInterface{ } @MyQualifier @Priority(2) public class MySecondBean implements MyBeanInterface{ } @ApplicationScoped public class MyBeanProcessor { //We expect that this injected instances shall be in order based on the @Priority annotation @Any @Inject private Instance myBeans; } {code} > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the {{Instance}} when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code:java} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code:java} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {{javax.annotation.Priority}} or any cdi specific annotation which we can add to {{MyBeanInterfaceImpl}} so that on injection of an {{Instance}}, all possible injection values are sorted based on the {{Priority.value()}} and if no annotation is defined, defaults to {{Priority.value = Integer.MAX_VALUE}} > {code:java} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 02:53:00 2016 From: issues at jboss.org (George Gastaldi (JIRA)) Date: Wed, 5 Oct 2016 02:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302678#comment-13302678 ] George Gastaldi commented on CDI-535: ------------------------------------- By the way, in my example above {{@OrderBy}} is not meant to be a {{@Qualifier}}, just a marker annotation > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the {{Instance}} when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code:java} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code:java} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {{javax.annotation.Priority}} or any cdi specific annotation which we can add to {{MyBeanInterfaceImpl}} so that on injection of an {{Instance}}, all possible injection values are sorted based on the {{Priority.value()}} and if no annotation is defined, defaults to {{Priority.value = Integer.MAX_VALUE}} > {code:java} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 03:17:01 2016 From: issues at jboss.org (Ochieng Marembo (JIRA)) Date: Wed, 5 Oct 2016 03:17:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-452) Specify that web scoped (request, session, application) beans are injectable in async servlets In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302687#comment-13302687 ] Ochieng Marembo commented on CDI-452: ------------------------------------- [~arjant] for javaee ejb environment, that works. But CDI is not meant primarily for a full java ee environment. Infact, most people prefer using CDI outside the bounds of ejb-containers, as ejb is relegated to heavy weight transactional backend-services, and for application which are not transactional, using ejb's for its security and role context would not suffice. > Specify that web scoped (request, session, application) beans are injectable in async servlets > ---------------------------------------------------------------------------------------------- > > Key: CDI-452 > URL: https://issues.jboss.org/browse/CDI-452 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts, Java EE integration > Affects Versions: 1.0 > Reporter: Ed Burns > Assignee: John Ament > Fix For: 2.0 (discussion) > > > Consider this code based on this blog post: < https://weblogs.java.net/blog/swchan2/archive/2013/06/06/asynchronous-servlet-and-java-ee-concurrency-utilities >. > {code} > @WebServlet(urlPatterns="/test2", asyncSupported=true) > public class TestAsyncMESServlet extends HttpServlet { > @Resource > private ManagedExecutorService managedExecutorService; > @Inject > MyRunnableImpl myRunnableImpl; > @Override > protected void doGet(HttpServletRequest req, HttpServletResponse res) > throws ServletException, IOException { > final AsyncContext asyncContext = req.startAsync(); > final PrintWriter writer = res.getWriter(); > managedExecutorService.submit(myRunnableImpl); > } > public static class MyRunnableImpl implements Runnable { > @Inject > Bean bean; // Bean is @RequestScoped > @Override > public void run() { > writer.println("Done"); > asyncContext.complete(); > } > } > } > {code} > According to Jozef Hartzinger, this currently does not work, because only @Dependent and @ApplicationScoped beans are propagated to the new thread. To keep CDI relevant in light of the reactive programming movement and the popularity of node.js, we need to make this work. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 03:31:00 2016 From: issues at jboss.org (arjan tijms (JIRA)) Date: Wed, 5 Oct 2016 03:31:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-452) Specify that web scoped (request, session, application) beans are injectable in async servlets In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302698#comment-13302698 ] arjan tijms commented on CDI-452: --------------------------------- [~marembo2008] The mentioned opaque security context is not particular to EJB. In fact, CDI already makes use of it by having a build-in bean for {{Principal}}, meaning you can do {{@Inject Principal principal}}. And Servlet containers use the same thing via web.xml constraints and things like {{HttpServletRequest.getUserPrincipal}}. So nothing of what I mentioned is EJB specific. Even things like {{@RolesAllowed}} are in fact not EJB (they're from Common Annotations, aka JSR 250), and every spec, including CDI can use it. This is also one of the goals of JSR 375 (Java EE Security API). > Specify that web scoped (request, session, application) beans are injectable in async servlets > ---------------------------------------------------------------------------------------------- > > Key: CDI-452 > URL: https://issues.jboss.org/browse/CDI-452 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts, Java EE integration > Affects Versions: 1.0 > Reporter: Ed Burns > Assignee: John Ament > Fix For: 2.0 (discussion) > > > Consider this code based on this blog post: < https://weblogs.java.net/blog/swchan2/archive/2013/06/06/asynchronous-servlet-and-java-ee-concurrency-utilities >. > {code} > @WebServlet(urlPatterns="/test2", asyncSupported=true) > public class TestAsyncMESServlet extends HttpServlet { > @Resource > private ManagedExecutorService managedExecutorService; > @Inject > MyRunnableImpl myRunnableImpl; > @Override > protected void doGet(HttpServletRequest req, HttpServletResponse res) > throws ServletException, IOException { > final AsyncContext asyncContext = req.startAsync(); > final PrintWriter writer = res.getWriter(); > managedExecutorService.submit(myRunnableImpl); > } > public static class MyRunnableImpl implements Runnable { > @Inject > Bean bean; // Bean is @RequestScoped > @Override > public void run() { > writer.println("Done"); > asyncContext.complete(); > } > } > } > {code} > According to Jozef Hartzinger, this currently does not work, because only @Dependent and @ApplicationScoped beans are propagated to the new thread. To keep CDI relevant in light of the reactive programming movement and the popularity of node.js, we need to make this work. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 03:37:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 5 Oct 2016 03:37:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-636) Add Instance.stream() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302701#comment-13302701 ] Martin Kouba commented on CDI-636: ---------------------------------- For the record, even now it's possible to use {{StreamSupport.stream(instance.spliterator(), false)}}. But I agree that {{instance.stream()}} is more convenient. > Add Instance.stream() > --------------------- > > Key: CDI-636 > URL: https://issues.jboss.org/browse/CDI-636 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: John Ament > > Add the ability to stream all bean instances from an Instance. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 03:54:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Wed, 5 Oct 2016 03:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-636) Add Instance.stream() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302708#comment-13302708 ] Romain Manni-Bucau commented on CDI-636: ---------------------------------------- Just an idea but why an instance wouldn't be a Stream? > Add Instance.stream() > --------------------- > > Key: CDI-636 > URL: https://issues.jboss.org/browse/CDI-636 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: John Ament > > Add the ability to stream all bean instances from an Instance. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 04:12:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 5 Oct 2016 04:12:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-636) Add Instance.stream() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302716#comment-13302716 ] Martin Kouba commented on CDI-636: ---------------------------------- [~rmannibucau] I believe it shouldn't be - for the same reason as it's not {{Iterator}} but {{Iterable}}. {{Instance}} is a source, not a "pipeline". > Add Instance.stream() > --------------------- > > Key: CDI-636 > URL: https://issues.jboss.org/browse/CDI-636 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: John Ament > > Add the ability to stream all bean instances from an Instance. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 04:16:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Wed, 5 Oct 2016 04:16:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-636) Add Instance.stream() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302719#comment-13302719 ] Romain Manni-Bucau commented on CDI-636: ---------------------------------------- Right forget it, Streams are not "reusable" which would break half of the usages so stream() is a good compromise > Add Instance.stream() > --------------------- > > Key: CDI-636 > URL: https://issues.jboss.org/browse/CDI-636 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: John Ament > > Add the ability to stream all bean instances from an Instance. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 08:55:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Wed, 5 Oct 2016 08:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302923#comment-13302923 ] John Ament commented on CDI-535: -------------------------------- I would say more than anything, my concern is on the reuse/misuse of {{Priority}} and using something new like {{OrderBy}} would not be an issue. Priority introduces misuse in my opinion. Even then, if you have multiple beans, all from the same field (all dependent scoped for example), how would you order them? > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the {{Instance}} when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code:java} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code:java} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {{javax.annotation.Priority}} or any cdi specific annotation which we can add to {{MyBeanInterfaceImpl}} so that on injection of an {{Instance}}, all possible injection values are sorted based on the {{Priority.value()}} and if no annotation is defined, defaults to {{Priority.value = Integer.MAX_VALUE}} > {code:java} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 09:19:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 5 Oct 2016 09:19:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302950#comment-13302950 ] Martin Kouba commented on CDI-535: ---------------------------------- [~meetoblivion] [~gastaldi] I don't think {{@Priority}} would introduce a misuse here: {quote} The Priority annotation can be applied to classes to indicate in what order the classes should be used. The effect of using the Priority annotation in any particular instance is defined by other specifications that define the use of a specific class. {quote} But as I said we would not be able to add priority to producer methods and fields. So it's -1. A new annotation might work as well. {{OrderBy}} would be mixed up with {{javax.persistence.OrderBy}}. bq. Even then, if you have multiple beans, all from the same field... How could that happen? > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the {{Instance}} when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code:java} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code:java} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {{javax.annotation.Priority}} or any cdi specific annotation which we can add to {{MyBeanInterfaceImpl}} so that on injection of an {{Instance}}, all possible injection values are sorted based on the {{Priority.value()}} and if no annotation is defined, defaults to {{Priority.value = Integer.MAX_VALUE}} > {code:java} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 6 05:16:04 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 6 Oct 2016 05:16:04 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-580: ---------------------------------------- Assignee: Antoine Sabot-Durand > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 6 05:16:04 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 6 Oct 2016 05:16:04 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303334#comment-13303334 ] Antoine Sabot-Durand commented on CDI-580: ------------------------------------------ During F2F we designed an API allowing creation of proxys needed for Interceptors and decorators. This would allow adding them to custom bean as well. > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 6 05:16:06 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 6 Oct 2016 05:16:06 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-580 started by Antoine Sabot-Durand. ------------------------------------------------ > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 6 05:17:03 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 6 Oct 2016 05:17:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-580: ------------------------------------- Fix Version/s: 2.0.Final > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Fix For: 2.0.Final > > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From builds at travis-ci.org Thu Oct 6 05:30:21 2016 From: builds at travis-ci.org (Travis CI) Date: Thu, 06 Oct 2016 09:30:21 +0000 Subject: [cdi-dev] Passed: cdi-spec/cdi#65 (revert-300-CDI-626 - 29b1e30) In-Reply-To: Message-ID: <57f619ad7ddcd_33fd2ca08e6c0101745@01f6158c-f4b4-49be-ab65-bf9ef413ae70.mail> Build Update for cdi-spec/cdi ------------------------------------- Build: #65 Status: Passed Duration: 7 minutes and 4 seconds Commit: 29b1e30 (revert-300-CDI-626) Author: Antoine Sabot-Durand Message: Revert "CDI-626 How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?" View the changeset: https://github.com/cdi-spec/cdi/commit/29b1e30a3423 View the full build log and details: https://travis-ci.org/cdi-spec/cdi/builds/165469838 -- 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/20161006/4ef89793/attachment.html From issues at jboss.org Fri Oct 7 05:07:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 05:07:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Intoroduce BeanManager.event() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-633: ------------------------------------- Sprint: Sprint 1 > Intoroduce BeanManager.event() > ------------------------------ > > Key: CDI-633 > URL: https://issues.jboss.org/browse/CDI-633 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types > * the method should return {{javax.enterprise.event.Event}} with no qualifiers -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 05:08:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 05:08:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-580: ------------------------------------- Sprint: Sprint 1 > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Fix For: 2.0.Final > > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 05:23:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 05:23:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-557) Chapter "10.4.3. The EventMetadata interface" mentions fireAsyncEvent method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-557: ------------------------------------- Fix Version/s: 2.0-EDR2 > Chapter "10.4.3. The EventMetadata interface" mentions fireAsyncEvent method > ---------------------------------------------------------------------------- > > Key: CDI-557 > URL: https://issues.jboss.org/browse/CDI-557 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Tomas Remes > Assignee: Antoine Sabot-Durand > Priority: Minor > Fix For: 2.0-EDR2 > > > http://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html#event_metadata > In paragraph for isAsync method there is: > {quote} > isAsync() returns true if the event was fired with fireAsync() or fireAsyncEvent() methods otherwise returns false. > {quote} > AFAIK There is no such method. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 05:36:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 05:36:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-373) XML schema http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd is password protected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-373: ------------------------------------- Fix Version/s: 1.1.Final > XML schema http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd is password protected > --------------------------------------------------------------------------------- > > Key: CDI-373 > URL: https://issues.jboss.org/browse/CDI-373 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: David Konecny > Priority: Blocker > Fix For: 1.1.Final > > > Today I tried to access http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd and I was redirected to https://login.oracle.com/mysso/signon.jsp page. This used to work in the past. The same happens if I try to access the schema via http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html#7 page. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 05:41:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 05:41:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-87) Declarative control over classes including in bean archive scanning In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-87: ------------------------------------ Fix Version/s: 1.1.Final (was: TBD) > Declarative control over classes including in bean archive scanning > ------------------------------------------------------------------- > > Key: CDI-87 > URL: https://issues.jboss.org/browse/CDI-87 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.Final > > > Weld introduced a XML syntax for this -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 05:53:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 05:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-269) Fire ProcessAnnotatedType for annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reopened CDI-269: -------------------------------------- Bad resolution status since it was not rejected bud done > Fire ProcessAnnotatedType for annotations > ----------------------------------------- > > Key: CDI-269 > URL: https://issues.jboss.org/browse/CDI-269 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.PRD > > > If we fire a PAT event for annotations, the members can have @Nonbinding added -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 05:54:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 05:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-269) Fire ProcessAnnotatedType for annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-269. -------------------------------------- Resolution: Done > Fire ProcessAnnotatedType for annotations > ----------------------------------------- > > Key: CDI-269 > URL: https://issues.jboss.org/browse/CDI-269 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.PRD > > > If we fire a PAT event for annotations, the members can have @Nonbinding added -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 05:56:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 05:56:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-269) Fire ProcessAnnotatedType for annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reopened CDI-269: -------------------------------------- > Fire ProcessAnnotatedType for annotations > ----------------------------------------- > > Key: CDI-269 > URL: https://issues.jboss.org/browse/CDI-269 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.PRD > > > If we fire a PAT event for annotations, the members can have @Nonbinding added -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 05:56:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 05:56:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-269) Fire ProcessAnnotatedType for annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-269. ------------------------------------ Resolution: Rejected > Fire ProcessAnnotatedType for annotations > ----------------------------------------- > > Key: CDI-269 > URL: https://issues.jboss.org/browse/CDI-269 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.PRD > > > If we fire a PAT event for annotations, the members can have @Nonbinding added -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 05:56:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 05:56:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-138) Allow an extension to register an interceptor bindings and qualifiers with an AnnotatedType In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reopened CDI-138: -------------------------------------- > Allow an extension to register an interceptor bindings and qualifiers with an AnnotatedType > ------------------------------------------------------------------------------------------- > > Key: CDI-138 > URL: https://issues.jboss.org/browse/CDI-138 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Interceptors, Portable Extensions > Affects Versions: 1.0, 1.1.EDR > Reporter: Kevin Pollet > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.PRD > > > At BeforeBeanDiscovery phase an interceptor binding could be added with an {{AnnotatedType}} instead of annotation class. This could allow to add annotations to existing annotation attributes. > For example this case is needed for annotations {{@CacheResult}}, {{@CacheRemoveEntry}} and {{@CacheRemoveAll}} from JSR-107 which haven't annotation attributes annotated with {{@NonBinding}}. > The method signature could be: > * {{BeforeBeanDiscovery#addInterceptorBinding(AnnotatedType annotatedType, Annotation... bindingTypeDef)}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 05:56:03 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 05:56:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-138) Allow an extension to register an interceptor bindings and qualifiers with an AnnotatedType In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-138. -------------------------------------- Resolution: Done > Allow an extension to register an interceptor bindings and qualifiers with an AnnotatedType > ------------------------------------------------------------------------------------------- > > Key: CDI-138 > URL: https://issues.jboss.org/browse/CDI-138 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Interceptors, Portable Extensions > Affects Versions: 1.0, 1.1.EDR > Reporter: Kevin Pollet > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.PRD > > > At BeforeBeanDiscovery phase an interceptor binding could be added with an {{AnnotatedType}} instead of annotation class. This could allow to add annotations to existing annotation attributes. > For example this case is needed for annotations {{@CacheResult}}, {{@CacheRemoveEntry}} and {{@CacheRemoveAll}} from JSR-107 which haven't annotation attributes annotated with {{@NonBinding}}. > The method signature could be: > * {{BeforeBeanDiscovery#addInterceptorBinding(AnnotatedType annotatedType, Annotation... bindingTypeDef)}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 05:57:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 05:57:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-138) Allow an extension to register an interceptor bindings and qualifiers with an AnnotatedType In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-138. ------------------------------------ > Allow an extension to register an interceptor bindings and qualifiers with an AnnotatedType > ------------------------------------------------------------------------------------------- > > Key: CDI-138 > URL: https://issues.jboss.org/browse/CDI-138 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Interceptors, Portable Extensions > Affects Versions: 1.0, 1.1.EDR > Reporter: Kevin Pollet > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.PRD > > > At BeforeBeanDiscovery phase an interceptor binding could be added with an {{AnnotatedType}} instead of annotation class. This could allow to add annotations to existing annotation attributes. > For example this case is needed for annotations {{@CacheResult}}, {{@CacheRemoveEntry}} and {{@CacheRemoveAll}} from JSR-107 which haven't annotation attributes annotated with {{@NonBinding}}. > The method signature could be: > * {{BeforeBeanDiscovery#addInterceptorBinding(AnnotatedType annotatedType, Annotation... bindingTypeDef)}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 07:24:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 07:24:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-634) Clarify contextual reference validity to a bean with a normal scope in Java SE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-634: ------------------------------------- Fix Version/s: 2.0 .Final > Clarify contextual reference validity to a bean with a normal scope in Java SE > ------------------------------------------------------------------------------ > > Key: CDI-634 > URL: https://issues.jboss.org/browse/CDI-634 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > In Java SE, a user might be tempted to share a contextual reference for a normal scoped bean (client proxy) between multiple "deployments" of a single application, e.g.: > # start CDI container > # get a reference > # stop CDI container > # start CDI container again and try to use the stored reference. > I believe such a reference should not be valid after an application stopped (contexts are destroyed, etc.). Right now, it seems to be undefined. > See also WELD-2190. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 07:28:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 07:28:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-224) Support Decoration of no interface beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-224: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: 2.0 .Final) > Support Decoration of no interface beans > ---------------------------------------- > > Key: CDI-224 > URL: https://issues.jboss.org/browse/CDI-224 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators > Affects Versions: 1.0 > Reporter: Aslak Knutsen > Assignee: Antoine Sabot-Durand > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > According to CDI 1.0 Spec: > "Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean." > "The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for java.io.Serializable. The decorator bean class and its superclasses are not decorated types of the decorator." > Both CDI and EJB support No interface beans, but for some reason Decorators only work on methods from a Interface. While Interceptors on the other hand work fine with Classes. > I can see no technical reason to why Decorators should only work on Interfaces since all Proxies etc should already be in place. > {code} > import javax.decorator.Decorator; > import javax.decorator.Delegate; > import javax.enterprise.inject.Any; > import javax.inject.Inject; > import junit.framework.Assert; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.shrinkwrap.api.ShrinkWrap; > import org.jboss.shrinkwrap.api.spec.WebArchive; > import org.jboss.shrinkwrap.impl.BeansXml; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class DecoratesClassTestCase { > @Deployment > public static WebArchive create() { > return ShrinkWrap.create(WebArchive.class) > .addAsWebInfResource( > new BeansXml().decorators(BusinessDecorator.class), "beans.xml"); > } > > @Test > public void shouldBeAbleToDecorate(BusinessObject business) throws Exception { > Assert.assertEquals("Decorated Test", business.send("Test")); > } > > @Decorator > public static abstract class BusinessDecorator extends BusinessObject { > @Inject @Delegate @Any > private BusinessObject delegate; > > public String send(String msg) { > return "Decorated " + delegate.send(msg); > } > } > > public static class BusinessObject { > > public String send(String msg) { > return msg; > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 07:30:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 07:30:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-526) Include filters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-526: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: 2.0 .Final) > Include filters > --------------- > > Key: CDI-526 > URL: https://issues.jboss.org/browse/CDI-526 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > CDI has support for exclude filters in the beans.xml where a certain part of a bean archive (no matter whether "annotated" or "all" type) can be excluded from CDI processing on a package level, e.g: > {code:XML} > > {code} > With the rise of fat jars and CDI support for SE it would also be useful to be able to define an include filter. Suppose we have a single large jar file with all its dependencies shaded in. This jar file has the beans.xml file which means that all the packages in that file are processed (all classes are at least scanned for bean defining annotations or even turned into CDI beans in "all" mode). We can obviously add a couple of exclude filters for each of the libraries we do not want to scan. It would however be much nicer if we could define a single include filter e.g.: > {code:XML} > > {code} > Other packages (that belong to shaded-in libraries) in the same jar would not be scanned at all. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 07:31:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 07:31:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-613) Container should be able to receive information about the context in which it was bootstraped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-613: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: 2.0 .Final) > Container should be able to receive information about the context in which it was bootstraped > --------------------------------------------------------------------------------------------- > > Key: CDI-613 > URL: https://issues.jboss.org/browse/CDI-613 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > Today it's impossible to know what is the outside context of the CDI container (i.e what is the application or EE module it belongs to). > This is problematic for other spec like JPA who needs to retrieve their information (persistence units) from a portable extension. > This would help solving issues like WFLY-2387 in a portable way. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 07:33:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 07:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Intoroduce BeanManager.event() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-633: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Intoroduce BeanManager.event() > ------------------------------ > > Key: CDI-633 > URL: https://issues.jboss.org/browse/CDI-633 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types > * the method should return {{javax.enterprise.event.Event}} with no qualifiers -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 07:47:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 07:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-613) Container should be able to receive information about the context in which it was bootstraped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-613: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Container should be able to receive information about the context in which it was bootstraped > --------------------------------------------------------------------------------------------- > > Key: CDI-613 > URL: https://issues.jboss.org/browse/CDI-613 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: Antoine Sabot-Durand > Fix For: TBD > > > Today it's impossible to know what is the outside context of the CDI container (i.e what is the application or EE module it belongs to). > This is problematic for other spec like JPA who needs to retrieve their information (persistence units) from a portable extension. > This would help solving issues like WFLY-2387 in a portable way. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 07:47:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 07:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-612) ObserverMethodConfigurator.notifyWith() should probably accept a functional interface whose method throws java.lang.Exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-612: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > ObserverMethodConfigurator.notifyWith() should probably accept a functional interface whose method throws java.lang.Exception > ----------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-612 > URL: https://issues.jboss.org/browse/CDI-612 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > The regular observer methods may also throw checked exceptions (wrapped and rethrown as an (unchecked) {{ObserverException}}). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 07:52:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 07:52: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:all-tabpanel ] Antoine Sabot-Durand resolved CDI-601. -------------------------------------- Resolution: Duplicate Issue Duplicates CDI-625 > 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 Fri Oct 7 07:54:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 07:54:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-593) Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-593: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc > ------------------------------------------------------------------------------------ > > Key: CDI-593 > URL: https://issues.jboss.org/browse/CDI-593 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > * javadoc would definitely deserve some more info > * the spec text should mention this interface as well and describe basic use cases (e.g. an interceptor passed to {{AfterBeanDiscovery.addBean()}} and implementing this interface is globally enabled) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 07:55:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 07:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-592) Consider adding ObserverMethod.notify() method which also accepts EventMetadata In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-592: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Consider adding ObserverMethod.notify() method which also accepts EventMetadata > ------------------------------------------------------------------------------- > > Key: CDI-592 > URL: https://issues.jboss.org/browse/CDI-592 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > {code:java} > // Make the original method also default so that new impls don't need to implement two methods > default void notify(T event) { > // No-op > } > // The container should always call this method... > default void notify(T event, EventMetadata metadata) { > notify(event); > } > {code} > This should not break existing implementations. The truth is a custom impl will not be forced to implement any {{notify()}} method. But I think the benefits are worth it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 07:59:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 07:59:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-561) Add the possibility to unmanage a bean instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-561: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Add the possibility to unmanage a bean instance > ----------------------------------------------- > > Key: CDI-561 > URL: https://issues.jboss.org/browse/CDI-561 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Fix For: TBD > > > CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful > * Accessing the true class of the instance in a clean way > * Being able to capture an instance state to use its information outside CDI or as an event payload > The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. > We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 08:00:03 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 08:00:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-546) Constant for default observer priority In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-546: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Constant for default observer priority > -------------------------------------- > > Key: CDI-546 > URL: https://issues.jboss.org/browse/CDI-546 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Priority: Minor > Fix For: 2.0 .Final > > > Currently we use: > {code:JAVA} > @Override > public default int getPriority() { > return javax.interceptor.Interceptor.Priority.APPLICATION + 500; > }; > {code} > It would be nice to have the value stored as a constant e.g.: > {code:JAVA} > int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500; > {code} > so that other code can reference it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 08:00:12 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 08:00:12 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-541: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Ordering of async observers (vs sync observers) is not specified > ---------------------------------------------------------------- > > Key: CDI-541 > URL: https://issues.jboss.org/browse/CDI-541 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > Fix For: TBD > > > I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? > For example: > {{event.fireAsync(new Message());}} > {code} > public class First { > > void observeMessage(@Observes @Priority(2000) Message message){} > } > {code} > {code} > public class Second { > > void observeMessage(@ObservesAsync @Priority(2100) Message message){} > } > {code} > {code} > public class Third { > > void observeMessage(@Observes @Priority(2200) Message message){} > } > {code} > {code} > public class Fourth { > > void observeMessage(@ObservesAsync @Priority(2300) Message message){} > } > {code} > What will be the order in this case? First, Third, Second, Fourth? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 08:15:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 08:15:02 -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=13304210#comment-13304210 ] Antoine Sabot-Durand commented on CDI-623: ------------------------------------------ During F2F meeting we agreed on the following wording: {quote}If the container is unable to process configurator it will be treated as a deployement problem{quote} > 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 > Labels: F2F2016 > Fix For: 2.0 .Final > > > 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 issues at jboss.org Fri Oct 7 08:15:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 08:15:02 -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=13304210#comment-13304210 ] Antoine Sabot-Durand edited comment on CDI-623 at 10/7/16 8:14 AM: ------------------------------------------------------------------- During F2F meeting we agreed on the following wording: {quote}If the container is unable to process configurator it will be treated as a deployment problem{quote} was (Author: antoinesabot-durand): During F2F meeting we agreed on the following wording: {quote}If the container is unable to process configurator it will be treated as a deployement problem{quote} > 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 > Labels: F2F2016 > Fix For: 2.0 .Final > > > 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 issues at jboss.org Fri Oct 7 08:16:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 08:16:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-526) Include filters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-526: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Include filters > --------------- > > Key: CDI-526 > URL: https://issues.jboss.org/browse/CDI-526 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: TBD > > > CDI has support for exclude filters in the beans.xml where a certain part of a bean archive (no matter whether "annotated" or "all" type) can be excluded from CDI processing on a package level, e.g: > {code:XML} > > {code} > With the rise of fat jars and CDI support for SE it would also be useful to be able to define an include filter. Suppose we have a single large jar file with all its dependencies shaded in. This jar file has the beans.xml file which means that all the packages in that file are processed (all classes are at least scanned for bean defining annotations or even turned into CDI beans in "all" mode). We can obviously add a couple of exclude filters for each of the libraries we do not want to scan. It would however be much nicer if we could define a single include filter e.g.: > {code:XML} > > {code} > Other packages (that belong to shaded-in libraries) in the same jar would not be scanned at all. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 08:18:05 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 08:18:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-523) CDI spec tries to dispose a container-managed entity manager. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304212#comment-13304212 ] Antoine Sabot-Durand commented on CDI-523: ------------------------------------------ So example should be changed. Do you have suggestion to demonstrated disposer with a basic example ? > CDI spec tries to dispose a container-managed entity manager. > ------------------------------------------------------------- > > Key: CDI-523 > URL: https://issues.jboss.org/browse/CDI-523 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final, 1.1.Final > Reporter: Martin Andersson > Fix For: 2.0 .Final > > > Section "3.5.2. Declaring a disposer method" has this example: > {code:java} > public class Resources { > @PersistenceContext > @Produces @UserDatabase > private EntityManager em; > > public void close(@Disposes @UserDatabase EntityManager em) { > em.close(); > } > } > {code} > The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says: > {quote} > The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager. > {quote} > This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java]. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 08:18:05 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 08:18:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-523) CDI spec tries to dispose a container-managed entity manager. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-523: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > CDI spec tries to dispose a container-managed entity manager. > ------------------------------------------------------------- > > Key: CDI-523 > URL: https://issues.jboss.org/browse/CDI-523 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final, 1.1.Final > Reporter: Martin Andersson > Fix For: 2.0 .Final > > > Section "3.5.2. Declaring a disposer method" has this example: > {code:java} > public class Resources { > @PersistenceContext > @Produces @UserDatabase > private EntityManager em; > > public void close(@Disposes @UserDatabase EntityManager em) { > em.close(); > } > } > {code} > The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says: > {quote} > The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager. > {quote} > This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java]. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From werner.keil at gmail.com Fri Oct 7 08:39:24 2016 From: werner.keil at gmail.com (Werner Keil) Date: Fri, 7 Oct 2016 14:39:24 +0200 Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Intoroduce BeanManager.event() Message-ID: The confusion between the existing BeanManager.fireEvent() (JIRA comments sometimes just call it "fire") and this newly proposed method should be avoided. Backward-compatibility means the existing ones should still work as they do of course. What's the rationale behind just wanting to call it "event". It would return an Event object. All but the void methods (including fireEvent) follow certain conventions like - get* - create* - is* - are* depending on what they return. Why would a non-void non-static method of an existing interface that returns something suddenly break with these conventions? If the existing fireEvent method did not exist, it may be less problematic, though other than the static accessor method current() in the CDI class, I am not aware of interfaces doing that so far. However having fireEvent in the same interface, just calling a "getter" method event() makes that even more ambiguous and easy to misinterpret. Werner On Fri, Oct 7, 2016 at 1:59 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. [JBoss JIRA] (CDI-224) Support Decoration of no interface > beans (Antoine Sabot-Durand (JIRA)) > 2. [JBoss JIRA] (CDI-526) Include filters > (Antoine Sabot-Durand (JIRA)) > 3. [JBoss JIRA] (CDI-613) Container should be able to receive > information about the context in which it was bootstraped > (Antoine Sabot-Durand (JIRA)) > 4. [JBoss JIRA] (CDI-633) Intoroduce BeanManager.event() > (Antoine Sabot-Durand (JIRA)) > 5. [JBoss JIRA] (CDI-613) Container should be able to receive > information about the context in which it was bootstraped > (Antoine Sabot-Durand (JIRA)) > 6. [JBoss JIRA] (CDI-612) > ObserverMethodConfigurator.notifyWith() should probably accept a > functional interface whose method throws java.lang.Exception > (Antoine Sabot-Durand (JIRA)) > 7. [JBoss JIRA] (CDI-601) Add container lifecycle event fired > before container destroys all contexts (Antoine Sabot-Durand (JIRA)) > 8. [JBoss JIRA] (CDI-593) Mention > javax.enterprise.inject.spi.Prioritized in spec text and improve > its javadoc (Antoine Sabot-Durand (JIRA)) > 9. [JBoss JIRA] (CDI-592) Consider adding > ObserverMethod.notify() method which also accepts EventMetadata > (Antoine Sabot-Durand (JIRA)) > 10. [JBoss JIRA] (CDI-561) Add the possibility to unmanage a bean > instance (Antoine Sabot-Durand (JIRA)) > > > ---------------------------------------------------------------------- > > Message: 4 > Date: Fri, 7 Oct 2016 07:33:00 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Intoroduce > BeanManager.event() > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ https://issues.jboss.org/browse/CDI-633?page=com. > atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Antoine Sabot-Durand updated CDI-633: > ------------------------------------- > Fix Version/s: 2.0 .Final > (was: 2.0 (discussion)) > > > > Intoroduce BeanManager.event() > > ------------------------------ > > > > Key: CDI-633 > > URL: https://issues.jboss.org/browse/CDI-633 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Reporter: Martin Kouba > > Fix For: 2.0 .Final > > > > > > * this would allow to define the _specified type_ - the container may > use the specified type to infer the parameterized type of the event types > > * the method should return {{javax.enterprise.event.Event}} > with no qualifiers > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 5 > Date: Fri, 7 Oct 2016 07:47:00 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-613) Container should be able to > receive information about the context in which it was bootstraped > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ https://issues.jboss.org/browse/CDI-613?page=com. > atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Antoine Sabot-Durand updated CDI-613: > ------------------------------------- > Fix Version/s: TBD > (was: 2.0 (discussion)) > > > > Container should be able to receive information about the context in > which it was bootstraped > > ------------------------------------------------------------ > --------------------------------- > > > > Key: CDI-613 > > URL: https://issues.jboss.org/browse/CDI-613 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Components: Java EE integration > > Reporter: Antoine Sabot-Durand > > Fix For: TBD > > > > > > Today it's impossible to know what is the outside context of the CDI > container (i.e what is the application or EE module it belongs to). > > This is problematic for other spec like JPA who needs to retrieve their > information (persistence units) from a portable extension. > > This would help solving issues like WFLY-2387 in a portable way. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 6 > Date: Fri, 7 Oct 2016 07:47:00 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-612) > ObserverMethodConfigurator.notifyWith() should probably accept a > functional interface whose method throws java.lang.Exception > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ https://issues.jboss.org/browse/CDI-612?page=com. > atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Antoine Sabot-Durand updated CDI-612: > ------------------------------------- > Fix Version/s: 2.0 .Final > (was: 2.0 (discussion)) > > > > ObserverMethodConfigurator.notifyWith() should probably accept a > functional interface whose method throws java.lang.Exception > > ------------------------------------------------------------ > ----------------------------------------------------------------- > > > > Key: CDI-612 > > URL: https://issues.jboss.org/browse/CDI-612 > > Project: CDI Specification Issues > > Issue Type: Clarification > > Affects Versions: 2.0-EDR1 > > Reporter: Martin Kouba > > Fix For: 2.0 .Final > > > > > > The regular observer methods may also throw checked exceptions (wrapped > and rethrown as an (unchecked) {{ObserverException}}). > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 7 > Date: Fri, 7 Oct 2016 07:52:01 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle > event fired before container destroys all contexts > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ https://issues.jboss.org/browse/CDI-601?page=com. > atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Antoine Sabot-Durand resolved CDI-601. > -------------------------------------- > Resolution: Duplicate Issue > > > Duplicates CDI-625 > > > 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) > > > ------------------------------ > > Message: 8 > Date: Fri, 7 Oct 2016 07:54:01 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-593) Mention > javax.enterprise.inject.spi.Prioritized in spec text and improve > its > javadoc > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ https://issues.jboss.org/browse/CDI-593?page=com. > atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Antoine Sabot-Durand updated CDI-593: > ------------------------------------- > Fix Version/s: 2.0 .Final > (was: 2.0 (discussion)) > > > > Mention javax.enterprise.inject.spi.Prioritized in spec text and > improve its javadoc > > ------------------------------------------------------------ > ------------------------ > > > > Key: CDI-593 > > URL: https://issues.jboss.org/browse/CDI-593 > > Project: CDI Specification Issues > > Issue Type: Clarification > > Reporter: Martin Kouba > > Fix For: 2.0 .Final > > > > > > * javadoc would definitely deserve some more info > > * the spec text should mention this interface as well and describe basic > use cases (e.g. an interceptor passed to {{AfterBeanDiscovery.addBean()}} > and implementing this interface is globally enabled) > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 9 > Date: Fri, 7 Oct 2016 07:55:00 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-592) Consider adding > ObserverMethod.notify() method which also accepts EventMetadata > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ https://issues.jboss.org/browse/CDI-592?page=com. > atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Antoine Sabot-Durand updated CDI-592: > ------------------------------------- > Fix Version/s: 2.0 .Final > (was: 2.0 (discussion)) > > > > Consider adding ObserverMethod.notify() method which also accepts > EventMetadata > > ------------------------------------------------------------ > ------------------- > > > > Key: CDI-592 > > URL: https://issues.jboss.org/browse/CDI-592 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Components: Events > > Reporter: Martin Kouba > > Fix For: 2.0 .Final > > > > > > {code:java} > > // Make the original method also default so that new impls don't need to > implement two methods > > default void notify(T event) { > > // No-op > > } > > // The container should always call this method... > > default void notify(T event, EventMetadata metadata) { > > notify(event); > > } > > {code} > > This should not break existing implementations. The truth is a custom > impl will not be forced to implement any {{notify()}} method. But I think > the benefits are worth it. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 10 > Date: Fri, 7 Oct 2016 07:59:00 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-561) Add the possibility to > unmanage a bean instance > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ https://issues.jboss.org/browse/CDI-561?page=com. > atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Antoine Sabot-Durand updated CDI-561: > ------------------------------------- > Fix Version/s: TBD > (was: 2.0 (discussion)) > > > > Add the possibility to unmanage a bean instance > > ----------------------------------------------- > > > > Key: CDI-561 > > URL: https://issues.jboss.org/browse/CDI-561 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Components: Beans > > Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1 > > Reporter: Antoine Sabot-Durand > > Fix For: TBD > > > > > > CDI implementations make heavy uses of proxies to support normal scope > and interceptor decorators. There are use case where being able to have a > bean instance without its proxy could be useful > > * Accessing the true class of the instance in a clean way > > * Being able to capture an instance state to use its information outside > CDI or as an event payload > > The limitation we have on Async event is probably a good example. As we > don't propagate active normal context at firing time, it's not possible to > inject a bean with such a scope (except {{@ApplicationScoped}} since > Application context is shared), it could be useful to give the possibility > to copy such a bean instance to a standard pojo instance so it could be > used as event payload for instance. > > We could even imagine that the mechanism could be transparently > activated if an asynchronous observer inject a {{@RequestScoped}} or > {{@SessionScoped}} bean. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > _______________________________________________ > 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 71, Issue 8 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161007/726c5761/attachment-0001.html From mkouba at redhat.com Fri Oct 7 08:48:38 2016 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 7 Oct 2016 14:48:38 +0200 Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Intoroduce BeanManager.event() In-Reply-To: References: Message-ID: I'm fine with BeanManager.getEvent(). Martin Dne 7.10.2016 v 14:39 Werner Keil napsal(a): > The confusion between the existing BeanManager.fireEvent() > (JIRA comments sometimes just call it "fire") and this newly proposed > method should be avoided. > Backward-compatibility means the existing ones should still work as they > do of course. > > What's the rationale behind just wanting to call it "event". It would > return an Event object. All but the void methods (including fireEvent) > follow certain conventions like > - get* > - create* > - is* > - are* > depending on what they return. > > Why would a non-void non-static method of an existing interface that > returns something suddenly break with these conventions? If the existing > fireEvent method did not exist, it may be less problematic, though other > than the static accessor method current() in the CDI class, I am not > aware of interfaces doing that so far. > > However having fireEvent in the same interface, just calling a "getter" > method event() makes that even more ambiguous and easy to misinterpret. > > Werner > > > > On Fri, Oct 7, 2016 at 1:59 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. [JBoss JIRA] (CDI-224) Support Decoration of no interface > beans (Antoine Sabot-Durand (JIRA)) > 2. [JBoss JIRA] (CDI-526) Include filters > (Antoine Sabot-Durand (JIRA)) > 3. [JBoss JIRA] (CDI-613) Container should be able to receive > information about the context in which it was bootstraped > (Antoine Sabot-Durand (JIRA)) > 4. [JBoss JIRA] (CDI-633) Intoroduce BeanManager.event() > (Antoine Sabot-Durand (JIRA)) > 5. [JBoss JIRA] (CDI-613) Container should be able to receive > information about the context in which it was bootstraped > (Antoine Sabot-Durand (JIRA)) > 6. [JBoss JIRA] (CDI-612) > ObserverMethodConfigurator.notifyWith() should probably accept a > functional interface whose method throws java.lang.Exception > (Antoine Sabot-Durand (JIRA)) > 7. [JBoss JIRA] (CDI-601) Add container lifecycle event fired > before container destroys all contexts (Antoine Sabot-Durand > (JIRA)) > 8. [JBoss JIRA] (CDI-593) Mention > javax.enterprise.inject.spi.Prioritized in spec text and improve > its javadoc (Antoine Sabot-Durand (JIRA)) > 9. [JBoss JIRA] (CDI-592) Consider adding > ObserverMethod.notify() method which also accepts EventMetadata > (Antoine Sabot-Durand (JIRA)) > 10. [JBoss JIRA] (CDI-561) Add the possibility to unmanage a bean > instance (Antoine Sabot-Durand (JIRA)) > > > ---------------------------------------------------------------------- > > Message: 4 > Date: Fri, 7 Oct 2016 07:33:00 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > > Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Intoroduce > BeanManager.event() > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > > ] > > Antoine Sabot-Durand updated CDI-633: > ------------------------------------- > Fix Version/s: 2.0 .Final > (was: 2.0 (discussion)) > > > > Intoroduce BeanManager.event() > > ------------------------------ > > > > Key: CDI-633 > > URL: https://issues.jboss.org/browse/CDI-633 > > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Reporter: Martin Kouba > > Fix For: 2.0 .Final > > > > > > * this would allow to define the _specified type_ - the container > may use the specified type to infer the parameterized type of the > event types > > * the method should return > {{javax.enterprise.event.Event}} with no qualifiers > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 5 > Date: Fri, 7 Oct 2016 07:47:00 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > > Subject: [cdi-dev] [JBoss JIRA] (CDI-613) Container should be able to > receive information about the context in which it was > bootstraped > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > > ] > > Antoine Sabot-Durand updated CDI-613: > ------------------------------------- > Fix Version/s: TBD > (was: 2.0 (discussion)) > > > > Container should be able to receive information about the context > in which it was bootstraped > > > --------------------------------------------------------------------------------------------- > > > > Key: CDI-613 > > URL: https://issues.jboss.org/browse/CDI-613 > > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Components: Java EE integration > > Reporter: Antoine Sabot-Durand > > Fix For: TBD > > > > > > Today it's impossible to know what is the outside context of the > CDI container (i.e what is the application or EE module it belongs to). > > This is problematic for other spec like JPA who needs to retrieve > their information (persistence units) from a portable extension. > > This would help solving issues like WFLY-2387 in a portable way. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 6 > Date: Fri, 7 Oct 2016 07:47:00 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > > Subject: [cdi-dev] [JBoss JIRA] (CDI-612) > ObserverMethodConfigurator.notifyWith() should probably accept a > functional interface whose method throws java.lang.Exception > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > > ] > > Antoine Sabot-Durand updated CDI-612: > ------------------------------------- > Fix Version/s: 2.0 .Final > (was: 2.0 (discussion)) > > > > ObserverMethodConfigurator.notifyWith() should probably accept a > functional interface whose method throws java.lang.Exception > > > ----------------------------------------------------------------------------------------------------------------------------- > > > > Key: CDI-612 > > URL: https://issues.jboss.org/browse/CDI-612 > > > Project: CDI Specification Issues > > Issue Type: Clarification > > Affects Versions: 2.0-EDR1 > > Reporter: Martin Kouba > > Fix For: 2.0 .Final > > > > > > The regular observer methods may also throw checked exceptions > (wrapped and rethrown as an (unchecked) {{ObserverException}}). > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 7 > Date: Fri, 7 Oct 2016 07:52:01 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > > Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle > event fired before container destroys all contexts > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > > ] > > Antoine Sabot-Durand resolved CDI-601. > -------------------------------------- > Resolution: Duplicate Issue > > > Duplicates CDI-625 > > > 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) > > > ------------------------------ > > Message: 8 > Date: Fri, 7 Oct 2016 07:54:01 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > > Subject: [cdi-dev] [JBoss JIRA] (CDI-593) Mention > javax.enterprise.inject.spi.Prioritized in spec text and > improve its > javadoc > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > > ] > > Antoine Sabot-Durand updated CDI-593: > ------------------------------------- > Fix Version/s: 2.0 .Final > (was: 2.0 (discussion)) > > > > Mention javax.enterprise.inject.spi.Prioritized in spec text and > improve its javadoc > > > ------------------------------------------------------------------------------------ > > > > Key: CDI-593 > > URL: https://issues.jboss.org/browse/CDI-593 > > > Project: CDI Specification Issues > > Issue Type: Clarification > > Reporter: Martin Kouba > > Fix For: 2.0 .Final > > > > > > * javadoc would definitely deserve some more info > > * the spec text should mention this interface as well and describe > basic use cases (e.g. an interceptor passed to > {{AfterBeanDiscovery.addBean()}} and implementing this interface is > globally enabled) > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 9 > Date: Fri, 7 Oct 2016 07:55:00 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > > Subject: [cdi-dev] [JBoss JIRA] (CDI-592) Consider adding > ObserverMethod.notify() method which also accepts EventMetadata > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > > ] > > Antoine Sabot-Durand updated CDI-592: > ------------------------------------- > Fix Version/s: 2.0 .Final > (was: 2.0 (discussion)) > > > > Consider adding ObserverMethod.notify() method which also accepts > EventMetadata > > > ------------------------------------------------------------------------------- > > > > Key: CDI-592 > > URL: https://issues.jboss.org/browse/CDI-592 > > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Components: Events > > Reporter: Martin Kouba > > Fix For: 2.0 .Final > > > > > > {code:java} > > // Make the original method also default so that new impls don't > need to implement two methods > > default void notify(T event) { > > // No-op > > } > > // The container should always call this method... > > default void notify(T event, EventMetadata metadata) { > > notify(event); > > } > > {code} > > This should not break existing implementations. The truth is a > custom impl will not be forced to implement any {{notify()}} method. > But I think the benefits are worth it. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 10 > Date: Fri, 7 Oct 2016 07:59:00 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > > Subject: [cdi-dev] [JBoss JIRA] (CDI-561) Add the possibility to > unmanage a bean instance > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > > ] > > Antoine Sabot-Durand updated CDI-561: > ------------------------------------- > Fix Version/s: TBD > (was: 2.0 (discussion)) > > > > Add the possibility to unmanage a bean instance > > ----------------------------------------------- > > > > Key: CDI-561 > > URL: https://issues.jboss.org/browse/CDI-561 > > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Components: Beans > > Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1 > > Reporter: Antoine Sabot-Durand > > Fix For: TBD > > > > > > CDI implementations make heavy uses of proxies to support normal > scope and interceptor decorators. There are use case where being > able to have a bean instance without its proxy could be useful > > * Accessing the true class of the instance in a clean way > > * Being able to capture an instance state to use its information > outside CDI or as an event payload > > The limitation we have on Async event is probably a good example. > As we don't propagate active normal context at firing time, it's not > possible to inject a bean with such a scope (except > {{@ApplicationScoped}} since Application context is shared), it > could be useful to give the possibility to copy such a bean instance > to a standard pojo instance so it could be used as event payload for > instance. > > We could even imagine that the mechanism could be transparently > activated if an asynchronous observer inject a {{@RequestScoped}} or > {{@SessionScoped}} bean. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > _______________________________________________ > 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 71, Issue 8 > ************************************** > > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From issues at jboss.org Fri Oct 7 09:37:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 09:37:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-518) Clarify boundaries of the ServletContext event In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-518: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Clarify boundaries of the ServletContext event > ---------------------------------------------- > > Key: CDI-518 > URL: https://issues.jboss.org/browse/CDI-518 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: TBD > > > {quote} > An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application > context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired > when the application is destroyed. The event payload is: > ? the ServletContext if the application is a web application deployed to a Servlet container, or Conversation context lifecycle > ? any java.lang.Object for other types of application. > {quote} > Unlike dependency injection, the spec does not define any visibility boundaries for events. It could therefore be implied that in an EAR a web application could observe the ServletContext event for a different web application. This obviously does not seem right and the spec should explicitly define the expected behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 09:58:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 09:58:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-516) Firing events with dynamic parameterized types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-516. ------------------------------------ Release Notes Text: Should be resolved with CDI-633 Resolution: Duplicate Issue > Firing events with dynamic parameterized types > ---------------------------------------------- > > Key: CDI-516 > URL: https://issues.jboss.org/browse/CDI-516 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.2.Final > Reporter: Antonin Stefanutti > Fix For: 2.0 (discussion) > > > For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]: > {quote} > If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types. > If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown. > {quote} > Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]: > {quote} > If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown. > {quote} > While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.: > {code} > @Inject > Event event; > event.select(new TypeLiteral() {}); > {code} > It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}. > Yet, there are use cases where that need is valid, for example: > {code} > CdiEventEndpoint cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event event) throws Exception { > // Represents the runtime type for T > Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0]; > String uri = endpointUri(type, ip.getQualifiers()); > if (context.hasEndpoint(uri) == null) { > // Work around to pass the dynamic type > TypeLiteral literal = new TypeLiteral() {}; > for (Field field : TypeLiteral.class.getDeclaredFields()) { > if (field.getType().equals(Type.class)) { > field.setAccessible(true); > field.set(literal, type); > break; > } > } > // Here we used the dynamic type > Event typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()])); > context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context)); > } > return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class); > } > {code} > In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument. > Another alternative would be to enrich the {{BeanManager}} SPI with the following method: > {code} > public void fireEvent(Object event, Type type, Annotation... qualifiers); > {code} > That use case is taken from the [CDI event Camel endpoint|https://github.com/astefanutti/camel-cdi/blob/84426570bcd7815eb98f87b07739aa9ddfc44191/impl/src/main/java/org/apache/camel/cdi/CdiCamelFactory.java#L91] in the [Camel CDI extension|https://github.com/astefanutti/camel-cdi]. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 10:02:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 10:02:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-500) Clarify @Intercepted Bean metadata injection for EE components In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-500: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Clarify @Intercepted Bean metadata injection for EE components > -------------------------------------------------------------- > > Key: CDI-500 > URL: https://issues.jboss.org/browse/CDI-500 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > It's not clear what should happen when an interceptor with {{@Intercepted Bean}} metadata is associated with an EE component. > See the CDI spec, "5.5.8. Bean metadata": > {quote} > Additionally, the container must provide beans allowing interceptors and decorators to obtain information about the beans they intercept and decorate: > * a bean with scope @Dependent, qualifier @Intercepted and type Bean which can be injected into any interceptor instance, and > * ... > {quote} > However, most EE components must also support the use of CDI interceptors. See also the Java EE 7 spec, "EE.5.2.5 Annotations and Injection": > {quote} > The component classes listed in Table EE.5-1 with support level "Standard" > all support Java EE resource injection, as well as PostConstruct and PreDestroy callbacks. In addition, if CDI is enabled?which it is by default?these classes also support CDI injection, as described in Section EE.5.24, "Support for Dependency Injection", and the use of interceptors. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 10:26:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 10:26:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-498) Revise "6.7.5. The Conversation interface" - dots are not valid in EL name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-498: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Revise "6.7.5. The Conversation interface" - dots are not valid in EL name > -------------------------------------------------------------------------- > > Key: CDI-498 > URL: https://issues.jboss.org/browse/CDI-498 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Tomas Remes > Fix For: 2.0 .Final > > > Seems that following part contradicts the EL spec: > {quote}The container provides a built-in bean with bean type Conversation , scope @RequestScoped , > and qualifier @Default , named javax.enterprise.context.conversation .{quote} > The EL name "javax.enterprise.context.conversation" is not valid. > Discussion available at http://transcripts.jboss.org/channel/irc.freenode.org/%23cdi-dev/2015/%23cdi-dev.2015-01-06.log.html > and > http://lists.jboss.org/pipermail/cdi-dev/2015-January/thread.html - topic "where is defined javax.enterprise.context.conversation.id?" -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 10:30:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 10:30:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-497) session scope doesn't follow session lifecycle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-497: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > session scope doesn't follow session lifecycle > ---------------------------------------------- > > Key: CDI-497 > URL: https://issues.jboss.org/browse/CDI-497 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > Fix For: 2.0 .Final > > > ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case). > Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 7 11:04:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Oct 2016 11:04:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-496) Clarification (or completion) for interceptor binding to session bean In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-496: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Clarification (or completion) for interceptor binding to session bean > --------------------------------------------------------------------- > > Key: CDI-496 > URL: https://issues.jboss.org/browse/CDI-496 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.2.Final > Reporter: Tomas Remes > Fix For: TBD > > > It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement: > {quote}Managed beans and EJB session and message-driven beans support interception.{quote} > But at the end of "9.3. Binding an interceptor to a bean" There is only: > {quote} > If a managed bean has a class-level or method-level interceptor binding, the managed bean must > be a proxyable bean type, as defined in Section 3.15, ?Unproxyable bean types?. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 04:30:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 04:30:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-495) What happens if an illegal bean type is found in the set of bean types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304614#comment-13304614 ] Antoine Sabot-Durand commented on CDI-495: ------------------------------------------ +1 to add a mention of ignoring the type > What happens if an illegal bean type is found in the set of bean types > ---------------------------------------------------------------------- > > Key: CDI-495 > URL: https://issues.jboss.org/browse/CDI-495 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 04:31:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 04:31:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-495) What happens if an illegal bean type is found in the set of bean types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-495: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > What happens if an illegal bean type is found in the set of bean types > ---------------------------------------------------------------------- > > Key: CDI-495 > URL: https://issues.jboss.org/browse/CDI-495 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 04:33:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 04:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-493) Allow firing of parameterized event types from BeanManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-493. -------------------------------------- Release Notes Text: Solved by CDI-633 Resolution: Duplicate Issue > Allow firing of parameterized event types from BeanManager > ---------------------------------------------------------- > > Key: CDI-493 > URL: https://issues.jboss.org/browse/CDI-493 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.2.Final > Reporter: Sven Linstaedt > Fix For: 2.0 (discussion) > > > Currently we are allowed firing generic events from {{javax.enterprise.event.Event#fire}} as long as it's type parameter X does not contain a TypeVariable. > When it comes to {{javax.enterprise.inject.spi.BeanManager#fireEvent}} and {{javax.enterprise.inject.spi.BeanManager#resolveObserverMethods}} this is unfortunately not possible due to type erasure. Because we lack the relevant generic information that are otherwise explicit stated via {{Event#select}}, we are not able to fire a generic event from {{BeanManager#fireEvent}}. > This proposal is about enhancing the API of BeanManager in order to supply the relevant type information, that are otherwise discarded by type erasure. A possible solution would look like adding two new methods to BeanManager > {code} > BeanManager#fireEvent(Type, Object, Annotation...) > BeanManager#resolveObserverMethods(Type, T, Annotation...) > {code} > which receive the selected event type as 1st parameter, validate that the actual event instance (2nd parameter) is assignable to the selected event type (the selected event type has to resolve all type variables; throwing an IllegalArgumentException otherwise) and fires the event afterwards. > The original two methods can delegate their calls to the new ones, having {{java.lang.Object}} as event type. > Additionally {{javax.enterprise.inject.spi.EventMetadata#getType()}} will return the resolved parameterized type. > With this proposal it would be possible to provide meta-extensions, that enable other extension to handle custom extension lifecycle events like > {code} > void on(@Observes @BoundWith(InterceptorBinding.class) ProcessBoundedType pbt) { > if (pbt.getBoundedType().isAnnotationPresent(Interceptor.class)) { > // register interceptor type > } else { > // register intercepted type > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 04:33:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 04:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-492) Give ownership of servlet specific part to servlet specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-492: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Give ownership of servlet specific part to servlet specification > ---------------------------------------------------------------- > > Key: CDI-492 > URL: https://issues.jboss.org/browse/CDI-492 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: Antoine Sabot-Durand > Fix For: TBD > > > [Section 3.8 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans] places some requirements on CDI implementations when running with Servlet. To better suit user desires for modularity these requirements are better met by moving them to the Servlet spec. Specifically, > {quote} > A servlet container must provide the following built-in beans, all of which have qualifier @Default: > * a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the HttpServletRequest > * a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the HttpSession, > * a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the ServletContext, > These beans are passivation capable dependencies, as defined in Passivation capable dependencies. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 04:46:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 04:46:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-492) Give ownership of servlet specific part to servlet specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-492: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: TBD) > Give ownership of servlet specific part to servlet specification > ---------------------------------------------------------------- > > Key: CDI-492 > URL: https://issues.jboss.org/browse/CDI-492 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: Antoine Sabot-Durand > Fix For: 2.1 (Discussion) > > > [Section 3.8 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans] places some requirements on CDI implementations when running with Servlet. To better suit user desires for modularity these requirements are better met by moving them to the Servlet spec. Specifically, > {quote} > A servlet container must provide the following built-in beans, all of which have qualifier @Default: > * a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the HttpServletRequest > * a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the HttpSession, > * a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the ServletContext, > These beans are passivation capable dependencies, as defined in Passivation capable dependencies. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 04:50:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 04:50:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-492) Give ownership of servlet specific part to servlet specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304615#comment-13304615 ] Antoine Sabot-Durand commented on CDI-492: ------------------------------------------ Had a discussion with [~edburns] at Java One. We agreed on re-discussing this topic for servlet next iteration and probably CDI 2.1. > Give ownership of servlet specific part to servlet specification > ---------------------------------------------------------------- > > Key: CDI-492 > URL: https://issues.jboss.org/browse/CDI-492 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: Antoine Sabot-Durand > Fix For: 2.1 (Discussion) > > > [Section 3.8 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans] places some requirements on CDI implementations when running with Servlet. To better suit user desires for modularity these requirements are better met by moving them to the Servlet spec. Specifically, > {quote} > A servlet container must provide the following built-in beans, all of which have qualifier @Default: > * a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the HttpServletRequest > * a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the HttpSession, > * a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the ServletContext, > These beans are passivation capable dependencies, as defined in Passivation capable dependencies. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 05:01:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 05:01:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-488) InjectionPoint SPI should expose whether an injection point is @TransientReference In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-488: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > InjectionPoint SPI should expose whether an injection point is @TransientReference > ---------------------------------------------------------------------------------- > > Key: CDI-488 > URL: https://issues.jboss.org/browse/CDI-488 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Jozef Hartinger > Fix For: TBD > > > Similarly to InjectionPoint.isDelegate(), the SPI should expose whether an injection points requires a @TransientReference or not. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 05:11:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 05:11:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-486) Define security constraints for using CDI SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304616#comment-13304616 ] Antoine Sabot-Durand commented on CDI-486: ------------------------------------------ We really need to consult a security expert on this point. > Define security constraints for using CDI SPI > --------------------------------------------- > > Key: CDI-486 > URL: https://issues.jboss.org/browse/CDI-486 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Priority: Critical > Fix For: 2.0 .Final > > > Currently, the specification does not require any security checks to be performed when CDI SPI is used. It is not clear how this should be implemented. > Note that since a CDI implementation is required to support bypassing platform securiy checks (e.g. when invoking aprivate observer method), total absence of security checks on CDI SPI level could result in privilege escalation. Here's an example: > Suppose the application server bundles a sensitive method: > {code:JAVA} > public class ApplicationServer { > static boolean explode() { > // ... > } > } > {code} > The method is package-private and thus cannot be by an application. If the application would be to invoke this method using reflection, it would need to first obtain the Method handle for the explode method. Obtaining a Method handle requires the "accessDeclaredMembers" runtime permission which the application does not have. It can however use the CDI SPI: > {code:JAVA} > Method method = null; > for (AnnotatedMethod annotatedMethod : manager.createAnnotatedType(ApplicationServer.class).getMethods()) { > if (annotatedMethod.getJavaMember().equals("explode")) { > method = annotatedMethod.getJavaMember(); > break; > } > } > {code} > Now the application has the Method handle without having the "accessDeclaredMembers" permission. > The application still cannot invoke the method as it needs to bypass security checks on access to the method first. This cannot be done without the "suppressAccessChecks" runtime permission. > Again, remember that CDI implementations are supposed to be capable of invoking inaccessible methods and this capability is exposed through the SPI. Therefore, the application call: > {code:JAVA} > Producer producer = manager.getProducerFactory(annotatedMethod, null).createProducer(null); > {code} > Now, calling producer.produce() will cause the sensitive method to be invoked even though the application was not granted "accessDeclaredMembers" neither "suppressAccessChecks" permission. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 05:11:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 05:11:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-486) Define security constraints for using CDI SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-486: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Define security constraints for using CDI SPI > --------------------------------------------- > > Key: CDI-486 > URL: https://issues.jboss.org/browse/CDI-486 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Priority: Critical > Fix For: 2.0 .Final > > > Currently, the specification does not require any security checks to be performed when CDI SPI is used. It is not clear how this should be implemented. > Note that since a CDI implementation is required to support bypassing platform securiy checks (e.g. when invoking aprivate observer method), total absence of security checks on CDI SPI level could result in privilege escalation. Here's an example: > Suppose the application server bundles a sensitive method: > {code:JAVA} > public class ApplicationServer { > static boolean explode() { > // ... > } > } > {code} > The method is package-private and thus cannot be by an application. If the application would be to invoke this method using reflection, it would need to first obtain the Method handle for the explode method. Obtaining a Method handle requires the "accessDeclaredMembers" runtime permission which the application does not have. It can however use the CDI SPI: > {code:JAVA} > Method method = null; > for (AnnotatedMethod annotatedMethod : manager.createAnnotatedType(ApplicationServer.class).getMethods()) { > if (annotatedMethod.getJavaMember().equals("explode")) { > method = annotatedMethod.getJavaMember(); > break; > } > } > {code} > Now the application has the Method handle without having the "accessDeclaredMembers" permission. > The application still cannot invoke the method as it needs to bypass security checks on access to the method first. This cannot be done without the "suppressAccessChecks" runtime permission. > Again, remember that CDI implementations are supposed to be capable of invoking inaccessible methods and this capability is exposed through the SPI. Therefore, the application call: > {code:JAVA} > Producer producer = manager.getProducerFactory(annotatedMethod, null).createProducer(null); > {code} > Now, calling producer.produce() will cause the sensitive method to be invoked even though the application was not granted "accessDeclaredMembers" neither "suppressAccessChecks" permission. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 05:22:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 05:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-484) Provide forwarding implementations of SPI interfaces In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-484. -------------------------------------- Resolution: Duplicate Issue CDI-558 answers to most use cases link to this ticket > Provide forwarding implementations of SPI interfaces > ---------------------------------------------------- > > Key: CDI-484 > URL: https://issues.jboss.org/browse/CDI-484 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > The decorator design pattern is commonly used in CDI extensions to modify existing metadata by wrapping it with a wrapper implementation that overrides certain method. This can be done in the following callbacks: ProcessAnnotatedType, ProcessProducer, ProcessInjectionTarget, ProcessInjectionPoint and ProcessBeanAttributes. > In order to do this it is often very convenient to have a forwarding implementation available, e.g.: > {code:JAVA} > void wrap(@Observes ProcessAnnotatedType event) { > final AnnotatedType delegate = event.getAnnotatedType(); > event.setAnnotatedType(new ForwardingAnnotatedType(delegate) { > @Override > public A getAnnotation(Class annotationType) { > return null; > } > @Override > public Set getAnnotations() { > return Collections.emptySet(); > } > @Override > public boolean isAnnotationPresent(Class annotationType) { > return false; > } > } > {code} > We should consider providing these utility forwarding implementations as part of the CDI API. This is similar to e.g. Servlet specification doing this for their decorable APIs (http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpServletRequestWrapper.html) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 05:25:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 05:25:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-482) Overloaded version of ObserverMethod.notify() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-482. -------------------------------------- Resolution: Duplicate Issue > Overloaded version of ObserverMethod.notify() > --------------------------------------------- > > Key: CDI-482 > URL: https://issues.jboss.org/browse/CDI-482 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > Resurrecting the old proposal (CDI-36) that was rejected due to backward compatibility (CDI-281). In the meantime, alternative approach of obtaining event qualifiers (doing a programmatic lookup for EventMetadata) became available. > Now that default methods are available in Java, we should consider making EventMetadata easier to use by making it part of the SPI directly: > {code:JAVA} > ObserverMethod.notify(T event, EventMetadata metadata) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 05:31:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 05:31:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-477) Update outdated package-info.java in javax.enterprise.inject package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-477: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Update outdated package-info.java in javax.enterprise.inject package > -------------------------------------------------------------------- > > Key: CDI-477 > URL: https://issues.jboss.org/browse/CDI-477 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > Update or remove this javadoc. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 11:54:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 11:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-478) Interceptor and Decorator EPIC for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-478: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Interceptor and Decorator EPIC for CDI 2.0 > ------------------------------------------ > > Key: CDI-478 > URL: https://issues.jboss.org/browse/CDI-478 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > This Epic ticket gathers all work and documents about interceptor and decorator in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/10iexiDfMT9tYaUPa2cGiw4P68VG_bryDIS0DKzP1ils/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 11:58:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 11:58:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-473: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Standardize eager initialisation of ApplicationScoped bean > ---------------------------------------------------------- > > Key: CDI-473 > URL: https://issues.jboss.org/browse/CDI-473 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Antonin Stefanutti > Fix For: 2.0 .Final > > > Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called. > While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.: > {code} > void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) { > for (AnnotatedType type : eagerBeans) > // Calling toString is necessary to force the initialization of normal-scoped beans > BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString(); > } > {code} > There should be a concise way to declare that intent which would then be address by the CDI container, for example: > {code} > @ApplicationScoped(eager = true} > class EagerApplicationScopedBean { > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 21:16:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 21:16:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-468) Extend javax.interceptor.InvocationContext In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-468: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: 2.0 (discussion)) > Extend javax.interceptor.InvocationContext > ------------------------------------------ > > Key: CDI-468 > URL: https://issues.jboss.org/browse/CDI-468 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Arne Limburg > Fix For: 2.1 (Discussion) > > > Currently there is no easy way to obtain the interceptor binding annotation for an interceptor call. The interceptor binding annotation is needed to access @Nonbinding attributes and behave accordingly. > I propose to extend the javax.interceptor.InvocationContext interface with a method > public Annotation getInterceptorBinding() or > public A getInterceptorBinding(Class type) > The @AroundInvoke method of CDI Interceptors may use this extended interface as parameter instead of the original one to obtain the interceptor binding annotation. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 21:32:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 21:32:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-259) Add conversation begin and conversation end events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-259: ------------------------------------- Priority: Optional (was: Major) > Add conversation begin and conversation end events > -------------------------------------------------- > > Key: CDI-259 > URL: https://issues.jboss.org/browse/CDI-259 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Priority: Optional > Fix For: TBD > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 21:32:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 21:32:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-259) Add conversation begin and conversation end events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-259: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Add conversation begin and conversation end events > -------------------------------------------------- > > Key: CDI-259 > URL: https://issues.jboss.org/browse/CDI-259 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Priority: Optional > Fix For: TBD > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 21:34:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 21:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-463) Events Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-463. -------------------------------------- Release Notes Text: All features done Resolution: Done > Events Epic for CDI 2.0 > ----------------------- > > Key: CDI-463 > URL: https://issues.jboss.org/browse/CDI-463 > Project: CDI Specification Issues > Issue Type: Epic > Components: Events > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > This Epic ticket gathers all work and documents about possible events enhancement in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/1lFtgLm6hY-uECdA1r0Sfimq6vkVYThoUZsevPUaSP0E/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 21:35:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 21:35:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-462) Parts Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-462: ------------------------------------- Fix Version/s: (was: 2.0 (discussion)) > Parts Epic for CDI 2.0 > ---------------------- > > Key: CDI-462 > URL: https://issues.jboss.org/browse/CDI-462 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > > this Epic ticket gathers all tickets and work documents about the introudction of parts (modularity) in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/1AEBjQl00CZ9ERfgXSHq9cdxrngwsERjUCEmcdzgMSZ4/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 21:35:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 21:35:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-463) Events Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-463: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Events Epic for CDI 2.0 > ----------------------- > > Key: CDI-463 > URL: https://issues.jboss.org/browse/CDI-463 > Project: CDI Specification Issues > Issue Type: Epic > Components: Events > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > This Epic ticket gathers all work and documents about possible events enhancement in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/1lFtgLm6hY-uECdA1r0Sfimq6vkVYThoUZsevPUaSP0E/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 21:37:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 21:37:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-462) Parts Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-462. -------------------------------------- Resolution: Rejected No parts in CDI 2.0 > Parts Epic for CDI 2.0 > ---------------------- > > Key: CDI-462 > URL: https://issues.jboss.org/browse/CDI-462 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > > this Epic ticket gathers all tickets and work documents about the introudction of parts (modularity) in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/1AEBjQl00CZ9ERfgXSHq9cdxrngwsERjUCEmcdzgMSZ4/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 21:38:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 21:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-462) Parts Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-462: ------------------------------------- Fix Version/s: 2.0 (discussion) > Parts Epic for CDI 2.0 > ---------------------- > > Key: CDI-462 > URL: https://issues.jboss.org/browse/CDI-462 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > this Epic ticket gathers all tickets and work documents about the introudction of parts (modularity) in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/1AEBjQl00CZ9ERfgXSHq9cdxrngwsERjUCEmcdzgMSZ4/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 21:38:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 21:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-462) Parts Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-462. ------------------------------------ > Parts Epic for CDI 2.0 > ---------------------- > > Key: CDI-462 > URL: https://issues.jboss.org/browse/CDI-462 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > this Epic ticket gathers all tickets and work documents about the introudction of parts (modularity) in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/1AEBjQl00CZ9ERfgXSHq9cdxrngwsERjUCEmcdzgMSZ4/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 21:39:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 21:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-461) Configuration Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-461. ------------------------------------ Resolution: Done No configuration feature in CDI 2.0 > Configuration Epic for CDI 2.0 > ------------------------------ > > Key: CDI-461 > URL: https://issues.jboss.org/browse/CDI-461 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > This Epic ticket gathers all tickets and work document about studying the possible introduction of configuration feature in CDI 2.0. > Draft document is here : https://docs.google.com/document/d/1378aTRNgCMXRYP9LBYRuGdan0mmQ3rPjjIYLWv2AB9I/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 21:45:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 21:45:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-456: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: 2.0 (discussion)) > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > Fix For: 2.1 (Discussion) > > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 21:45:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 21:45:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-456: ------------------------------------- Priority: Minor (was: Major) > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > Priority: Minor > Fix For: 2.1 (Discussion) > > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 21:48:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 21:48:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-449) beans.xml examples are not valid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-449: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > beans.xml examples are not valid > -------------------------------- > > Key: CDI-449 > URL: https://issues.jboss.org/browse/CDI-449 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > The {{beans.xml}} examples in "5.1.1. Declaring selected alternatives", "8.2.2. Decorator enablement and ordering for a bean archive" and "9.4. Interceptor enablement and ordering" (which contain a reference to beans_1_1.xsd) are not valid - {{bean-discovery-mode}} attribute is required. I think it would be appropriate to specify the version attribute as well. > The last {{beans.xml}} example in "12.4.2. Exclude filters" does not even define the reference to an XSD. Again, I believe the version and bean-discovery-mode attributes should be specified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:04:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:04:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-437) The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-437: ------------------------------------- Fix Version/s: 2.1 (was: 2.0 (discussion)) > The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly > ----------------------------------------------------------------------------------------- > > Key: CDI-437 > URL: https://issues.jboss.org/browse/CDI-437 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Priority: Minor > Labels: F2F2016 > Fix For: 2.1 (Discussion) > > > {quote} > Any observer of this event is permitted to add classes to, or remove classes from, the list of alternatives, list of interceptors or list of decorators. *The container must use the final values of these collections*, after all observers of AfterTypeDiscovery have been called, to determine the order of the enabled alternatives, interceptors, and decorators for application. The initial values of these collections are defined by the @Priority annotation. > {quote} > However, the container cannot use the final value of the alternatives collection properly. The problem occurs if an extension adds an alternative class. > The container can either: > * use the index from the list -> selected alternatives with the same priority will not cause {{AmbiguousResolutionException}} (this contradicts the spec), or > * use the original priority, an alternative added by an extension will be selected for an application but without any priority value (this contradicts the spec) -> an extension would not be able to affect the final ordering > The first option seems to be less harmful. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:04:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:04:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-437) The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-437: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: 2.1) > The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly > ----------------------------------------------------------------------------------------- > > Key: CDI-437 > URL: https://issues.jboss.org/browse/CDI-437 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Priority: Minor > Labels: F2F2016 > Fix For: 2.1 (Discussion) > > > {quote} > Any observer of this event is permitted to add classes to, or remove classes from, the list of alternatives, list of interceptors or list of decorators. *The container must use the final values of these collections*, after all observers of AfterTypeDiscovery have been called, to determine the order of the enabled alternatives, interceptors, and decorators for application. The initial values of these collections are defined by the @Priority annotation. > {quote} > However, the container cannot use the final value of the alternatives collection properly. The problem occurs if an extension adds an alternative class. > The container can either: > * use the index from the list -> selected alternatives with the same priority will not cause {{AmbiguousResolutionException}} (this contradicts the spec), or > * use the original priority, an alternative added by an extension will be selected for an application but without any priority value (this contradicts the spec) -> an extension would not be able to affect the final ordering > The first option seems to be less harmful. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:06:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:06:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-415) Observer resolution doesn't specify handling of null parameter values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-415: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: 2.0 (discussion)) > Observer resolution doesn't specify handling of null parameter values > --------------------------------------------------------------------- > > Key: CDI-415 > URL: https://issues.jboss.org/browse/CDI-415 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Michael Kotten > Priority: Minor > Labels: F2F2016 > Fix For: 2.1 (Discussion) > > > There is a gap in chapter 10.2 of the current CDI spec about [observer resolution|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#observer_resolution]. It doesn't specify what should happen if an event gets fired using a null value. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:06:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:06:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-466) Contexts Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-466: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Contexts Epic for CDI 2.0 > ------------------------- > > Key: CDI-466 > URL: https://issues.jboss.org/browse/CDI-466 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > This Epic ticket gathers all work and documents about possible contexts enhancement in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/1tIFNoe9sdyvXT1wTjIeT7ARDaoRZR0IWzcfvKrmdIX4/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:06:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:06:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-467) Java 8 Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-467: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Java 8 Epic for CDI 2.0 > ----------------------- > > Key: CDI-467 > URL: https://issues.jboss.org/browse/CDI-467 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > This Epic ticket gathers all work and documents about possible in CDI 2.0 due to Java SE 8.0 > Draft document is here : https://docs.google.com/document/d/1KUaxXIXJ_r-h5UJGIij6I4vrLS7uXkeeeZr2SaRipWQ/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:07:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:07:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-465) SPI Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-465: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > SPI Epic for CDI 2.0 > -------------------- > > Key: CDI-465 > URL: https://issues.jboss.org/browse/CDI-465 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > This Epic ticket gathers all work and documents about possible SPI enhancement in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/1aK3aIQG-W9D72Ti9fj0xLFNmqxQtYyy_vjc6QgN3Z2Y/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:07:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:07:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-464) Java SE Epic for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-464: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Java SE Epic for CDI 2.0 > ------------------------ > > Key: CDI-464 > URL: https://issues.jboss.org/browse/CDI-464 > Project: CDI Specification Issues > Issue Type: Epic > Components: Java SE Integration > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > This Epic ticket gathers all work and documents about Java SE bootstrap in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:09:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:09:01 -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:all-tabpanel ] Antoine Sabot-Durand updated CDI-414: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: 2.0 (discussion)) > 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.1 (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 Sun Oct 9 22:09:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:09:01 -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:all-tabpanel ] Antoine Sabot-Durand updated CDI-414: ------------------------------------- Priority: Minor (was: Major) > 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 > Priority: Minor > Fix For: 2.1 (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 Sun Oct 9 22:11:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:11:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-403) why decorator requires interface In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-403. -------------------------------------- Resolution: Duplicate Issue Duplicate of CDI-224 > why decorator requires interface > -------------------------------- > > Key: CDI-403 > URL: https://issues.jboss.org/browse/CDI-403 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Mathieu Lachance > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > As discussed with Jozef Hartinger on the WELD forum thread (see forum reference and CDI-224), > would it be possible to revisit why decorator requires an interface ? > I do not understand the semantic difference between: > 1. a decorator to be an abstract class which implements an interface, which delegate to the same interface. > 2. a decorator to be a concrete class which extends a another class, which delegates to the same class. > Why 1. should be allowed and why 2. should be disallowed ? > As stated in CDI-224, if there is no technical reason of disallowing 2., should it be then considerate as a vendor specific feature to support it whether or not ? > It is kind of sad that only decorators requires an interface while all the others Java EE 6 features do not. > Thanks, -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:18:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:18:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-362) No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-362: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting > --------------------------------------------------------------------------------------------- > > Key: CDI-362 > URL: https://issues.jboss.org/browse/CDI-362 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Pete Muir > Priority: Minor > Fix For: TBD > > > E.g. > // allowed by EJB > // disallowed by CDI > @Stateful @RequestScoped > public class MyBean { > final void m() { }; > } > public class Other { > @EJB MyBean field; // PASS > @Inject MyBean field; // FAIL - unproxyable > } -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:18:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:18:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-362) No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-362: ------------------------------------- Priority: Minor (was: Major) > No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting > --------------------------------------------------------------------------------------------- > > Key: CDI-362 > URL: https://issues.jboss.org/browse/CDI-362 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Pete Muir > Priority: Minor > Fix For: TBD > > > E.g. > // allowed by EJB > // disallowed by CDI > @Stateful @RequestScoped > public class MyBean { > final void m() { }; > } > public class Other { > @EJB MyBean field; // PASS > @Inject MyBean field; // FAIL - unproxyable > } -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:20:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:20:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-291) Clarify interceptor/decorator resolution rules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-291: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Clarify interceptor/decorator resolution rules > ---------------------------------------------- > > Key: CDI-291 > URL: https://issues.jboss.org/browse/CDI-291 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators, Interceptors > Affects Versions: 1.0 > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: TBD > > > Currently the spec only says: > {quote} > A decorator is bound to a bean if: > * The bean is assignable to the delegate injection point according to the rules defined in Section 5.2, "Typesafe resolu- > tion" (using Section 8.3.1, "Assignability of raw and parameterized types for delegate injection points"). > * The decorator is enabled in the bean archive containing the bean. > {quote} > AND > {quote} > An interceptor is bound to a method if: > * The method has all the interceptor bindings of the interceptor. A method has an interceptor binding of an interceptor if > it has an interceptor binding with (a) the same type and (b) the same annotation member value for each member which > is not annotated @javax.enterprise.util.Nonbinding. > * The interceptor intercepts the given kind of lifecycle callback or business method. > * The interceptor is enabled in the bean archive containing the bean. > {quote} > What remains unspecified is: > * In a scenario where a module A enables interceptor X in its beans.xml, does X have to be accessible from A. That effectively means that an EJB jar could (or could not) legally use an interceptor/decorator packaged in a web application. > * Even if X is accessible, does it have to be packaged in a bean archive or is it enough for it to be packaged in a library that does not contain beans.xml but is accessible from A? This means that a CDI implementation would need to additionally scan those classes as they would not be scanned by normal bean archive discovery. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:21:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:21:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-280: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > clarify usage of 'bean' term usage in the spec > ---------------------------------------------- > > Key: CDI-280 > URL: https://issues.jboss.org/browse/CDI-280 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Labels: CDI_api_chge, CDI_spec_chge > Fix For: TBD > > > We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for > * The Bean extends Contextual. Should be referred as 'Bean' or 'CDI Bean' > * The class which gets scanned. Should be referred as 'Bean Class' to > * The instance stored in the context. Should be referred to as 'Contextual Instance' > * The proxy for a Contextual Instance should be referred to as 'Contextual Reference' > * The type of an injection point should be referred to as 'InjectionPoint Type' -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:21:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:21:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-280: ------------------------------------- Priority: Minor (was: Major) > clarify usage of 'bean' term usage in the spec > ---------------------------------------------- > > Key: CDI-280 > URL: https://issues.jboss.org/browse/CDI-280 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Priority: Minor > Labels: CDI_api_chge, CDI_spec_chge > Fix For: TBD > > > We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for > * The Bean extends Contextual. Should be referred as 'Bean' or 'CDI Bean' > * The class which gets scanned. Should be referred as 'Bean Class' to > * The instance stored in the context. Should be referred to as 'Contextual Instance' > * The proxy for a Contextual Instance should be referred to as 'Contextual Reference' > * The type of an injection point should be referred to as 'InjectionPoint Type' -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:25:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:25:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-279) Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-279: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-279 > URL: https://issues.jboss.org/browse/CDI-279 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Hong Zhang > Assignee: Pete Muir > Fix For: TBD > > > Please provide CDI SPI that could be used to directly replace the java.lang.reflect methods when expanding the use of @Stereotype to Java EE 7 platform. > Also attaching the relevant sections from Bill's @Stereotype proposal below: > ================================================ > Stereotypes are implemented by CDI, but (typically) the Java EE deployment processing has no knowledge of CDI when it's looking for Java EE annotations. Integrating with CDI so that stereotypes could be considered during this deployment-time annotation processing would require a new CDI SPI. > Many existing implementations would need to be changed to understand > how to expand stereotypes. Requiring every technology to do this > itself will almost certainly lead to inconsistencies. Since stereotypes > are a CDI feature, CDI will provide a simple replacement for the > java.lang.reflect methods such as getAnnotations that takes into > account stereotypes. > Some technologies will not want to have a hard dependency on CDI so > we'll need to provide a simple way for them to conditionally invoke > these new methods only if CDI is present, falling back to java.lang.reflect > if not. This seems straightforward. In this case, the functionality of > @Stereotype would not be available to applications that chose to run > without CDI. > =============================== -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:25:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:25:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-279) Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-279: ------------------------------------- Priority: Minor (was: Major) > Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-279 > URL: https://issues.jboss.org/browse/CDI-279 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Hong Zhang > Assignee: Pete Muir > Priority: Minor > Fix For: TBD > > > Please provide CDI SPI that could be used to directly replace the java.lang.reflect methods when expanding the use of @Stereotype to Java EE 7 platform. > Also attaching the relevant sections from Bill's @Stereotype proposal below: > ================================================ > Stereotypes are implemented by CDI, but (typically) the Java EE deployment processing has no knowledge of CDI when it's looking for Java EE annotations. Integrating with CDI so that stereotypes could be considered during this deployment-time annotation processing would require a new CDI SPI. > Many existing implementations would need to be changed to understand > how to expand stereotypes. Requiring every technology to do this > itself will almost certainly lead to inconsistencies. Since stereotypes > are a CDI feature, CDI will provide a simple replacement for the > java.lang.reflect methods such as getAnnotations that takes into > account stereotypes. > Some technologies will not want to have a hard dependency on CDI so > we'll need to provide a simple way for them to conditionally invoke > these new methods only if CDI is present, falling back to java.lang.reflect > if not. This seems straightforward. In this case, the functionality of > @Stereotype would not be available to applications that chose to run > without CDI. > =============================== -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:32:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:32:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-270) Allow @WithAnnotations to be applied to other events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-270: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: 2.0 (discussion)) > Allow @WithAnnotations to be applied to other events > ---------------------------------------------------- > > Key: CDI-270 > URL: https://issues.jboss.org/browse/CDI-270 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Labels: with-annotations > Fix For: 2.1 (Discussion) > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:33:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-248) Provide means to observe a group of qualified events ("Qualifier Inheritance"?) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-248: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Provide means to observe a group of qualified events ("Qualifier Inheritance"?) > -------------------------------------------------------------------------------- > > Key: CDI-248 > URL: https://issues.jboss.org/browse/CDI-248 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts, Events > Reporter: Jens Schumann > Fix For: TBD > > > We have been using CDI events for application development quite extensively. For instance we use events to propagate entity lifecycle events (@Created/@Updated/@Deleted Customer customer) or GUI selections (@Selected/@Deselected Customer customer) and implement related business logic in event observers. (e.g. send email for newly created customers, clear cached values on select/deselect/create/update/delete ...). > This works quite well, however we have noticed that especially our JSF Presentation Tier contains lots of observer methods implementing the same behavior for a group of related CDI events. > Example: > {code} > public class XyzBean { > public void onCustomerCreate(@Observes @Created Customer customer) { reset();} > public void onCustomerUpdate(@Observes @Updated Customer customer) { reset();} > public void onCustomerDelete(@Observes @Deleted Customer customer) { reset();} > > } > {code} > Looks ugly, doesn't it? > The above example could be improved if CDI would be able to observe a group of qualified events, e.g. public void onCustomerLifeCycleEvent(@Observes @LifeCycleChange Customer customer) { reset(); } - ignore method and qualifier names for now. > Since Java does not support annotation inheritance grouping could be achieved using "qualified qualifier annotations": > {code} > @Qualifier > public @interface LifeCycleChange > @Qualifier > @LifeCycleChange > public @interface Created > @Qualifier > @LifeCycleChange > public @interface Updated > @Qualifier > @LifeCycleChange > public @interface Deleted > @Qualifier > public @interface SelectionChange > @Qualifier > @SelectionChange > public @interface Selected > @Qualifier > @SelectionChange > public @interface Deselected > {code} > WDYT? Side effects? Problems? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:33:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-248) Provide means to observe a group of qualified events ("Qualifier Inheritance"?) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-248: ------------------------------------- Priority: Minor (was: Major) > Provide means to observe a group of qualified events ("Qualifier Inheritance"?) > -------------------------------------------------------------------------------- > > Key: CDI-248 > URL: https://issues.jboss.org/browse/CDI-248 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts, Events > Reporter: Jens Schumann > Priority: Minor > Fix For: TBD > > > We have been using CDI events for application development quite extensively. For instance we use events to propagate entity lifecycle events (@Created/@Updated/@Deleted Customer customer) or GUI selections (@Selected/@Deselected Customer customer) and implement related business logic in event observers. (e.g. send email for newly created customers, clear cached values on select/deselect/create/update/delete ...). > This works quite well, however we have noticed that especially our JSF Presentation Tier contains lots of observer methods implementing the same behavior for a group of related CDI events. > Example: > {code} > public class XyzBean { > public void onCustomerCreate(@Observes @Created Customer customer) { reset();} > public void onCustomerUpdate(@Observes @Updated Customer customer) { reset();} > public void onCustomerDelete(@Observes @Deleted Customer customer) { reset();} > > } > {code} > Looks ugly, doesn't it? > The above example could be improved if CDI would be able to observe a group of qualified events, e.g. public void onCustomerLifeCycleEvent(@Observes @LifeCycleChange Customer customer) { reset(); } - ignore method and qualifier names for now. > Since Java does not support annotation inheritance grouping could be achieved using "qualified qualifier annotations": > {code} > @Qualifier > public @interface LifeCycleChange > @Qualifier > @LifeCycleChange > public @interface Created > @Qualifier > @LifeCycleChange > public @interface Updated > @Qualifier > @LifeCycleChange > public @interface Deleted > @Qualifier > public @interface SelectionChange > @Qualifier > @SelectionChange > public @interface Selected > @Qualifier > @SelectionChange > public @interface Deselected > {code} > WDYT? Side effects? Problems? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:34:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-234) behavior of arrays without @Nonbinding In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-234: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > behavior of arrays without @Nonbinding > -------------------------------------- > > Key: CDI-234 > URL: https://issues.jboss.org/browse/CDI-234 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 1.0 > Reporter: Romain Manni-Bucau > Assignee: Pete Muir > Priority: Minor > Fix For: TBD > > > The spec says: > "Array-valued or annotation-valued members of a qualifier type should be annotated @Nonbinding in a portable application. > If an array-valued or annotation-valued member of a qualifier type is not annotated @Nonbinding, non-portable behavior > results." > The case of arrays without this annotation should be managed to get a better portability. The equality of arrays is determined through "Arrays" helper (http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/annotation/Annotation.html) so i don't think there is any technical issue to consider arrays as a field. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:37:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:37:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-233) Specify target bean archive for bean added via AfterBeanDiscovery.addBean() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-233: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Specify target bean archive for bean added via AfterBeanDiscovery.addBean() > --------------------------------------------------------------------------- > > Key: CDI-233 > URL: https://issues.jboss.org/browse/CDI-233 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Martin Kouba > Priority: Minor > Labels: F2F2016, visibility > Fix For: TBD > > > This may have impact, provided that alternatives, interceptors or decorators are used. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 9 22:46:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 9 Oct 2016 22:46:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-229) introduce @OverridesAttribute for @StereoType In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-229: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: 2.0 (discussion)) > introduce @OverridesAttribute for @StereoType > --------------------------------------------- > > Key: CDI-229 > URL: https://issues.jboss.org/browse/CDI-229 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.1.EDR > Reporter: Mark Struberg > Fix For: 2.1 (Discussion) > > > We recently had a thread on the DeltaSpike list about using StereoTypes in real world applications: http://markmail.org/thread/ntqwnsyukjvdwspm > ------ > Imagine the following Stereotype for my Services (I spare out the standard > stuff) > @StereoType @Secured @Transactional @ApplicationScoped > public @interface @Service {} > The problem here is that there is no way to 'propagate' any rolesAllowed from > @Service to @Secured, etc. > What I'd like to have is something like ... > public @interface @Service { > String[] rolesAllowed(); > TransactionAttributeType transactionType(); > } > where the rolesAllowed() would get propagated to the @Secured meta-annotation > and transactionType() to the @Transactional > ----------- > Gerhard Petracek now pointed me to a cool feature which is used in JSR-303 BVAL: @OverridesAttribute > http://docs.oracle.com/javaee/6/api/javax/validation/OverridesAttribute.html > We should ping the BVAL EG for the details. There are quite a few little tricks and side effects to consider. > On the implementation side, we could e.g. pick the @StereoType annotation and automatically propagate those values to the AnnotatedType which get's passed to the Extensions -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 03:29:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 10 Oct 2016 03:29:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-437) The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304693#comment-13304693 ] Martin Kouba commented on CDI-437: ---------------------------------- For the record, Weld 3 currently tries to solve this problem in a way that if {{AfterTypeDiscovery.getAlternatives().add()}} is used a "sythetic" priority is assigned to the "list item". See also {{org.jboss.weld.bootstrap.enablement.EnablementListView.getPriority(Item, Item)}} for details. > The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly > ----------------------------------------------------------------------------------------- > > Key: CDI-437 > URL: https://issues.jboss.org/browse/CDI-437 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Priority: Minor > Labels: F2F2016 > Fix For: 2.1 (Discussion) > > > {quote} > Any observer of this event is permitted to add classes to, or remove classes from, the list of alternatives, list of interceptors or list of decorators. *The container must use the final values of these collections*, after all observers of AfterTypeDiscovery have been called, to determine the order of the enabled alternatives, interceptors, and decorators for application. The initial values of these collections are defined by the @Priority annotation. > {quote} > However, the container cannot use the final value of the alternatives collection properly. The problem occurs if an extension adds an alternative class. > The container can either: > * use the index from the list -> selected alternatives with the same priority will not cause {{AmbiguousResolutionException}} (this contradicts the spec), or > * use the original priority, an alternative added by an extension will be selected for an application but without any priority value (this contradicts the spec) -> an extension would not be able to affect the final ordering > The first option seems to be less harmful. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 03:40:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 03:40:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-226) Clarify the @Singleton behaviour In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304698#comment-13304698 ] Antoine Sabot-Durand commented on CDI-226: ------------------------------------------ During EG F2F 2016 we launch the idea of writing a mention about singleton saying its discourage in EE. This said it can be postponed to 2.1 > Clarify the @Singleton behaviour > -------------------------------- > > Key: CDI-226 > URL: https://issues.jboss.org/browse/CDI-226 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Contexts > Affects Versions: 1.1.EDR > Reporter: Daniel Sachse > Labels: F2F2016, application-scoped, singleton > Fix For: 2.0 (discussion) > > > The specification should make a more clear statement about the Scope and Lifecycle of the @Singleton annotation. > ATM it is e.g. totally unclear, in which environment a Singleton is guaranteed to be a Singleton(JVM, EAR, WAR,... ). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 03:41:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 03:41:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-226) Clarify the @Singleton behaviour In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-226: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: 2.0 (discussion)) > Clarify the @Singleton behaviour > -------------------------------- > > Key: CDI-226 > URL: https://issues.jboss.org/browse/CDI-226 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Contexts > Affects Versions: 1.1.EDR > Reporter: Daniel Sachse > Labels: F2F2016, application-scoped, singleton > Fix For: 2.1 (Discussion) > > > The specification should make a more clear statement about the Scope and Lifecycle of the @Singleton annotation. > ATM it is e.g. totally unclear, in which environment a Singleton is guaranteed to be a Singleton(JVM, EAR, WAR,... ). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 03:46:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 03:46:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-174) Define contexts and context lifecycle for Java SE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-174. -------------------------------------- Resolution: Out of Date Partially defined (@ApplicationScoped is supported). Solution will be ended with CDI-30 approach. > Define contexts and context lifecycle for Java SE > ------------------------------------------------- > > Key: CDI-174 > URL: https://issues.jboss.org/browse/CDI-174 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 2.0 (discussion) > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 03:50:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 03:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-161) Java DSL to define beans to create and deploy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-161. -------------------------------------- Resolution: Out of Date Use case solved by CDI 2.0 configurators. > Java DSL to define beans to create and deploy > --------------------------------------------- > > Key: CDI-161 > URL: https://issues.jboss.org/browse/CDI-161 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 2.0 (discussion) > > > This would be especially useful in Java SE mode -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 04:05:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 04:05:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-473: ------------------------------------- Fix Version/s: TBD (was: 2.0 .Final) > Standardize eager initialisation of ApplicationScoped bean > ---------------------------------------------------------- > > Key: CDI-473 > URL: https://issues.jboss.org/browse/CDI-473 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Antonin Stefanutti > Fix For: TBD > > > Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called. > While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.: > {code} > void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) { > for (AnnotatedType type : eagerBeans) > // Calling toString is necessary to force the initialization of normal-scoped beans > BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString(); > } > {code} > There should be a concise way to declare that intent which would then be address by the CDI container, for example: > {code} > @ApplicationScoped(eager = true} > class EagerApplicationScopedBean { > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 04:06:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 04:06:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-142) Clarify behaviour of specializing beans across bean archive boundaries In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-142: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Clarify behaviour of specializing beans across bean archive boundaries > ---------------------------------------------------------------------- > > Key: CDI-142 > URL: https://issues.jboss.org/browse/CDI-142 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Labels: F2F2016 > Fix For: TBD > > > For instance, if a bean in a war specializes a bean in an ejb jar does the bean in the war become visible to other bean archives that would not normally be able to see it? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 04:08:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 04:08:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-128) Ability to access CDI enhanced metadata from the InvocationContext.getMethod() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-128: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: 2.0 (discussion)) > Ability to access CDI enhanced metadata from the InvocationContext.getMethod() > ------------------------------------------------------------------------------ > > Key: CDI-128 > URL: https://issues.jboss.org/browse/CDI-128 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Interceptors > Affects Versions: 1.0 > Reporter: Richard Hightower > Fix For: 2.1 (Discussion) > > > The issues with InvocationContext is it was designed before CDI as part of EJB 3. In CDI, the meta-data will likely exist in an annotation, but it could exist in an XML file (Candi, and Seam XML Extension for CDI). > For example, I am working on creating a standard interceptor for JCache 107. I can read the annotation from the getMethod of the InvocationContext, but if someone added the interception meta-data in an XML file, then it will not be available to InvocationContext.getMethod().getAnnotation(Cacheable.class). > I propose we have an extension interface that extends InvocationContext called CDIInvocationContext that has a getAnnotated. This way if someone annotates in an XML file, then it is available to implementors for interceptors. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 04:09:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 04:09:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-114: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 04:13:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 04:13:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-110) Provide support for binding an invocation handler to an interface or abstract class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-110: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: 2.0 (discussion)) > Provide support for binding an invocation handler to an interface or abstract class > ----------------------------------------------------------------------------------- > > Key: CDI-110 > URL: https://issues.jboss.org/browse/CDI-110 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Inheritance and Specialization > Affects Versions: 1.0 > Reporter: George Gastaldi > Labels: cdi > Fix For: 2.1 (Discussion) > > > The purpose of this feature is to allow interfaces and abstract classes to be automatically implemented by an invocation handler to which all abstract method invocations are delegated. The invocation handler would get "bound" to the type using the same strategy as is used for interceptor binding. > Binding type: > {code:java} > @Target({ METHOD, TYPE }) > @Retention(RetentionPolicy.RUNTIME) > @ServiceHandlerBindingType > public @interface EchoService {} > {code} > Invocation handler: > {code:java} > @ServiceHandler > @EchoService > public class EchoServiceHandler { > @AroundInvoke > public Object invoke(InvocationContext ctx) { > return ctx.getMethod().getName().toString(); > } > } > {code} > Usage: > {code:java} > @EchoService > public interface HelloWorld { > String helloWorld(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 04:27:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 04:27:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-103) Support client controlled contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-103: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: 2.0 (discussion)) > Support client controlled contexts > ---------------------------------- > > Key: CDI-103 > URL: https://issues.jboss.org/browse/CDI-103 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Pete Muir > Fix For: 2.1 (Discussion) > > > In a client controlled context, the client controls via some identifier (probably an identifier, but we should allow the context to inspect the injection point) which contextual instances it sees for a particular bean type. For example given: > {code} > @MyScope > class Foo { > String name; > } > {code} > and a context which uses annotations to differentiate between contextual instance, these two injection points would see different instances: > {code} > @Inject @Bar Foo barFoo; > @Inject @Baz Foo bazFoo; > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 04:39:00 2016 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Mon, 10 Oct 2016 04:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Intoroduce BeanManager.event() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295652#comment-13295652 ] Sven Linstaedt edited comment on CDI-633 at 10/10/16 4:38 AM: -------------------------------------------------------------- [~manovotn] Not completely: {{javax.enterprise.event.Event}} is meant for application driven event triggering. In order to narrow down the event type, you can either specify a {{java.lang.Class}} or a for generics a {{javax.enterprise.util.TypeLiteral}}. As an extension developer, {{Event}} is not sufficient as you can neither # resolve {{Event}} before {{AfterDeploymentValidation}} nor # narrow down the event type by an extension-resolved {{java.lang.reflect.Type}}, which can not be hardcoded using {{TypeLiteral}} as the static type is not known to the extension and TypeLiteral was not meant for being created out of some unknown {{Type}}. So there is still a need for extending the existing method {{BeanManager#fire}} and of course keeping it backwards compatible as mentioned in CDI-493. was (Author: tzwoenn): [~manovotn] Not completely: {{javax.enterprise.event.Event}} is meant for application driven event triggering. In order to narrow down the event type, you can either specify a {{java.lang.Class}} or a for generics a {{javax.enterprise.util.TypeLiteral}}. As an extension developer, {{Event}} is not sufficient as you can neither # resolve {{Event}} before{{AfterDeploymentValidation}} nor # narrow down the event type by an extension-resolved {{java.lang.reflect.Type}}, which can not be hardcoded using {{TypeLiteral}} as the static type is not known to the extension and TypeLiteral was not meant for being created out of some unknown {{Type}}. So there is still a need for extending the existing method {{BeanManager#fire}} and of course keeping it backwards compatible as mentioned in CDI-493. > Intoroduce BeanManager.event() > ------------------------------ > > Key: CDI-633 > URL: https://issues.jboss.org/browse/CDI-633 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types > * the method should return {{javax.enterprise.event.Event}} with no qualifiers -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 05:13:00 2016 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Mon, 10 Oct 2016 05:13:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-455) Allow building of TypeLiteral's with dynamic types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304735#comment-13304735 ] Sven Linstaedt commented on CDI-455: ------------------------------------ At first I thought of {{TypeLiteral}} being a workaround for java's type erasure. Extending it by being able to create one from an unknown {{java.lang.Class}} with given type parameters or even {{java.lang.reflect.Type}} just to be able to "reuse" all existing APIs that accept a {{TypeLiteral}} smells like a dirty trick, as the benefit of type safety as mentioned before is lost. Secondly we have a bunch of existing APIs, that are meant to be used with "dynamic types". Most of them reside in {{javax.enterprise.inject.spi.BeanManager}} like {{BeanManager#getBeans}} or {{BeanManager#getReference}}. If there is a need to extend something, it may be more suitable to extend these APIs. > Allow building of TypeLiteral's with dynamic types > -------------------------------------------------- > > Key: CDI-455 > URL: https://issues.jboss.org/browse/CDI-455 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Lucas Ventura Carro > > It could be useful the building of {{TypeLiteral}}'s, but using dynamic types. This way, the types can be indicated at runtime and not in compile. This functionality is "doable" as it is done at [Guice|https://github.com/google/guice], a similar injection framework, and as [this post shows|http://luisfsgoncalves.wordpress.com/2010/09/08/generic-bindings-with-guice/]. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 05:14:01 2016 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Mon, 10 Oct 2016 05:14:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Intoroduce BeanManager.event() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304738#comment-13304738 ] Sven Linstaedt commented on CDI-633: ------------------------------------ To be a more concrete: I tried to write a meta-extension allowing "binding" of beans by (e.g. like in "interceptor binding") firing custom events during container initialization, similar to {{ProcessAnnotatedType}}, that may be handled by other extensions. The type parameter {{T}} is not known statically, but rather reflectively as {{java.lang.reflect.Type}}. So even being able to retrieve an {{Event}} before {{AfterDeploymentValidation }} does not help in this case, as {{Event}} was meant for use with a concrete type parameter {{T}} either via {{Class}} or {{TypeLiteral}}. This proposal does not supersedes it's linked duplicates imho. > Intoroduce BeanManager.event() > ------------------------------ > > Key: CDI-633 > URL: https://issues.jboss.org/browse/CDI-633 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types > * the method should return {{javax.enterprise.event.Event}} with no qualifiers -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 06:29:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 10 Oct 2016 06:29:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Intoroduce BeanManager.event() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304788#comment-13304788 ] Matej Novotny commented on CDI-633: ----------------------------------- I see, you cannot do anything with {{Event}} before deployment validation phase, so it won't help. Since you only have BM at that point, the solution would be to add another BM method, which would allow to explicitly state the type as well, is that correct? Something along these lines: {code} BeanManager#fire(type, event, qualifiers) {code} > Intoroduce BeanManager.event() > ------------------------------ > > Key: CDI-633 > URL: https://issues.jboss.org/browse/CDI-633 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types > * the method should return {{javax.enterprise.event.Event}} with no qualifiers -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 06:47:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 10 Oct 2016 06:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Introduce BeanManager.event() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-633: ----------------------------- Summary: Introduce BeanManager.event() (was: Intoroduce BeanManager.event()) > Introduce BeanManager.event() > ----------------------------- > > Key: CDI-633 > URL: https://issues.jboss.org/browse/CDI-633 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types > * the method should return {{javax.enterprise.event.Event}} with no qualifiers -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 06:52:00 2016 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Mon, 10 Oct 2016 06:52:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Introduce BeanManager.event() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304796#comment-13304796 ] Sven Linstaedt commented on CDI-633: ------------------------------------ Some enhancement like that, yeah. A similar solution was already stated in CDI-493 and CDI-516. This new API enhancement should accept any {{java.lang.reflect.Type}}, that does not contain a TypeVariable, but will throw an {{IllegalArgumentException}} otherwise. Of course only the raw type of the event object could only be checked against the type parameter for consistency, so we loose a good amount of type safety here. But as these API is primary meant to be used by extensions like the majority of {{BeanManager}} methods, at least I am fine with it. In addition the original methods ({{fireEvent(event, qualifiers)}} and {{resolveObserverMethods(event, qualifiers)}}) must be kept for backward compability and probably will keep the use the event object's class for resolution, which implies the event class must not have any type variable as this will cause the documented {{IllegalArgumentException}}. > Introduce BeanManager.event() > ----------------------------- > > Key: CDI-633 > URL: https://issues.jboss.org/browse/CDI-633 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types > * the method should return {{javax.enterprise.event.Event}} with no qualifiers -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 08:40:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 08:40:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-89) Add @Unwraps from Seam Solder In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-89: ------------------------------------ Fix Version/s: TBD (was: 2.0 (discussion)) > Add @Unwraps from Seam Solder > ------------------------------ > > Key: CDI-89 > URL: https://issues.jboss.org/browse/CDI-89 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Fix For: TBD > > > @Unwraps allows for an essentially stateless scope for producer methods and fields. > At injection time a dependent scoped proxy is injected into the injection point. When a methods is invoked on this proxy it calls the corresponding @Unwraps methods to get the instance to invoke the method on. > Because the proxy is @Dependent scoped, the @Unwraps method can inject the corresponding InjectionPoint. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 08:40:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 08:40:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-79) Allow you to inspect the decorator chain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-79: ------------------------------------ Fix Version/s: TBD (was: 2.0 (discussion)) > Allow you to inspect the decorator chain > ---------------------------------------- > > Key: CDI-79 > URL: https://issues.jboss.org/browse/CDI-79 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 08:41:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 08:41:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-63) Add section on cyclic dependencies to the spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-63: ------------------------------------ Fix Version/s: TBD (was: 2.0 (discussion)) > Add section on cyclic dependencies to the spec > ---------------------------------------------- > > Key: CDI-63 > URL: https://issues.jboss.org/browse/CDI-63 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 08:45:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 08:45:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-61) Producers and beans that are under construction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-61: ------------------------------------ Fix Version/s: 2.1 (Discussion) (was: 2.0 (discussion)) > Producers and beans that are under construction > ----------------------------------------------- > > Key: CDI-61 > URL: https://issues.jboss.org/browse/CDI-61 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 2.1 (Discussion) > > > I think we need the spec to say something about cases where an injection point of a bean resolves to a producer method of the same bean. The implementation should detect that this is a definition error. It shouldn't try to call a producer method on a non-fully-initialized bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 08:48:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 08:48:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-45: ------------------------------------ Fix Version/s: TBD (was: 2.0 (discussion)) > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: TBD > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 08:48:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 08:48:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-45: ------------------------------------ Priority: Optional (was: Major) > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Priority: Optional > Fix For: TBD > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 08:52:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 08:52:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-37) Stateless scope In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-37: ------------------------------------ Fix Version/s: TBD (was: 2.0 (discussion)) > Stateless scope > --------------- > > Key: CDI-37 > URL: https://issues.jboss.org/browse/CDI-37 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Adam Warski > Fix For: TBD > > > From a discussion on weld-dev (http://lists.jboss.org/pipermail/weld-dev/2011-January/002825.html): > Here's my use-case: > I have some beans which are inherently stateless, e.g. "services" or factory methods. The only fields they have are injected. I am using these beans in normal-scoped passivation-capable beans, e.g. session or conversation scoped. In such case, they also have to be passivation-capable, which means either > (a) be normal-scoped (proxyable) > (b) implement Serializable and leave the bean dependent-scoped > If I go with (a) this means that I'd have to put my bean in the request, session, conversation or application scope. However none of these choices make much sense, as they indicate the my beans holds request/session/etc-scoped data - which it doesn't, as it is stateless. > So I am left with (b) - implement Serializable + dependent scope. But is that the right thing to do always? Firstly, if I have a lot of such stateless beans, which are injected one into another, serializing a simple session-scope bean may mean that half the beans in my application get serialized. Secondly, a developer looking at such a bean could wonder why is this bean serializable? Esp if it doesn't have any state? > Hence what I'd like in fact is a proxyable scope (normal), which on serialization would only write the proxy information, on de-serialization would inject a new instance of the bean (or from a pool), and on injection would either behave as dependent (new instance), or take beans from a pool. Just as the EJB Stateless scope (except that I don't want to make my bean an EJB). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 08:53:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 08:53:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-29) Method of accessing contexts regardless of active state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-29: ------------------------------------ Fix Version/s: 2.1 (Discussion) (was: 2.0 (discussion)) > Method of accessing contexts regardless of active state > ------------------------------------------------------- > > Key: CDI-29 > URL: https://issues.jboss.org/browse/CDI-29 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Nicklas Karlsson > Fix For: 2.1 (Discussion) > > > It would be practical to have a way of accessing contexts from the BeanManager regardless of their active state. Currently, contexts cannot be activated (e.g. Conversation) in a portable way because there is no way of getting the inactive context in order to activate it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 08:55:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 08:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-21) Support PostConstruct callbacks in Extension class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-21. ----------------------------------- Resolution: Rejected {{@BeforeBeanDiscovery}} is nearly the equivalent of {{@PostConstruct}} from the extension inititlisation POV. > Support PostConstruct callbacks in Extension class > -------------------------------------------------- > > Key: CDI-21 > URL: https://issues.jboss.org/browse/CDI-21 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Sivakumar Thyagarajan > Priority: Minor > Fix For: 2.0 (discussion) > > > It is sometimes useful to get to know after a portable extension class has been instantiated, so that the state of the Extension could be initialized [ie not establishing state in the constructor and having it called twice when the Extension is proxied]. Though the 1.0 specification does not require this, it would be useful to support @PostConstruct callback on Extension class in the next version of the specification. > Please see https://jira.jboss.org/browse/WELD-713 for additional information on this issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 08:56:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 08:56:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-20) @Observes(propagate = false) - stop event propagation after being handled by an observer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-20. ----------------------------------- Resolution: Rejected Kills the idea of decoupling behind event. And BTW throwing an exception in a synchronous observer can do the trick. > @Observes(propagate = false) - stop event propagation after being handled by an observer > ---------------------------------------------------------------------------------------- > > Key: CDI-20 > URL: https://issues.jboss.org/browse/CDI-20 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.0 > Environment: any > Reporter: Walter White > Fix For: 2.0 (discussion) > > > I would like to have the ability to stop event propagation after it is handled by any observer only for certain situations. Is it possible to add a property to the annotation indicating whether the propagation should continue after being handled by the observer? Alternatively, would it be more concise to add a qualifier annotation which specifies the propagation. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 08:57:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 08:57:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-19) Ordering execution on Extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-19. ------------------------------------- Resolution: Rejected CDI-4 brings a solution for this ordering > Ordering execution on Extensions > -------------------------------- > > Key: CDI-19 > URL: https://issues.jboss.org/browse/CDI-19 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Robson Ximenes > Priority: Minor > Fix For: 2.0 (discussion) > > > I believe the cdi portable extension could have the load order of extensions the same as it is registered; > It is possible that one extension expect some previous preparation of beans from another extension -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 08:58:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 08:58:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-10: ------------------------------------ Fix Version/s: 2.1 (Discussion) (was: 2.0 (discussion)) > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > Labels: F2F2016 > Fix For: 2.1 (Discussion) > > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 09:13:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 09:13:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-9) Interceptors are not applied to custom bean types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-9. ------------------------------------ Resolution: Duplicate Issue Effort on this feature will be done in CDI-580 > Interceptors are not applied to custom bean types > ------------------------------------------------- > > Key: CDI-9 > URL: https://issues.jboss.org/browse/CDI-9 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Interceptors, Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > Beans added through the SPI do not have interceptors applied. > Even though bean does not have a getInterceptorBindings() method, interceptors applied to stereotypes should still work. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 09:14:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 09:14:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-8) Decorators are not applied to custom beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-8. ------------------------------------ Resolution: Duplicate Issue Effort on this feature will be done in CDI-580 > Decorators are not applied to custom beans > ------------------------------------------ > > Key: CDI-8 > URL: https://issues.jboss.org/browse/CDI-8 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators, Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > Beans added with AfterBeanDiscovery.addBean() do not have decorators applied -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 09:22:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 09:22:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-636) Add Instance.stream() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-636: ------------------------------------- Fix Version/s: 2.0 .Final > Add Instance.stream() > --------------------- > > Key: CDI-636 > URL: https://issues.jboss.org/browse/CDI-636 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: John Ament > Fix For: 2.0 .Final > > > Add the ability to stream all bean instances from an Instance. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 09:23:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 09:23:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-635) Session context activation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-635: ------------------------------------- Fix Version/s: 2.0 .Final > Session context activation > -------------------------- > > Key: CDI-635 > URL: https://issues.jboss.org/browse/CDI-635 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.2.Final > Reporter: John Ament > Fix For: 2.1 (Discussion) > > > This is split from discussions around CDI-30. It was agreed that session context management and request context management are two different things. CDI-30 is now targeted to just managing request contexts, this ticket is to manage session contexts. > When considering this ticket, think of the following: > - How to associate a context with multiple threads > - How to look up a session context -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 09:23:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 09:23:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-635) Session context activation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-635: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: 2.0 .Final) > Session context activation > -------------------------- > > Key: CDI-635 > URL: https://issues.jboss.org/browse/CDI-635 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.2.Final > Reporter: John Ament > Fix For: 2.1 (Discussion) > > > This is split from discussions around CDI-30. It was agreed that session context management and request context management are two different things. CDI-30 is now targeted to just managing request contexts, this ticket is to manage session contexts. > When considering this ticket, think of the following: > - How to associate a context with multiple threads > - How to look up a session context -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 09:26:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 10 Oct 2016 09:26:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-636) Add Instance.stream() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament reassigned CDI-636: ------------------------------ Assignee: John Ament > Add Instance.stream() > --------------------- > > Key: CDI-636 > URL: https://issues.jboss.org/browse/CDI-636 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: John Ament > Assignee: John Ament > Fix For: 2.0 .Final > > > Add the ability to stream all bean instances from an Instance. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 09:26:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 10 Oct 2016 09:26:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-636) Add Instance.stream() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-636 started by John Ament. -------------------------------------- > Add Instance.stream() > --------------------- > > Key: CDI-636 > URL: https://issues.jboss.org/browse/CDI-636 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: John Ament > Assignee: John Ament > Fix For: 2.0 .Final > > > Add the ability to stream all bean instances from an Instance. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 09:44:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 09:44: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:all-tabpanel ] Antoine Sabot-Durand updated CDI-622: ------------------------------------- Fix Version/s: 2.1 (Discussion) > 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 > Fix For: 2.1 (Discussion) > > > 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 Oct 10 09:50:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 09:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-614) Review all read methods at configurators In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-614: ------------------------------------- Fix Version/s: 2.0 .Final > Review all read methods at configurators > ---------------------------------------- > > Key: CDI-614 > URL: https://issues.jboss.org/browse/CDI-614 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0-EDR2 > Reporter: Tomas Remes > Fix For: 2.0 .Final > > > Currently there are several read methods used to initialize given configurator. These methods are at: > * {{BeanConfigurator}} > * {{InjectionPointConfigurator}} > * {{ObserverMethodConfigurator}} > I think we should review all of them. I don't understand to usage or let say additional value of the following ones: > * {{ObserverMethodConfigurator#read(javax.enterprise.inject.spi.ObserverMethod)}} > This allows you to add new observer method based on exsiting one. Although when you want to define some observed type (of this new method) you need to specify subtype of the original type or you will end up with ClassCastException. > Then there are those at {{InjectionPointConfigurator}} which appears to me completely useless: > * {{InjectionPointConfigurator#read(java.lang.reflect.Field)}} > * {{InjectionPointConfigurator#read(java.lang.reflect.Parameter)}} > * {{InjectionPointConfigurator#read(javax.enterprise.inject.spi.AnnotatedField)}} > * {{InjectionPointConfigurator#read(javax.enterprise.inject.spi.AnnotatedParameter)}} > * {{InjectionPointConfigurator#read(javax.enterprise.inject.spi.InjectionPoint)}} > AFAIK the {{InjectionPointConfigurator}} is available only during {{ProcessInjectionPoint}} lifecycle event. My question is why should I use any of these during this lifecycle event since I can easily call {{event.configureInjectionPoint()}}? Do we want to allow to configure different injection point in non corresponding {{ProcessInjectionPoint}} lifecycle event? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 09:53:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 10 Oct 2016 09:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-632) Possible conflict for Implicit bean archive definition between core and SE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-632: ------------------------------------- Fix Version/s: TBD > Possible conflict for Implicit bean archive definition between core and SE > -------------------------------------------------------------------------- > > Key: CDI-632 > URL: https://issues.jboss.org/browse/CDI-632 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java SE Integration > Affects Versions: 2.0-EDR2 > Reporter: Antoine Sabot-Durand > Priority: Minor > Fix For: TBD > > > Section 12.1 (which should be satisfied in SE an EE) states: > bq. An implicit bean archive is any other archive which contains one or more bean classes with a bean defining annotation as defined in Bean defining annotations. > And section 15.1 reads: > {quote}When running in Java SE, the container must extend the rules defined in Bean archives and also ensure that : > An archive which doesn?t contain a beans.xml file can?t be discovered as an implicit bean archive unless: > * the application is launched with system property javax.enterprise.inject.scan.implicit set to true, or > * the container was initialized with a parameter map containing an entry with javax.enterprise.inject.scan.implicit as key and Boolean.TRUE as value.{quote} > Perhaps this deserve a bit of clarification. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 10:04:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 10 Oct 2016 10:04:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-523) CDI spec tries to dispose a container-managed entity manager. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-523 started by John Ament. -------------------------------------- > CDI spec tries to dispose a container-managed entity manager. > ------------------------------------------------------------- > > Key: CDI-523 > URL: https://issues.jboss.org/browse/CDI-523 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final, 1.1.Final > Reporter: Martin Andersson > Assignee: John Ament > Fix For: 2.0 .Final > > > Section "3.5.2. Declaring a disposer method" has this example: > {code:java} > public class Resources { > @PersistenceContext > @Produces @UserDatabase > private EntityManager em; > > public void close(@Disposes @UserDatabase EntityManager em) { > em.close(); > } > } > {code} > The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says: > {quote} > The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager. > {quote} > This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java]. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 10:04:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 10 Oct 2016 10:04:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-523) CDI spec tries to dispose a container-managed entity manager. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament reassigned CDI-523: ------------------------------ Assignee: John Ament > CDI spec tries to dispose a container-managed entity manager. > ------------------------------------------------------------- > > Key: CDI-523 > URL: https://issues.jboss.org/browse/CDI-523 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final, 1.1.Final > Reporter: Martin Andersson > Assignee: John Ament > Fix For: 2.0 .Final > > > Section "3.5.2. Declaring a disposer method" has this example: > {code:java} > public class Resources { > @PersistenceContext > @Produces @UserDatabase > private EntityManager em; > > public void close(@Disposes @UserDatabase EntityManager em) { > em.close(); > } > } > {code} > The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says: > {quote} > The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager. > {quote} > This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java]. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 10:50:00 2016 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Mon, 10 Oct 2016 10:50: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=13304963#comment-13304963 ] Sven Linstaedt commented on CDI-622: ------------------------------------ >From an integration point of view this proposal may be interesting as afaik there is no "standard" way to configure beans/extensions currently. Each framework and/or extension has their own way to do this. E.g. even deltaspike has several different abstractions of configuration to enable users to customize it for their use. > 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 > Fix For: 2.1 (Discussion) > > > 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 Tue Oct 11 04:53:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:53:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in Instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-232: ------------------------------------- Sprint: Sprint 1 > Relax requirements for built-in Instance > ---------------------------------------- > > Key: CDI-232 > URL: https://issues.jboss.org/browse/CDI-232 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.EDR > Reporter: Martin Kouba > Priority: Minor > Labels: F2F2016 > Fix For: 2.0 .Final > > > 5.6.2. The built-in Instance > {quote} > The container must provide a built-in bean with: > * Instance and Provider for every legal bean type X in its set of bean types, > * every qualifier type in its set of qualifier types, > {quote} > This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording. > By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 04:53:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:53:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-449) beans.xml examples are not valid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-449: ------------------------------------- Sprint: Sprint 1 > beans.xml examples are not valid > -------------------------------- > > Key: CDI-449 > URL: https://issues.jboss.org/browse/CDI-449 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > The {{beans.xml}} examples in "5.1.1. Declaring selected alternatives", "8.2.2. Decorator enablement and ordering for a bean archive" and "9.4. Interceptor enablement and ordering" (which contain a reference to beans_1_1.xsd) are not valid - {{bean-discovery-mode}} attribute is required. I think it would be appropriate to specify the version attribute as well. > The last {{beans.xml}} example in "12.4.2. Exclude filters" does not even define the reference to an XSD. Again, I believe the version and bean-discovery-mode attributes should be specified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 04:53:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:53:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-477) Update outdated package-info.java in javax.enterprise.inject package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-477: ------------------------------------- Sprint: Sprint 1 > Update outdated package-info.java in javax.enterprise.inject package > -------------------------------------------------------------------- > > Key: CDI-477 > URL: https://issues.jboss.org/browse/CDI-477 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > Update or remove this javadoc. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 04:53:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:53:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-471: ------------------------------------- Sprint: Sprint 1 > Support repeating qualifiers in typesafe resolution mechanism > ------------------------------------------------------------- > > Key: CDI-471 > URL: https://issues.jboss.org/browse/CDI-471 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Reporter: Antonin Stefanutti > Labels: F2F2016 > Fix For: 2.0 .Final > > > As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it would be valuable to percolate that support into the CDI typesafe resolution mechanism. > For example, one could write: > {code} > @Qualifier > @Repeatable(ContextNames.class) > public interface @ContextName { > String value; > } > public @interface ContextNames { > ContextName[] value(); > } > {code} > And then: > {code} > @ContextName("ctx1") > class CamelContext1 { > } > @ContextName("ctx2") > class CamelContext2 { > } > @Uri("") > @Produces > @ContextName("ctx1") > @ContextName("ctx2") > static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance instance) { > } > {code} > That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies. > Support of the annotation container / list for backward compatibility could be provided as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 04:53:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:53:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-486) Define security constraints for using CDI SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-486: ------------------------------------- Sprint: Sprint 1 > Define security constraints for using CDI SPI > --------------------------------------------- > > Key: CDI-486 > URL: https://issues.jboss.org/browse/CDI-486 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Priority: Critical > Fix For: 2.0 .Final > > > Currently, the specification does not require any security checks to be performed when CDI SPI is used. It is not clear how this should be implemented. > Note that since a CDI implementation is required to support bypassing platform securiy checks (e.g. when invoking aprivate observer method), total absence of security checks on CDI SPI level could result in privilege escalation. Here's an example: > Suppose the application server bundles a sensitive method: > {code:JAVA} > public class ApplicationServer { > static boolean explode() { > // ... > } > } > {code} > The method is package-private and thus cannot be by an application. If the application would be to invoke this method using reflection, it would need to first obtain the Method handle for the explode method. Obtaining a Method handle requires the "accessDeclaredMembers" runtime permission which the application does not have. It can however use the CDI SPI: > {code:JAVA} > Method method = null; > for (AnnotatedMethod annotatedMethod : manager.createAnnotatedType(ApplicationServer.class).getMethods()) { > if (annotatedMethod.getJavaMember().equals("explode")) { > method = annotatedMethod.getJavaMember(); > break; > } > } > {code} > Now the application has the Method handle without having the "accessDeclaredMembers" permission. > The application still cannot invoke the method as it needs to bypass security checks on access to the method first. This cannot be done without the "suppressAccessChecks" runtime permission. > Again, remember that CDI implementations are supposed to be capable of invoking inaccessible methods and this capability is exposed through the SPI. Therefore, the application call: > {code:JAVA} > Producer producer = manager.getProducerFactory(annotatedMethod, null).createProducer(null); > {code} > Now, calling producer.produce() will cause the sensitive method to be invoked even though the application was not granted "accessDeclaredMembers" neither "suppressAccessChecks" permission. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 04:53:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:53:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-489) NonexistentConversationException thrown at restore view or not? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-489: ------------------------------------- Sprint: Sprint 1 > NonexistentConversationException thrown at restore view or not? > --------------------------------------------------------------- > > Key: CDI-489 > URL: https://issues.jboss.org/browse/CDI-489 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 1.2.Final > Reporter: Vsevolod Golovanov > Fix For: 2.0 .Final > > > The 1.0 spec says in 6.7.4: > {quote}If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and throw an exception of type javax.enterprise.context.NonexistentConversationException from the restore > view phase of the JSF lifecycle. The application may handle this exception using the JSF ExceptionHandler.{quote} > 1.1 and 1.2 just say: > {quote} > If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and > throw an exception of type javax.enterprise.context.NonexistentConversationException. > {quote} > Yet the javadoc of NonexistentConversationException for both 1.1 and 1.2 says: > {quote} > If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and throw an exception of type NonexistentConversationException from the restore view phase of the JSF lifecycle. > {quote} > So is it supposed to be thrown from restore view or not? I assume not. Probably javadoc should be amended. > I'm curious about reasoning behind the change. I tried searching for an explanation but didn't find anything. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 04:53:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:53:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-495) What happens if an illegal bean type is found in the set of bean types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-495: ------------------------------------- Sprint: Sprint 1 > What happens if an illegal bean type is found in the set of bean types > ---------------------------------------------------------------------- > > Key: CDI-495 > URL: https://issues.jboss.org/browse/CDI-495 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 04:53:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:53:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-490: ------------------------------------- Sprint: Sprint 1 > Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml > ------------------------------------------------------------------------------------------------ > > Key: CDI-490 > URL: https://issues.jboss.org/browse/CDI-490 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators, Interceptors > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Labels: F2F2016 > Fix For: 2.0 .Final > > > Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because: > {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final > list of interceptors for the application, as defined in Section 11.5.2, ?AfterTypeDiscovery event?.{quote} > it matches both parts of the statement. > As for ordering, the following statement defines invocation order: > {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote} > Since InterceptorA is enabled by both @Priority and beans.xml, the following applies: > "Interceptors enabled using @Priority" = \{ InterceptorA \} > "interceptors enabled using beans.xml" = \{ InterceptorA \} > We can perform substitution in the statement and we get: > *\{ InterceptorA \} are called before \{ InterceptorA \}* > which does not seem right. > The specification should explicitly address this scenario. There are several options (some of them are better, some are worse): > 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml > 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence) > 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence) > 4) Forbid an interceptor to be enabled by both @Priority and beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 04:53:03 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:53:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-497) session scope doesn't follow session lifecycle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-497: ------------------------------------- Sprint: Sprint 1 > session scope doesn't follow session lifecycle > ---------------------------------------------- > > Key: CDI-497 > URL: https://issues.jboss.org/browse/CDI-497 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > Fix For: 2.0 .Final > > > ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case). > Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 04:53:03 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:53:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-498) Revise "6.7.5. The Conversation interface" - dots are not valid in EL name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-498: ------------------------------------- Sprint: Sprint 1 > Revise "6.7.5. The Conversation interface" - dots are not valid in EL name > -------------------------------------------------------------------------- > > Key: CDI-498 > URL: https://issues.jboss.org/browse/CDI-498 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Tomas Remes > Fix For: 2.0 .Final > > > Seems that following part contradicts the EL spec: > {quote}The container provides a built-in bean with bean type Conversation , scope @RequestScoped , > and qualifier @Default , named javax.enterprise.context.conversation .{quote} > The EL name "javax.enterprise.context.conversation" is not valid. > Discussion available at http://transcripts.jboss.org/channel/irc.freenode.org/%23cdi-dev/2015/%23cdi-dev.2015-01-06.log.html > and > http://lists.jboss.org/pipermail/cdi-dev/2015-January/thread.html - topic "where is defined javax.enterprise.context.conversation.id?" -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 04:53:03 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:53:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-500) Clarify @Intercepted Bean metadata injection for EE components In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-500: ------------------------------------- Sprint: Sprint 1 > Clarify @Intercepted Bean metadata injection for EE components > -------------------------------------------------------------- > > Key: CDI-500 > URL: https://issues.jboss.org/browse/CDI-500 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > It's not clear what should happen when an interceptor with {{@Intercepted Bean}} metadata is associated with an EE component. > See the CDI spec, "5.5.8. Bean metadata": > {quote} > Additionally, the container must provide beans allowing interceptors and decorators to obtain information about the beans they intercept and decorate: > * a bean with scope @Dependent, qualifier @Intercepted and type Bean which can be injected into any interceptor instance, and > * ... > {quote} > However, most EE components must also support the use of CDI interceptors. See also the Java EE 7 spec, "EE.5.2.5 Annotations and Injection": > {quote} > The component classes listed in Table EE.5-1 with support level "Standard" > all support Java EE resource injection, as well as PostConstruct and PreDestroy callbacks. In addition, if CDI is enabled?which it is by default?these classes also support CDI injection, as described in Section EE.5.24, "Support for Dependency Injection", and the use of interceptors. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 04:53:03 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:53:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-546) Constant for default observer priority In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-546: ------------------------------------- Sprint: Sprint 1 > Constant for default observer priority > -------------------------------------- > > Key: CDI-546 > URL: https://issues.jboss.org/browse/CDI-546 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Priority: Minor > Fix For: 2.0 .Final > > > Currently we use: > {code:JAVA} > @Override > public default int getPriority() { > return javax.interceptor.Interceptor.Priority.APPLICATION + 500; > }; > {code} > It would be nice to have the value stored as a constant e.g.: > {code:JAVA} > int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500; > {code} > so that other code can reference it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 04:54:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-592) Consider adding ObserverMethod.notify() method which also accepts EventMetadata In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-592: ------------------------------------- Sprint: Sprint 1 > Consider adding ObserverMethod.notify() method which also accepts EventMetadata > ------------------------------------------------------------------------------- > > Key: CDI-592 > URL: https://issues.jboss.org/browse/CDI-592 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > {code:java} > // Make the original method also default so that new impls don't need to implement two methods > default void notify(T event) { > // No-op > } > // The container should always call this method... > default void notify(T event, EventMetadata metadata) { > notify(event); > } > {code} > This should not break existing implementations. The truth is a custom impl will not be forced to implement any {{notify()}} method. But I think the benefits are worth it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 04:54:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:54:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-593) Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-593: ------------------------------------- Sprint: Sprint 1 > Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc > ------------------------------------------------------------------------------------ > > Key: CDI-593 > URL: https://issues.jboss.org/browse/CDI-593 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > * javadoc would definitely deserve some more info > * the spec text should mention this interface as well and describe basic use cases (e.g. an interceptor passed to {{AfterBeanDiscovery.addBean()}} and implementing this interface is globally enabled) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 04:54:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:54:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-612) ObserverMethodConfigurator.notifyWith() should probably accept a functional interface whose method throws java.lang.Exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-612: ------------------------------------- Sprint: Sprint 1 > ObserverMethodConfigurator.notifyWith() should probably accept a functional interface whose method throws java.lang.Exception > ----------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-612 > URL: https://issues.jboss.org/browse/CDI-612 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > The regular observer methods may also throw checked exceptions (wrapped and rethrown as an (unchecked) {{ObserverException}}). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 04:54:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:54:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-616) Injection point declared as transient is not useful In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-616: ------------------------------------- Sprint: Sprint 1 > Injection point declared as transient is not useful > --------------------------------------------------- > > Key: CDI-616 > URL: https://issues.jboss.org/browse/CDI-616 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > Priority: Minor > Fix For: 2.0 .Final > > > An injection point declared as 'transient' is not useful, due to the fact of after bean's passivation, the transient field will not be reinjected and its value will be lost. This causes confusion. See Weld forum discussion [link title|https://developer.jboss.org/thread/179486]. In the section 5.5.7, how about to make the following changes? > The isTransient() method returns true if the injection point is a transient field, and > false otherwise. If the injection point represents a dynamically obtained instance then the > isTransient() method returns true if the Instance injection point is a transient field, and > false otherwise. > => > The isTransient() method returns true if the injection point is a transient field, and > false otherwise. If the injection point represents a dynamically obtained instance then the > isTransient() method returns true if the Instance injection point is a transient field, and > false otherwise. If this injection point is declared as transient, after bean's passivation, the value will not be restored. Instance injection point is the preferred approach. > Any other better suggestions? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 04:54:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:54:02 -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:all-tabpanel ] Antoine Sabot-Durand updated CDI-623: ------------------------------------- Sprint: Sprint 1 > 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 > Labels: F2F2016 > Fix For: 2.0 .Final > > > 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 issues at jboss.org Tue Oct 11 04:54:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 04:54:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-627: ------------------------------------- Sprint: Sprint 1 > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Fix For: 2.0 .Final > > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Tue Oct 11 05:37:22 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 11 Oct 2016 09:37:22 +0000 Subject: [cdi-dev] Cleaning the backlog for feature freeze Message-ID: Hi all, I made some housekeeping in our ticket in prevision of CDI 2.0 final release. You can now use the following filters in Jira: - Targeted for 2.0 final [1]. It contains 27 tickets with 8 of them being worked on. Contains feature and clarification that we should be able to deliver for 2.0 - Discussed for 2.0 [2]. A remaining stock of tickets (9), that are still under discussion. Some of them may make it for CDI 2.0 I created a new version "Discussed for 2.1" in which I put mostly tickets linked to other specs or interesting one that can be fir in 2.0 release If you think something important is missing, it's still time to add things here. Thanks for your feedbeck, [1]: https://issues.jboss.org/browse/CDI-633?filter=12328604 [2]: https://issues.jboss.org/browse/CDI-631?filter=12328671 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161011/3d67581e/attachment.html From issues at jboss.org Tue Oct 11 05:52:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 11 Oct 2016 05:52:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305353#comment-13305353 ] Mark Struberg commented on CDI-627: ----------------------------------- plz review the pull request. > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 .Final > > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 05:52:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 11 Oct 2016 05:52:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned CDI-627: --------------------------------- Assignee: Mark Struberg > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 .Final > > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 05:59:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 11 Oct 2016 05:59:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-616) Injection point declared as transient is not useful In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305355#comment-13305355 ] Mark Struberg commented on CDI-616: ----------------------------------- > Do nothing but add clarification in the spec : Injection in transient field is not supported. We probably are talking about thesame thing, but the wording is not quite as discussed on the ML as far as I interpret it. Why should the injection itself not be supported? I think what we agreed on is that we just don't do anything for RE-injecting it in case of deserialisation. At least that was I understood during our discussion. Not sure we need to clarify anything as this is standard Java behaviour: the developer is responsible to get back any transient fields himself by default. > Injection point declared as transient is not useful > --------------------------------------------------- > > Key: CDI-616 > URL: https://issues.jboss.org/browse/CDI-616 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > Priority: Minor > Fix For: 2.0 .Final > > > An injection point declared as 'transient' is not useful, due to the fact of after bean's passivation, the transient field will not be reinjected and its value will be lost. This causes confusion. See Weld forum discussion [link title|https://developer.jboss.org/thread/179486]. In the section 5.5.7, how about to make the following changes? > The isTransient() method returns true if the injection point is a transient field, and > false otherwise. If the injection point represents a dynamically obtained instance then the > isTransient() method returns true if the Instance injection point is a transient field, and > false otherwise. > => > The isTransient() method returns true if the injection point is a transient field, and > false otherwise. If the injection point represents a dynamically obtained instance then the > isTransient() method returns true if the Instance injection point is a transient field, and > false otherwise. If this injection point is declared as transient, after bean's passivation, the value will not be restored. Instance injection point is the preferred approach. > Any other better suggestions? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From manovotn at redhat.com Tue Oct 11 06:06:23 2016 From: manovotn at redhat.com (Matej Novotny) Date: Tue, 11 Oct 2016 06:06:23 -0400 (EDT) Subject: [cdi-dev] Cleaning the backlog for feature freeze In-Reply-To: References: Message-ID: <132197507.1416594.1476180383490.JavaMail.zimbra@redhat.com> You probably meant these links instead (yours lead to a specific issue): [1]: https://issues.jboss.org/issues/?filter=12328604 [2]: https://issues.jboss.org/issues/?filter=12328671 ----- Original Message ----- > From: "Antoine Sabot-Durand" > To: "cdi-dev" > Sent: Tuesday, October 11, 2016 11:37:22 AM > Subject: [cdi-dev] Cleaning the backlog for feature freeze > > Hi all, > > I made some housekeeping in our ticket in prevision of CDI 2.0 final release. > > You can now use the following filters in Jira: > - Targeted for 2.0 final [1]. It contains 27 tickets with 8 of them being > worked on. Contains feature and clarification that we should be able to > deliver for 2.0 > - Discussed for 2.0 [2]. A remaining stock of tickets (9), that are still > under discussion. Some of them may make it for CDI 2.0 > > I created a new version "Discussed for 2.1" in which I put mostly tickets > linked to other specs or interesting one that can be fir in 2.0 release > > If you think something important is missing, it's still time to add things > here. > > Thanks for your feedbeck, > > > > [1]: https://issues.jboss.org/browse/CDI-633?filter=12328604 > [2]: https://issues.jboss.org/browse/CDI-631?filter=12328671 > > _______________________________________________ > 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 Tue Oct 11 06:08:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 06:08:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-30) An API for managing built in contexts designed for other frameworks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-30: ------------------------------------ Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > An API for managing built in contexts designed for other frameworks > ------------------------------------------------------------------- > > Key: CDI-30 > URL: https://issues.jboss.org/browse/CDI-30 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Nicklas Karlsson > Assignee: John Ament > Fix For: 2.0 .Final > > > In order to allow CDI to play well in the general ecosystem, it needs to have SPIs. These SPIs need to allow other libraries to do things like register beans (CDI extensions), look up a bean manager, and get managed versions of its classes. > CDI has no way currently to support a framework starting and stopping built in contexts. These built in contexts are not really clear in how they are started, other than the container is responsible for starting them. This means its near impossible for an external library which is not Java EE aware to start these built in contexts. Being able to reuse these contexts allow developers to build their beans once and reuse them in many use cases. > These use cases may include: > 1. Quartz Scheduler/CDI Integration. A Prototype of this is available in DeltaSpike, where jobs can be managed beans, by overriding the InstanceJobFactory, and can have contexts started via an annotation. To bring it a step further, Quartz, in order to mirror Java EE capabilities, may want to say that during the execution of a job, an instance of a request context is active. To do this, the developer should not need to do anything, but instead Quartz may automatically register a job listener that starts and stops the context (see: http://www.quartz-scheduler.org/documentation/quartz-2.2.x/cookbook/JobListeners.html) > 2. Camel-CDI. Camel may want to say that during the execution of a route, a request context is active. > 3. Netty/CDI (or any arbitrary network based server). During the reception of a message over TCP, a request is active. Likewise, for the entire TCP connection a session context is active. > 4. Sparkjava/CDI. Assuming that sparkjava isn't running in a servlet container, during the execution of an arbitrary reactive method call, a request context is available for use. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 06:09:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 06:09:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-129) Clarify behaviour of @ApplicationScoped in EARs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-129: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Clarify behaviour of @ApplicationScoped in EARs > ----------------------------------------------- > > Key: CDI-129 > URL: https://issues.jboss.org/browse/CDI-129 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Contexts > Affects Versions: 1.0 > Reporter: Mark Struberg > Assignee: Pete Muir > Labels: F2F2016, application-scoped, visibility > Fix For: TBD > > > Since @ApplicationScoped currently is defined in 6.5.2 as to be 'like in the Servlet specification' this means that you will get a new instance for every WebApplication (WAR file). > There is currently no specified CDI scope for providing a single shared instance for a whole EAR. > We could (ab-)use @Singleton for that, but this is currently not well defined at all. > Alternatively we could introduce an own new annotation like @EnterpriseScoped or likes. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 10:00:05 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 10:00:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-578) define behaviour of firing an event for an observer with transaction if the transaction is not open or marked rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-578: ------------------------------------- Fix Version/s: 2.0 .Final > define behaviour of firing an event for an observer with transaction if the transaction is not open or marked rollback > ---------------------------------------------------------------------------------------------------------------------- > > Key: CDI-578 > URL: https://issues.jboss.org/browse/CDI-578 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Fix For: 2.0 .Final > > > The original problem description can be found at https://issues.apache.org/jira/browse/OWB-1111 > If you have an observer > {code} > public void clearCacheAfterTx(@Observes(during=TransactionPhase.AFTER_COMPLETION) ClearAfterTx payload) {...} > {code} > and you fire the event > {code} > clearCacheEvent.fire(new ClearCacheEvent()); > {code} > In this case the behaviour when firing the event if the underlying transaction is already closed or rolled back is totally undefined. It might blow up or continue silently depending on the server. > The problem is that you cannot enlisten a Synchronisation at the tx anymore. > I think we should define/clarify how it should behave in the various phases. > E.g. a during=AFTER_SUCCESS should NOT deliver the event immediately if the tx is already marked for rollback. But for AFTER_COMPLETION it might be perfectly fine. > At the end we need a matrix of the the event phases + possible Exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Tue Oct 11 10:02:30 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 11 Oct 2016 14:02:30 +0000 Subject: [cdi-dev] Today's meeting on Hangout Message-ID: Hi all, Just to remind you that today's meeting will be on Hangout: https://hangouts.google.com/hangouts/_/sabot-durand.net/antoine We'll discuss mainly about CDI-578 (use cases for transactional observer) and CDI-625 (introduction of BeforeDestroyed and AfterDestroyed qualifiers) Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161011/bdf484ec/attachment.html From issues at jboss.org Tue Oct 11 10:59:01 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Tue, 11 Oct 2016 10:59:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-449) beans.xml examples are not valid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305657#comment-13305657 ] Tomas Remes commented on CDI-449: --------------------------------- PR sent https://github.com/cdi-spec/cdi/pull/311 > beans.xml examples are not valid > -------------------------------- > > Key: CDI-449 > URL: https://issues.jboss.org/browse/CDI-449 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > The {{beans.xml}} examples in "5.1.1. Declaring selected alternatives", "8.2.2. Decorator enablement and ordering for a bean archive" and "9.4. Interceptor enablement and ordering" (which contain a reference to beans_1_1.xsd) are not valid - {{bean-discovery-mode}} attribute is required. I think it would be appropriate to specify the version attribute as well. > The last {{beans.xml}} example in "12.4.2. Exclude filters" does not even define the reference to an XSD. Again, I believe the version and bean-discovery-mode attributes should be specified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From john.ament at spartasystems.com Tue Oct 11 12:01:46 2016 From: john.ament at spartasystems.com (John Ament) Date: Tue, 11 Oct 2016 16:01:46 +0000 Subject: [cdi-dev] Today's meeting on Hangout In-Reply-To: References: Message-ID: It says "waiting to join the call..." John ________________________________ From: cdi-dev-bounces at lists.jboss.org on behalf of Antoine Sabot-Durand Sent: Tuesday, October 11, 2016 10:02 AM To: cdi-dev Subject: [cdi-dev] Today's meeting on Hangout Hi all, Just to remind you that today's meeting will be on Hangout: https://hangouts.google.com/hangouts/_/sabot-durand.net/antoine We'll discuss mainly about CDI-578 (use cases for transactional observer) and CDI-625 (introduction of BeforeDestroyed and AfterDestroyed qualifiers) Antoine ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161011/f2f4e89b/attachment.html From issues at jboss.org Tue Oct 11 12:18:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 11 Oct 2016 12:18:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305692#comment-13305692 ] Antoine Sabot-Durand commented on CDI-625: ------------------------------------------ During EG meeting, decision was taken to introduce {{@BeforeDestroyed}} and keep {{@Destroyed}} to qualify event after the destruction of the context. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 .Final > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 15:29:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Tue, 11 Oct 2016 15:29:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-616) Injection point declared as transient is not useful In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305749#comment-13305749 ] Stephan Knitelius commented on CDI-616: --------------------------------------- Sadly Alea iacta est ("The die is cast") on this matter. I do agree that "normally" it is the developers responsibility to reinitialize any transient fields. However in the context of DI I always hear other devs speculating whether or not transient fields are "reinjected" post deserialization. So clarifying this matter is the least we should be doing. > Injection point declared as transient is not useful > --------------------------------------------------- > > Key: CDI-616 > URL: https://issues.jboss.org/browse/CDI-616 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > Priority: Minor > Fix For: 2.0 .Final > > > An injection point declared as 'transient' is not useful, due to the fact of after bean's passivation, the transient field will not be reinjected and its value will be lost. This causes confusion. See Weld forum discussion [link title|https://developer.jboss.org/thread/179486]. In the section 5.5.7, how about to make the following changes? > The isTransient() method returns true if the injection point is a transient field, and > false otherwise. If the injection point represents a dynamically obtained instance then the > isTransient() method returns true if the Instance injection point is a transient field, and > false otherwise. > => > The isTransient() method returns true if the injection point is a transient field, and > false otherwise. If the injection point represents a dynamically obtained instance then the > isTransient() method returns true if the Instance injection point is a transient field, and > false otherwise. If this injection point is declared as transient, after bean's passivation, the value will not be restored. Instance injection point is the preferred approach. > Any other better suggestions? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 16:10:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Tue, 11 Oct 2016 16:10:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305765#comment-13305765 ] Stephan Knitelius commented on CDI-45: -------------------------------------- How about we implement this by allowing Java 8 Optional? {code} @Inject private Optional myBean; {code} > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Priority: Optional > Fix For: TBD > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 16:13:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Tue, 11 Oct 2016 16:13:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305765#comment-13305765 ] Stephan Knitelius edited comment on CDI-45 at 10/11/16 4:12 PM: ---------------------------------------------------------------- How about we implement this by allowing Java 8 Optional? {code} @Inject private Optional myBean; {code} Would also be a nice Java 8 alignment. was (Author: sknitelius): How about we implement this by allowing Java 8 Optional? {code} @Inject private Optional myBean; {code} > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Priority: Optional > Fix For: TBD > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 16:24:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 11 Oct 2016 16:24:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305771#comment-13305771 ] Martin Kouba commented on CDI-45: --------------------------------- [~sknitelius] What's wrong with {{Instance}}? We're going to introduce {{Instance.isResolvable()}} within CDI-589. > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Priority: Optional > Fix For: TBD > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 16:29:01 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 11 Oct 2016 16:29:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305772#comment-13305772 ] John Ament commented on CDI-45: ------------------------------- [~mkouba] I think the implication is that we want some of the features of {{Optional}}. For example {code} MyBean bean = instance.select(MyBean.class).orElseThrow(() -> SomeException.class); MyBean bean = instance.select(MyBean.class).orElse(someAlternate); //or supply instance.select(MyBean.class).ifPresent(() -> someWork); {code} > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Priority: Optional > Fix For: TBD > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 16:45:03 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 11 Oct 2016 16:45:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305780#comment-13305780 ] Martin Kouba commented on CDI-45: --------------------------------- I see. We can extend {{Instance}} functionality then. Something like {{Instance.getOptional()}}? The default impl could be: {code:java} default Optional getOptional() { if (isResolvable()) { return java.util.Optional.of(get()); } return java.util.Optional.EMPTY; } {code} > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Priority: Optional > Fix For: TBD > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 16:50:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 11 Oct 2016 16:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305781#comment-13305781 ] John Ament commented on CDI-45: ------------------------------- I really like the idea of {{@Inject Optional}}. I may try to prototype a CDI extension that does it. > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Priority: Optional > Fix For: TBD > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 17:21:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 11 Oct 2016 17:21:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305785#comment-13305785 ] Martin Kouba commented on CDI-45: --------------------------------- Note that {{Optional}} is not {{Serializable}} and is defined final. So there will be problems with injecting into beans with passivating scope (e.g. {{@SessionScoped}}). > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Priority: Optional > Fix For: TBD > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 18:38:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 11 Oct 2016 18:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305798#comment-13305798 ] John Ament commented on CDI-45: ------------------------------- Underestood. The way I see it, for each Bean of type {{}} there exists a Bean of type {{Optional}} that shares the same qualifiers but has scope dependent. Optional beans can't be looked up programmatically. Another way to do this is to add all methods from https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html to Instance, which would be: * ifPresent * isPresent * orElse * orElseGet * orElseThrow So hm. > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Priority: Optional > Fix For: TBD > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 12 02:11:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 12 Oct 2016 02:11:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305826#comment-13305826 ] Martin Kouba commented on CDI-45: --------------------------------- -1 for adding those methods on {{Instance}} and -1 for introducing {{Optional}} built-in bean (mainly due to serialization issues and the need for special handling, e.g. disallow programatic lookup). {{Instance.getOptional().ifPresent(...)}} etc. is imho easier to understand. > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Priority: Optional > Fix For: TBD > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 12 02:29:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 12 Oct 2016 02:29:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-489) NonexistentConversationException thrown at restore view or not? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305828#comment-13305828 ] Tomas Remes commented on CDI-489: --------------------------------- PR sent: https://github.com/cdi-spec/cdi/pull/312 > NonexistentConversationException thrown at restore view or not? > --------------------------------------------------------------- > > Key: CDI-489 > URL: https://issues.jboss.org/browse/CDI-489 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 1.2.Final > Reporter: Vsevolod Golovanov > Fix For: 2.0 .Final > > > The 1.0 spec says in 6.7.4: > {quote}If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and throw an exception of type javax.enterprise.context.NonexistentConversationException from the restore > view phase of the JSF lifecycle. The application may handle this exception using the JSF ExceptionHandler.{quote} > 1.1 and 1.2 just say: > {quote} > If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and > throw an exception of type javax.enterprise.context.NonexistentConversationException. > {quote} > Yet the javadoc of NonexistentConversationException for both 1.1 and 1.2 says: > {quote} > If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and throw an exception of type NonexistentConversationException from the restore view phase of the JSF lifecycle. > {quote} > So is it supposed to be thrown from restore view or not? I assume not. Probably javadoc should be amended. > I'm curious about reasoning behind the change. I tried searching for an explanation but didn't find anything. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 12 03:19:01 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 12 Oct 2016 03:19:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305841#comment-13305841 ] Matej Novotny commented on CDI-45: ---------------------------------- -1 for {{Optional}} built-in bean, the limitations of that approach and the confusion caused (Optional vs Instance) are just not worth the few methods. Adding all methods onto {{Instance}} just feels dirty; -10. Personally I think explicitly supporting {{Optional}} isn't really worth it. But if we want to go that way anyway, I'd be +1 for adding {{Instance.getOptional}}. > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Priority: Optional > Fix For: TBD > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Wed Oct 12 04:43:05 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 12 Oct 2016 08:43:05 +0000 Subject: [cdi-dev] Moving on SERVLET_SPEC-116 (giving servlet beans to servlet spec) In-Reply-To: References: <22525.1203.450029.269620@gargle.gargle.HOWL> Message-ID: Hi All, Ed burns (in cc) contacted me yesterday to follow our brief encounter at Java One to re-open SERVLET_SPEC-116 (CDI-492 on our side). As you can see in the discussion below, I gave some leads to solve their issues and suggested that we help them to work on them. Perhaps we could start by setting up an online meeting with all interested person on both EG? Antoine ---------- Forwarded message ---------- From: *Antoine Sabot-Durand* Date: Wed, Oct 12, 2016 at 10:22 AM Subject: Re: [SERVLET_SPEC-116-CDIRelatedBeansInServletSpec][CDI-492-FobStuffToServlet] Revitalization attempt To: Edward Burns Cc: Shing Wai Chan Hi Ed, Glad to ear that. as you can check on our side [1] we are ready to help you solve these point Solutions are reachable: For the backward compatibility issue raised by Stuart: As I already said, the backward compatibility could be solved by either a qualifier or by adding to CDI an easy way to detect its version and decide of the bean creation on servlet side according to it. For the portable implementation issue: I don't understand what is the problem here. CDI provide a powerful SPI that allows development of portable extensions. Unless I miss something, I see no reason why this code shouldn't be developed at the spec level and so being portable. BTW we are of course ready to help you right this code. For the class loading issue: 2 solutions here: - accept to have an inactive class in your implementation (a CDI portable extension) linked to a missing library (cdi-api). As it will never be called no error should be raised - do like JAX-RS by creating a specific jar for CDI support in your implementation. The jar would be included in Java EE and not in Servlet only server That's only from my understanding and knowledge of the problem, if we go to a discussion with all CDI EG, we may find even more better solutions. I suggest that start a workgroup including member of the EG on both side to work on this issues resolution Wdyt? Antoine [1] http://cdi-development-mailing-list.1064426.n5.nabble.com/Which-version-of-HttpServletRequest-is-injected-td5713578.html#a5713688 On Tue, Oct 11, 2016 at 5:26 PM, Edward Burns wrote: Hello Antoine, When I briefly bumped into you at JavaOne, you expressed a desire to revisit this issue. Since we didn't make time to meet at JavaOne, I am following up over email. Way back at the beginning of Servlet 4.0, I attempted to get this one resolved. We filed two JIRAS, as in the subject, and had some discussion [1] [2]. We ended up resolving SERVLET_SPEC_116 as WORKS_AS_DESIGNED for this reason, the "classloader and backward compatibility concern": >>>>> On Wed, 19 Nov 2014 15:55:43 -0500 (EST), Stuart Douglas < sdouglas at redhat.com> said: SD> Say I have an application that packages Weld (or OWB) that I have SD> deployed on a Servlet 3.1 container, and I now want to move it to a SD> Servlet 4.0 container. The older version of Weld will still provide SD> the HttpServletRequest beans (as it is required to do by spec) and SD> the servlet container will also provide these beans (as we are SD> required to do by spec) and as a result if you try and inject them SD> you will get a bean resolution error as two beans resolve to the SD> injection point. >>>>> On Fri, 21 Nov 2014 14:06:24 +1100, Greg Wilkins said: GW> While initially I thought that the words "when running in an GW> environment that also supports CDI..." would be sufficient to make GW> this OK, I'm now doubting that. I share Stuarts concerns about GW> classloading confusion. >>>>> On Fri, 21 Nov 2014 07:03:33 -0800, Edward Burns < edward.burns at oracle.com> said: EB> Ajran, while your observations are accurate, the backward EB> compatibility issues raised by Stuart and seconded by Greg are EB> showstoppers for this change in my opinion at this point. There was an additional concern, the "portable implementation concern": it is not possible to provide portable implementations of the code necessary to implement the new requirements that would be in the Servlet spec, taken from CDI section 3.8: CDI3.8> A servlet container must provide the following built-in CDI3.8> beans, all of which have qualifier @Default: CDI3.8> a bean with bean type javax.servlet.http.HttpServletRequest, CDI3.8> allowing injection of a reference to the HttpServletRequest CDI3.8> a bean with bean type javax.servlet.http.HttpSession, CDI3.8> allowing injection of a reference to the HttpSession, CDI3.8> a bean with bean type javax.servlet.ServletContext, allowing CDI3.8> injection of a reference to the ServletContext, CDI3.8> These beans are passivation capable dependencies, as defined CDI3.8> in Passivation capable dependencies. In my understanding, the portable implementation concern has been adequately addressed by API in CDI 2.0. Is that correct? Do you have any suggestion for how to address the classloader and backward compatibility concern? Thanks, Ed -- | edward.burns at oracle.com | office: +1 407 458 0017 [1] https://java.net/projects/servlet-spec/lists/jsr369-experts/archive/2014-11/message/1 [2] https://java.net/projects/servlet-spec/lists/users/archive/2014-11/message/26 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161012/b71d71fc/attachment-0001.html From issues at jboss.org Wed Oct 12 05:09:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 12 Oct 2016 05:09:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-637) Rename builder package to configurator In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-637: ---------------------------------------- Summary: Rename builder package to configurator Key: CDI-637 URL: https://issues.jboss.org/browse/CDI-637 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 2.0-EDR2 Reporter: Antoine Sabot-Durand Since it contains only confgurators, package {{javax.enterprise.inject.spi.builder}} should be renamed {{javax.enterprise.inject.spi.configurator}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 12 05:09:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 12 Oct 2016 05:09:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-637) Rename builder package to configurator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-637: ------------------------------------- Fix Version/s: 2.0 .Final > Rename builder package to configurator > --------------------------------------- > > Key: CDI-637 > URL: https://issues.jboss.org/browse/CDI-637 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0-EDR2 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Since it contains only confgurators, package {{javax.enterprise.inject.spi.builder}} should be renamed {{javax.enterprise.inject.spi.configurator}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Wed Oct 12 05:18:59 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 12 Oct 2016 09:18:59 +0000 Subject: [cdi-dev] Spliting SE package in an independent jar Message-ID: to avoid including CDI SE features in Java EE, we already talk about creating a specific SE jar. Any thought on this approach? Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161012/ae1606a0/attachment.html From werner.keil at gmail.com Wed Oct 12 05:41:07 2016 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 12 Oct 2016 11:41:07 +0200 Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points Message-ID: In the Java SE 8 specific JSR 363 implementation Otavio and I tried to use Optional, but see the comments in https://github.com/unitsofmeasurement/uom-se/blob/master/src/main/java/tec/uom/se/spi/Range.java it caused problems with the type-safe Quantity mechanism. Can't recall the exact details, but there must have been a conflict when using another generic type like Quantity or similar as of Optional. If the of Bean and Optional were exactly the same it might work, but if types with their own generic elements (Collection, Map or a combination of several with different or nested generics) are used, Optional seems to have some problems and limitations. So trying to add these methods could be safer based on my experience with Optional. Werner On Wed, Oct 12, 2016 at 10:43 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. [JBoss JIRA] (CDI-45) Optional Injection Points > (John Ament (JIRA)) > 2. [JBoss JIRA] (CDI-45) Optional Injection Points > (Martin Kouba (JIRA)) > 3. [JBoss JIRA] (CDI-45) Optional Injection Points > (John Ament (JIRA)) > 4. [JBoss JIRA] (CDI-45) Optional Injection Points > (Martin Kouba (JIRA)) > 5. [JBoss JIRA] (CDI-489) NonexistentConversationException > thrown at restore view or not? (Tomas Remes (JIRA)) > 6. [JBoss JIRA] (CDI-45) Optional Injection Points > (Matej Novotny (JIRA)) > 7. Moving on SERVLET_SPEC-116 (giving servlet beans to servlet > spec) (Antoine Sabot-Durand) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 11 Oct 2016 16:50:00 -0400 (EDT) > From: "John Ament (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ https://issues.jboss.org/browse/CDI-45?page=com. > atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel&focusedCommentId=13305781#comment-13305781 ] > > John Ament commented on CDI-45: > ------------------------------- > > I really like the idea of {{@Inject Optional}}. I may try to prototype > a CDI extension that does it. > > > Optional Injection Points > > ------------------------- > > > > Key: CDI-45 > > URL: https://issues.jboss.org/browse/CDI-45 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Components: Resolution > > Affects Versions: 1.0 > > Reporter: Stuart Douglas > > Priority: Optional > > Fix For: TBD > > > > > > There are occoasions where it may be useful for some injection points to > be optional, e.g. > > @Inject > > @Optional > > MyBean bean; > > This would behave the same as a normal injection point, however it will > not cause the deployment to fail if it is not satisified. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 2 > Date: Tue, 11 Oct 2016 17:21:00 -0400 (EDT) > From: "Martin Kouba (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ https://issues.jboss.org/browse/CDI-45?page=com. > atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel&focusedCommentId=13305785#comment-13305785 ] > > Martin Kouba commented on CDI-45: > --------------------------------- > > Note that {{Optional}} is not {{Serializable}} and is defined final. So > there will be problems with injecting into beans with passivating scope > (e.g. {{@SessionScoped}}). > > > Optional Injection Points > > ------------------------- > > > > Key: CDI-45 > > URL: https://issues.jboss.org/browse/CDI-45 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Components: Resolution > > Affects Versions: 1.0 > > Reporter: Stuart Douglas > > Priority: Optional > > Fix For: TBD > > > > > > There are occoasions where it may be useful for some injection points to > be optional, e.g. > > @Inject > > @Optional > > MyBean bean; > > This would behave the same as a normal injection point, however it will > not cause the deployment to fail if it is not satisified. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 3 > Date: Tue, 11 Oct 2016 18:38:00 -0400 (EDT) > From: "John Ament (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ https://issues.jboss.org/browse/CDI-45?page=com. > atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel&focusedCommentId=13305798#comment-13305798 ] > > John Ament commented on CDI-45: > ------------------------------- > > Underestood. The way I see it, for each Bean of type {{}} there exists > a Bean of type {{Optional}} that shares the same qualifiers but has > scope dependent. Optional beans can't be looked up programmatically. > > Another way to do this is to add all methods from https://docs.oracle.com/ > javase/8/docs/api/java/util/Optional.html to Instance, which would be: > > * ifPresent > * isPresent > * orElse > * orElseGet > * orElseThrow > > So hm. > > > Optional Injection Points > > ------------------------- > > > > Key: CDI-45 > > URL: https://issues.jboss.org/browse/CDI-45 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Components: Resolution > > Affects Versions: 1.0 > > Reporter: Stuart Douglas > > Priority: Optional > > Fix For: TBD > > > > > > There are occoasions where it may be useful for some injection points to > be optional, e.g. > > @Inject > > @Optional > > MyBean bean; > > This would behave the same as a normal injection point, however it will > not cause the deployment to fail if it is not satisified. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 4 > Date: Wed, 12 Oct 2016 02:11:01 -0400 (EDT) > From: "Martin Kouba (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ https://issues.jboss.org/browse/CDI-45?page=com. > atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel&focusedCommentId=13305826#comment-13305826 ] > > Martin Kouba commented on CDI-45: > --------------------------------- > > -1 for adding those methods on {{Instance}} and -1 for introducing > {{Optional}} built-in bean (mainly due to serialization issues and the need > for special handling, e.g. disallow programatic lookup). > {{Instance.getOptional().ifPresent(...)}} etc. is imho easier to > understand. > > > Optional Injection Points > > ------------------------- > > > > Key: CDI-45 > > URL: https://issues.jboss.org/browse/CDI-45 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Components: Resolution > > Affects Versions: 1.0 > > Reporter: Stuart Douglas > > Priority: Optional > > Fix For: TBD > > > > > > There are occoasions where it may be useful for some injection points to > be optional, e.g. > > @Inject > > @Optional > > MyBean bean; > > This would behave the same as a normal injection point, however it will > not cause the deployment to fail if it is not satisified. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > _______________________________________________ > 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 71, Issue 25 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161012/8b1dda14/attachment-0001.html From issues at jboss.org Wed Oct 12 06:39:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Wed, 12 Oct 2016 06:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305973#comment-13305973 ] John Ament commented on CDI-45: ------------------------------- I'm -1 for adding a method named {{getOptional}} but might be +0.5 on methods like {{optional()}} or {{asOptional()}} since from a callers point of view It would be more ideal if the {{Instance}} object dealt with missing beans better, which is really what this ticket should cover. I think I'm strongly +1 on adding at least an {{isPresent()}} (the opposite of {{isUnresolved()}} effectively being a positive check rather than those negative checks) and an {{ifPresent(Consumer)}} method. > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Priority: Optional > Fix For: TBD > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 12 06:39:01 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Wed, 12 Oct 2016 06:39:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305973#comment-13305973 ] John Ament edited comment on CDI-45 at 10/12/16 6:38 AM: --------------------------------------------------------- I'm -1 for adding a method named {{getOptional}} but might be +0.5 on methods like {{optional()}} or {{asOptional()}} since from a callers point of view the chained method calls don't necessarily create new objects. It would be more ideal if the {{Instance}} object dealt with missing beans better, which is really what this ticket should cover. I think I'm strongly +1 on adding at least an {{isPresent()}} (the opposite of {{isUnresolved()}} effectively being a positive check rather than those negative checks) and an {{ifPresent(Consumer)}} method. was (Author: meetoblivion): I'm -1 for adding a method named {{getOptional}} but might be +0.5 on methods like {{optional()}} or {{asOptional()}} since from a callers point of view It would be more ideal if the {{Instance}} object dealt with missing beans better, which is really what this ticket should cover. I think I'm strongly +1 on adding at least an {{isPresent()}} (the opposite of {{isUnresolved()}} effectively being a positive check rather than those negative checks) and an {{ifPresent(Consumer)}} method. > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Priority: Optional > Fix For: TBD > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From john.ament at spartasystems.com Wed Oct 12 06:40:40 2016 From: john.ament at spartasystems.com (John Ament) Date: Wed, 12 Oct 2016 10:40:40 +0000 Subject: [cdi-dev] Spliting SE package in an independent jar In-Reply-To: References: Message-ID: the way I've envisioned it: - There is no dedicated EE API (none that I could find that is EE only, except for perhaps session scoped) - There is SE specific API and the current API could be considered "core" Take the current API module and create two submodules, one for core and one for SE. SE depends on core. EE still refers to core as the same existing coordinates (create new coordinates for the parent). ________________________________ From: cdi-dev-bounces at lists.jboss.org on behalf of Antoine Sabot-Durand Sent: Wednesday, October 12, 2016 5:18 AM To: cdi-dev Subject: [cdi-dev] Spliting SE package in an independent jar to avoid including CDI SE features in Java EE, we already talk about creating a specific SE jar. Any thought on this approach? Antoine ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161012/9cb13c4e/attachment.html From issues at jboss.org Wed Oct 12 06:46:01 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Wed, 12 Oct 2016 06:46:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament updated CDI-420: --------------------------- Issue Type: Feature Request (was: Bug) > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.2.Final, 1.1.Final > Reporter: Mark Struberg > Labels: F2F2016 > Fix For: 2.0 .Final > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 12 06:46:02 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Wed, 12 Oct 2016 06:46:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament updated CDI-420: --------------------------- Affects Version/s: 1.1.Final 1.2.Final (was: TBD) > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.2.Final, 1.1.Final > Reporter: Mark Struberg > Labels: F2F2016 > Fix For: 2.0 .Final > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 12 06:47:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Wed, 12 Oct 2016 06:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament reassigned CDI-490: ------------------------------ Assignee: John Ament > Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml > ------------------------------------------------------------------------------------------------ > > Key: CDI-490 > URL: https://issues.jboss.org/browse/CDI-490 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators, Interceptors > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Assignee: John Ament > Labels: F2F2016 > Fix For: 2.0 .Final > > > Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because: > {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final > list of interceptors for the application, as defined in Section 11.5.2, ?AfterTypeDiscovery event?.{quote} > it matches both parts of the statement. > As for ordering, the following statement defines invocation order: > {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote} > Since InterceptorA is enabled by both @Priority and beans.xml, the following applies: > "Interceptors enabled using @Priority" = \{ InterceptorA \} > "interceptors enabled using beans.xml" = \{ InterceptorA \} > We can perform substitution in the statement and we get: > *\{ InterceptorA \} are called before \{ InterceptorA \}* > which does not seem right. > The specification should explicitly address this scenario. There are several options (some of them are better, some are worse): > 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml > 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence) > 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence) > 4) Forbid an interceptor to be enabled by both @Priority and beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 12 06:50:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Wed, 12 Oct 2016 06:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305979#comment-13305979 ] John Ament commented on CDI-490: -------------------------------- [~mkouba] we can add a warning indicating the ordering was not deterministic in CDI 1.1/1.2, (CDI 1.0 wouldn't be relevant since you can only activate via {{beans.xml}}) and that it is becoming deterministic in CDI 2.0. > Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml > ------------------------------------------------------------------------------------------------ > > Key: CDI-490 > URL: https://issues.jboss.org/browse/CDI-490 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators, Interceptors > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Assignee: John Ament > Labels: F2F2016 > Fix For: 2.0 .Final > > > Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because: > {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final > list of interceptors for the application, as defined in Section 11.5.2, ?AfterTypeDiscovery event?.{quote} > it matches both parts of the statement. > As for ordering, the following statement defines invocation order: > {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote} > Since InterceptorA is enabled by both @Priority and beans.xml, the following applies: > "Interceptors enabled using @Priority" = \{ InterceptorA \} > "interceptors enabled using beans.xml" = \{ InterceptorA \} > We can perform substitution in the statement and we get: > *\{ InterceptorA \} are called before \{ InterceptorA \}* > which does not seem right. > The specification should explicitly address this scenario. There are several options (some of them are better, some are worse): > 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml > 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence) > 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence) > 4) Forbid an interceptor to be enabled by both @Priority and beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026) From john.ament at spartasystems.com Wed Oct 12 06:53:29 2016 From: john.ament at spartasystems.com (John Ament) Date: Wed, 12 Oct 2016 10:53:29 +0000 Subject: [cdi-dev] Moving on SERVLET_SPEC-116 (giving servlet beans to servlet spec) In-Reply-To: References: <22525.1203.450029.269620@gargle.gargle.HOWL> , Message-ID: Antoine, Definitely a good idea. I also reached out to Ed/Servlet EG recently about CDI-452. If we can schedule this meeting, I'd like to include 452 on the topic to make sure there's no crossed wires (I haven't read the full response yet, but I suspect there will still be questions). John ________________________________ From: cdi-dev-bounces at lists.jboss.org on behalf of Antoine Sabot-Durand Sent: Wednesday, October 12, 2016 4:43 AM To: cdi-dev Cc: edward.burns at oracle.com Subject: [cdi-dev] Moving on SERVLET_SPEC-116 (giving servlet beans to servlet spec) Hi All, Ed burns (in cc) contacted me yesterday to follow our brief encounter at Java One to re-open SERVLET_SPEC-116 (CDI-492 on our side). As you can see in the discussion below, I gave some leads to solve their issues and suggested that we help them to work on them. Perhaps we could start by setting up an online meeting with all interested person on both EG? Antoine ---------- Forwarded message ---------- From: Antoine Sabot-Durand > Date: Wed, Oct 12, 2016 at 10:22 AM Subject: Re: [SERVLET_SPEC-116-CDIRelatedBeansInServletSpec][CDI-492-FobStuffToServlet] Revitalization attempt To: Edward Burns > Cc: Shing Wai Chan > Hi Ed, Glad to ear that. as you can check on our side [1] we are ready to help you solve these point Solutions are reachable: For the backward compatibility issue raised by Stuart: As I already said, the backward compatibility could be solved by either a qualifier or by adding to CDI an easy way to detect its version and decide of the bean creation on servlet side according to it. For the portable implementation issue: I don't understand what is the problem here. CDI provide a powerful SPI that allows development of portable extensions. Unless I miss something, I see no reason why this code shouldn't be developed at the spec level and so being portable. BTW we are of course ready to help you right this code. For the class loading issue: 2 solutions here: - accept to have an inactive class in your implementation (a CDI portable extension) linked to a missing library (cdi-api). As it will never be called no error should be raised - do like JAX-RS by creating a specific jar for CDI support in your implementation. The jar would be included in Java EE and not in Servlet only server That's only from my understanding and knowledge of the problem, if we go to a discussion with all CDI EG, we may find even more better solutions. I suggest that start a workgroup including member of the EG on both side to work on this issues resolution Wdyt? Antoine [1] http://cdi-development-mailing-list.1064426.n5.nabble.com/Which-version-of-HttpServletRequest-is-injected-td5713578.html#a5713688 On Tue, Oct 11, 2016 at 5:26 PM, Edward Burns > wrote: Hello Antoine, When I briefly bumped into you at JavaOne, you expressed a desire to revisit this issue. Since we didn't make time to meet at JavaOne, I am following up over email. Way back at the beginning of Servlet 4.0, I attempted to get this one resolved. We filed two JIRAS, as in the subject, and had some discussion [1] [2]. We ended up resolving SERVLET_SPEC_116 as WORKS_AS_DESIGNED for this reason, the "classloader and backward compatibility concern": >>>>> On Wed, 19 Nov 2014 15:55:43 -0500 (EST), Stuart Douglas > said: SD> Say I have an application that packages Weld (or OWB) that I have SD> deployed on a Servlet 3.1 container, and I now want to move it to a SD> Servlet 4.0 container. The older version of Weld will still provide SD> the HttpServletRequest beans (as it is required to do by spec) and SD> the servlet container will also provide these beans (as we are SD> required to do by spec) and as a result if you try and inject them SD> you will get a bean resolution error as two beans resolve to the SD> injection point. >>>>> On Fri, 21 Nov 2014 14:06:24 +1100, Greg Wilkins > said: GW> While initially I thought that the words "when running in an GW> environment that also supports CDI..." would be sufficient to make GW> this OK, I'm now doubting that. I share Stuarts concerns about GW> classloading confusion. >>>>> On Fri, 21 Nov 2014 07:03:33 -0800, Edward Burns > said: EB> Ajran, while your observations are accurate, the backward EB> compatibility issues raised by Stuart and seconded by Greg are EB> showstoppers for this change in my opinion at this point. There was an additional concern, the "portable implementation concern": it is not possible to provide portable implementations of the code necessary to implement the new requirements that would be in the Servlet spec, taken from CDI section 3.8: CDI3.8> A servlet container must provide the following built-in CDI3.8> beans, all of which have qualifier @Default: CDI3.8> a bean with bean type javax.servlet.http.HttpServletRequest, CDI3.8> allowing injection of a reference to the HttpServletRequest CDI3.8> a bean with bean type javax.servlet.http.HttpSession, CDI3.8> allowing injection of a reference to the HttpSession, CDI3.8> a bean with bean type javax.servlet.ServletContext, allowing CDI3.8> injection of a reference to the ServletContext, CDI3.8> These beans are passivation capable dependencies, as defined CDI3.8> in Passivation capable dependencies. In my understanding, the portable implementation concern has been adequately addressed by API in CDI 2.0. Is that correct? Do you have any suggestion for how to address the classloader and backward compatibility concern? Thanks, Ed -- | edward.burns at oracle.com | office: +1 407 458 0017 [1] https://java.net/projects/servlet-spec/lists/jsr369-experts/archive/2014-11/message/1 [2] https://java.net/projects/servlet-spec/lists/users/archive/2014-11/message/26 ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161012/7f9e9876/attachment.html From issues at jboss.org Thu Oct 13 03:54:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 13 Oct 2016 03:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306436#comment-13306436 ] Martin Kouba commented on CDI-490: ---------------------------------- [~meetoblivion] Yes, that's a good idea. My original point was that an app may behave differently depending on the target CDI runtime, i.e. an interceptor with {{@Priority}} might be also used in CDI 1.0 (the priority would be just ignored). But it's probably a very rare use case. > Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml > ------------------------------------------------------------------------------------------------ > > Key: CDI-490 > URL: https://issues.jboss.org/browse/CDI-490 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators, Interceptors > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Assignee: John Ament > Labels: F2F2016 > Fix For: 2.0 .Final > > > Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because: > {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final > list of interceptors for the application, as defined in Section 11.5.2, ?AfterTypeDiscovery event?.{quote} > it matches both parts of the statement. > As for ordering, the following statement defines invocation order: > {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote} > Since InterceptorA is enabled by both @Priority and beans.xml, the following applies: > "Interceptors enabled using @Priority" = \{ InterceptorA \} > "interceptors enabled using beans.xml" = \{ InterceptorA \} > We can perform substitution in the statement and we get: > *\{ InterceptorA \} are called before \{ InterceptorA \}* > which does not seem right. > The specification should explicitly address this scenario. There are several options (some of them are better, some are worse): > 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml > 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence) > 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence) > 4) Forbid an interceptor to be enabled by both @Priority and beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Thu Oct 13 03:56:24 2016 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 13 Oct 2016 09:56:24 +0200 Subject: [cdi-dev] Spliting SE package in an independent jar In-Reply-To: References: Message-ID: <616fdc4e-26f6-a8d7-16d3-fdceb71faa1f@redhat.com> +1 for John's proposal. So there will be two API artifacts: * cdi-api * cdi-se-api (depends on cdi-api) Martin Dne 12.10.2016 v 12:40 John Ament napsal(a): > the way I've envisioned it: > > > - There is no dedicated EE API (none that I could find that is EE only, > except for perhaps session scoped)t > > - There is SE specific API and the current API could be considered "core" > > > > Take the current API module and create two submodules, one for core and > one for SE. SE depends on core. EE still refers to core as the same > existing coordinates (create new coordinates for the parent). > > ------------------------------------------------------------------------ > *From:* cdi-dev-bounces at lists.jboss.org > on behalf of Antoine Sabot-Durand > > *Sent:* Wednesday, October 12, 2016 5:18 AM > *To:* cdi-dev > *Subject:* [cdi-dev] Spliting SE package in an independent jar > > to avoid including CDI SE features in Java EE, we already talk about > creating a specific SE jar. > > Any thought on this approach? > > Antoine > ------------------------------------------------------------------------ > NOTICE: This e-mail message and any attachments may contain > confidential, proprietary, and/or privileged information which should be > treated accordingly. If you are not the intended recipient, please > notify the sender immediately by return e-mail, delete this message, and > destroy all physical and electronic copies. Thank you. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From issues at jboss.org Thu Oct 13 04:12:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 13 Oct 2016 04:12:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306451#comment-13306451 ] Martin Kouba commented on CDI-45: --------------------------------- [~meetoblivion] On F2F we decided to add {{isResolvable()}} (is satisfied and not ambiguous), it's already part of the [Weld API|https://github.com/weld/api/blob/2.4/weld/src/main/java/org/jboss/weld/inject/WeldInstance.java#L53]... I suppose this is basically what {{isPresent()}} does. Do you find the name acceptable? Also I quite like {{asOptional()}}. > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Priority: Optional > Fix For: TBD > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 17 09:59:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 17 Oct 2016 09:59:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0 In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-638: ---------------------------------------- Summary: Introduce a new xsd for CDI 2.0 Key: CDI-638 URL: https://issues.jboss.org/browse/CDI-638 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Antoine Sabot-Durand CDI-420 made us to introduce the {{}} attribute to {{beans.xml}}, so we need to introduce a new grammar ({{beans_2_0.xsd}})for CDI 2.0. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 17 10:01:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 17 Oct 2016 10:01:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-638: ------------------------------------- Fix Version/s: 2.0 .Final > Introduce a new xsd for CDI 2.0 > ------------------------------- > > Key: CDI-638 > URL: https://issues.jboss.org/browse/CDI-638 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > CDI-420 made us to introduce the {{}} attribute to {{beans.xml}}, so we need to introduce a new grammar ({{beans_2_0.xsd}})for CDI 2.0. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Mon Oct 17 10:16:11 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 17 Oct 2016 14:16:11 +0000 Subject: [cdi-dev] No meeting tomorrow Message-ID: Hi all, I'll be on PTO tomorrow, so no meeting, yet, we have a lot of PR open to review, so if you have time, please go thru them and give feedback or +1 if you're ok for the addition, it will help us go forward. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161017/793bb094/attachment.html From EMIJIANG at uk.ibm.com Tue Oct 18 05:09:29 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Tue, 18 Oct 2016 10:09:29 +0100 Subject: [cdi-dev] Spliting SE package in an independent jar In-Reply-To: <616fdc4e-26f6-a8d7-16d3-fdceb71faa1f@redhat.com> References: <616fdc4e-26f6-a8d7-16d3-fdceb71faa1f@redhat.com> Message-ID: +1 on John's proposal. +1 on splitting. 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: John Ament , Antoine Sabot-Durand , cdi-dev Date: 13/10/2016 08:57 Subject: Re: [cdi-dev] Spliting SE package in an independent jar Sent by: cdi-dev-bounces at lists.jboss.org +1 for John's proposal. So there will be two API artifacts: * cdi-api * cdi-se-api (depends on cdi-api) Martin Dne 12.10.2016 v 12:40 John Ament napsal(a): > the way I've envisioned it: > > > - There is no dedicated EE API (none that I could find that is EE only, > except for perhaps session scoped)t > > - There is SE specific API and the current API could be considered "core" > > > > Take the current API module and create two submodules, one for core and > one for SE. SE depends on core. EE still refers to core as the same > existing coordinates (create new coordinates for the parent). > > ------------------------------------------------------------------------ > *From:* cdi-dev-bounces at lists.jboss.org > on behalf of Antoine Sabot-Durand > > *Sent:* Wednesday, October 12, 2016 5:18 AM > *To:* cdi-dev > *Subject:* [cdi-dev] Spliting SE package in an independent jar > > to avoid including CDI SE features in Java EE, we already talk about > creating a specific SE jar. > > Any thought on this approach? > > Antoine > ------------------------------------------------------------------------ > NOTICE: This e-mail message and any attachments may contain > confidential, proprietary, and/or privileged information which should be > treated accordingly. If you are not the intended recipient, please > notify the sender immediately by return e-mail, delete this message, and > destroy all physical and electronic copies. Thank you. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba 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/20161018/0246016c/attachment-0001.html From werner.keil at gmail.com Tue Oct 18 05:27:20 2016 From: werner.keil at gmail.com (Werner Keil) Date: Tue, 18 Oct 2016 11:27:20 +0200 Subject: [cdi-dev] Spliting SE package in an independent jar Message-ID: So cdi-se-api is larger than the (core) EE API? An SE implementation should hopefully have a smaller footprint than current EE ones (e.g. Weld)? Werner On Tue, Oct 18, 2016 at 11:09 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. Re: Spliting SE package in an independent jar (Martin Kouba) > 2. [JBoss JIRA] (CDI-45) Optional Injection Points > (Martin Kouba (JIRA)) > 3. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0 > (Antoine Sabot-Durand (JIRA)) > 4. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0 > (Antoine Sabot-Durand (JIRA)) > 5. No meeting tomorrow (Antoine Sabot-Durand) > 6. Re: Spliting SE package in an independent jar (Emily Jiang) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 13 Oct 2016 09:56:24 +0200 > From: Martin Kouba > Subject: Re: [cdi-dev] Spliting SE package in an independent jar > To: John Ament , Antoine Sabot-Durand > , cdi-dev > Message-ID: <616fdc4e-26f6-a8d7-16d3-fdceb71faa1f at redhat.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > +1 for John's proposal. > > So there will be two API artifacts: > * cdi-api > * cdi-se-api (depends on cdi-api) > > Martin > > Dne 12.10.2016 v 12:40 John Ament napsal(a): > > the way I've envisioned it: > > > > > > - There is no dedicated EE API (none that I could find that is EE only, > > except for perhaps session scoped)t > > > > - There is SE specific API and the current API could be considered "core" > > > > > > > > Take the current API module and create two submodules, one for core and > > one for SE. SE depends on core. EE still refers to core as the same > > existing coordinates (create new coordinates for the parent). > > > > ------------------------------------------------------------------------ > > *From:* cdi-dev-bounces at lists.jboss.org > > on behalf of Antoine Sabot-Durand > > > > *Sent:* Wednesday, October 12, 2016 5:18 AM > > *To:* cdi-dev > > *Subject:* [cdi-dev] Spliting SE package in an independent jar > > > > to avoid including CDI SE features in Java EE, we already talk about > > creating a specific SE jar. > > > > Any thought on this approach? > > > > Antoine > > ------------------------------------------------------------------------ > > NOTICE: This e-mail message and any attachments may contain > > confidential, proprietary, and/or privileged information which should be > > treated accordingly. If you are not the intended recipient, please > > notify the sender immediately by return e-mail, delete this message, and > > destroy all physical and electronic copies. Thank you. > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 (http://www.apache.org/ > licenses/LICENSE-2.0.html). For all other ideas provided on this list, > the provider waives all patent and other intellectual property rights > inherent in such information. > > > > -- > Martin Kouba > 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 71, Issue 29 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161018/6c34a89d/attachment.html From john.ament at spartasystems.com Tue Oct 18 06:19:10 2016 From: john.ament at spartasystems.com (John Ament) Date: Tue, 18 Oct 2016 10:19:10 +0000 Subject: [cdi-dev] Spliting SE package in an independent jar In-Reply-To: References: Message-ID: Opposite Werner, EE API is larger and has the bulk of the content. SE API at this point has two classes. ________________________________ From: cdi-dev-bounces at lists.jboss.org on behalf of Werner Keil Sent: Tuesday, October 18, 2016 5:27 AM To: cdi-dev Subject: Re: [cdi-dev] Spliting SE package in an independent jar So cdi-se-api is larger than the (core) EE API? An SE implementation should hopefully have a smaller footprint than current EE ones (e.g. Weld)? Werner On Tue, Oct 18, 2016 at 11:09 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. Re: Spliting SE package in an independent jar (Martin Kouba) 2. [JBoss JIRA] (CDI-45) Optional Injection Points (Martin Kouba (JIRA)) 3. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0 (Antoine Sabot-Durand (JIRA)) 4. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0 (Antoine Sabot-Durand (JIRA)) 5. No meeting tomorrow (Antoine Sabot-Durand) 6. Re: Spliting SE package in an independent jar (Emily Jiang) ---------------------------------------------------------------------- Message: 1 Date: Thu, 13 Oct 2016 09:56:24 +0200 From: Martin Kouba > Subject: Re: [cdi-dev] Spliting SE package in an independent jar To: John Ament >, Antoine Sabot-Durand >, cdi-dev > Message-ID: <616fdc4e-26f6-a8d7-16d3-fdceb71faa1f at redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed +1 for John's proposal. So there will be two API artifacts: * cdi-api * cdi-se-api (depends on cdi-api) Martin Dne 12.10.2016 v 12:40 John Ament napsal(a): > the way I've envisioned it: > > > - There is no dedicated EE API (none that I could find that is EE only, > except for perhaps session scoped)t > > - There is SE specific API and the current API could be considered "core" > > > > Take the current API module and create two submodules, one for core and > one for SE. SE depends on core. EE still refers to core as the same > existing coordinates (create new coordinates for the parent). > > ------------------------------------------------------------------------ > *From:* cdi-dev-bounces at lists.jboss.org > > on behalf of Antoine Sabot-Durand > > > *Sent:* Wednesday, October 12, 2016 5:18 AM > *To:* cdi-dev > *Subject:* [cdi-dev] Spliting SE package in an independent jar > > to avoid including CDI SE features in Java EE, we already talk about > creating a specific SE jar. > > Any thought on this approach? > > Antoine > ------------------------------------------------------------------------ > NOTICE: This e-mail message and any attachments may contain > confidential, proprietary, and/or privileged information which should be > treated accordingly. If you are not the intended recipient, please > notify the sender immediately by return e-mail, delete this message, and > destroy all physical and electronic copies. Thank you. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba 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 71, Issue 29 *************************************** ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161018/7cfb259a/attachment-0001.html From werner.keil at gmail.com Tue Oct 18 06:37:47 2016 From: werner.keil at gmail.com (Werner Keil) Date: Tue, 18 Oct 2016 12:37:47 +0200 Subject: [cdi-dev] Spliting SE package in an independent jar In-Reply-To: References: Message-ID: Yes, but on SE you can't just use the "cdi-se-api" on its own. So SE on the API level needs 2 JARs not just one. That's what I mean. I trust the sum of all JARs for an implementation would be somewhat smaller on SE, otherwise the "Micro" idea of using a self-executable or "Fat" JAR in those places would be ad-absurdum, if you end up with a "Fat JAR" that's bigger than most existing app servers;-) I would have expected a core-api se-api ee-api kind of setup, but if it won't blow implementations on the SE side, I also understand that. Werner On Tue, Oct 18, 2016 at 12:19 PM, John Ament wrote: > Opposite Werner, EE API is larger and has the bulk of the content. SE API > at this point has two classes. > > > ------------------------------ > *From:* cdi-dev-bounces at lists.jboss.org > on behalf of Werner Keil > *Sent:* Tuesday, October 18, 2016 5:27 AM > *To:* cdi-dev > > *Subject:* Re: [cdi-dev] Spliting SE package in an independent jar > > So cdi-se-api is larger than the (core) EE API? > > An SE implementation should hopefully have a smaller footprint than > current EE ones (e.g. Weld)? > > Werner > > > On Tue, Oct 18, 2016 at 11:09 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. Re: Spliting SE package in an independent jar (Martin Kouba) >> 2. [JBoss JIRA] (CDI-45) Optional Injection Points >> (Martin Kouba (JIRA)) >> 3. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0 >> (Antoine Sabot-Durand (JIRA)) >> 4. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0 >> (Antoine Sabot-Durand (JIRA)) >> 5. No meeting tomorrow (Antoine Sabot-Durand) >> 6. Re: Spliting SE package in an independent jar (Emily Jiang) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Thu, 13 Oct 2016 09:56:24 +0200 >> From: Martin Kouba >> Subject: Re: [cdi-dev] Spliting SE package in an independent jar >> To: John Ament , Antoine Sabot-Durand >> , cdi-dev >> Message-ID: <616fdc4e-26f6-a8d7-16d3-fdceb71faa1f at redhat.com> >> Content-Type: text/plain; charset=windows-1252; format=flowed >> >> +1 for John's proposal. >> >> So there will be two API artifacts: >> * cdi-api >> * cdi-se-api (depends on cdi-api) >> >> Martin >> >> Dne 12.10.2016 v 12:40 John Ament napsal(a): >> > the way I've envisioned it: >> > >> > >> > - There is no dedicated EE API (none that I could find that is EE only, >> > except for perhaps session scoped)t >> > >> > - There is SE specific API and the current API could be considered >> "core" >> > >> > >> > >> > Take the current API module and create two submodules, one for core and >> > one for SE. SE depends on core. EE still refers to core as the same >> > existing coordinates (create new coordinates for the parent). >> > >> > ------------------------------------------------------------ >> ------------ >> > *From:* cdi-dev-bounces at lists.jboss.org >> > on behalf of Antoine Sabot-Durand >> > >> > *Sent:* Wednesday, October 12, 2016 5:18 AM >> > *To:* cdi-dev >> > *Subject:* [cdi-dev] Spliting SE package in an independent jar >> > >> > to avoid including CDI SE features in Java EE, we already talk about >> > creating a specific SE jar. >> > >> > Any thought on this approach? >> > >> > Antoine >> > ------------------------------------------------------------ >> ------------ >> > NOTICE: This e-mail message and any attachments may contain >> > confidential, proprietary, and/or privileged information which should be >> > treated accordingly. If you are not the intended recipient, please >> > notify the sender immediately by return e-mail, delete this message, and >> > destroy all physical and electronic copies. Thank you. >> > >> > >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> > Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 (http://www.apache.org/license >> s/LICENSE-2.0.html). For all other ideas provided on this list, the >> provider waives all patent and other intellectual property rights inherent >> in such information. >> > >> >> -- >> 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/license >> s/LICENSE-2.0.html). For all other ideas provided on this list, the >> provider waives all patent and other intellectual property rights inherent >> in such information. >> >> End of cdi-dev Digest, Vol 71, Issue 29 >> *************************************** >> > > ------------------------------ > NOTICE: This e-mail message and any attachments may contain confidential, > proprietary, and/or privileged information which should be treated > accordingly. If you are not the intended recipient, please notify the > sender immediately by return e-mail, delete this message, and destroy all > physical and electronic copies. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161018/faf72610/attachment.html From john.ament at spartasystems.com Tue Oct 18 09:23:00 2016 From: john.ament at spartasystems.com (John Ament) Date: Tue, 18 Oct 2016 13:23:00 +0000 Subject: [cdi-dev] Spliting SE package in an independent jar In-Reply-To: References: , Message-ID: Thats why cdi-se-api depends on cdi-api. ________________________________ From: Werner Keil Sent: Tuesday, October 18, 2016 6:37 AM To: John Ament Cc: cdi-dev Subject: Re: [cdi-dev] Spliting SE package in an independent jar Yes, but on SE you can't just use the "cdi-se-api" on its own. So SE on the API level needs 2 JARs not just one. That's what I mean. I trust the sum of all JARs for an implementation would be somewhat smaller on SE, otherwise the "Micro" idea of using a self-executable or "Fat" JAR in those places would be ad-absurdum, if you end up with a "Fat JAR" that's bigger than most existing app servers;-) I would have expected a core-api se-api ee-api kind of setup, but if it won't blow implementations on the SE side, I also understand that. Werner On Tue, Oct 18, 2016 at 12:19 PM, John Ament > wrote: Opposite Werner, EE API is larger and has the bulk of the content. SE API at this point has two classes. ________________________________ From: cdi-dev-bounces at lists.jboss.org > on behalf of Werner Keil > Sent: Tuesday, October 18, 2016 5:27 AM To: cdi-dev Subject: Re: [cdi-dev] Spliting SE package in an independent jar So cdi-se-api is larger than the (core) EE API? An SE implementation should hopefully have a smaller footprint than current EE ones (e.g. Weld)? Werner On Tue, Oct 18, 2016 at 11:09 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. Re: Spliting SE package in an independent jar (Martin Kouba) 2. [JBoss JIRA] (CDI-45) Optional Injection Points (Martin Kouba (JIRA)) 3. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0 (Antoine Sabot-Durand (JIRA)) 4. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0 (Antoine Sabot-Durand (JIRA)) 5. No meeting tomorrow (Antoine Sabot-Durand) 6. Re: Spliting SE package in an independent jar (Emily Jiang) ---------------------------------------------------------------------- Message: 1 Date: Thu, 13 Oct 2016 09:56:24 +0200 From: Martin Kouba > Subject: Re: [cdi-dev] Spliting SE package in an independent jar To: John Ament >, Antoine Sabot-Durand >, cdi-dev > Message-ID: <616fdc4e-26f6-a8d7-16d3-fdceb71faa1f at redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed +1 for John's proposal. So there will be two API artifacts: * cdi-api * cdi-se-api (depends on cdi-api) Martin Dne 12.10.2016 v 12:40 John Ament napsal(a): > the way I've envisioned it: > > > - There is no dedicated EE API (none that I could find that is EE only, > except for perhaps session scoped)t > > - There is SE specific API and the current API could be considered "core" > > > > Take the current API module and create two submodules, one for core and > one for SE. SE depends on core. EE still refers to core as the same > existing coordinates (create new coordinates for the parent). > > ------------------------------------------------------------------------ > *From:* cdi-dev-bounces at lists.jboss.org > > on behalf of Antoine Sabot-Durand > > > *Sent:* Wednesday, October 12, 2016 5:18 AM > *To:* cdi-dev > *Subject:* [cdi-dev] Spliting SE package in an independent jar > > to avoid including CDI SE features in Java EE, we already talk about > creating a specific SE jar. > > Any thought on this approach? > > Antoine > ------------------------------------------------------------------------ > NOTICE: This e-mail message and any attachments may contain > confidential, proprietary, and/or privileged information which should be > treated accordingly. If you are not the intended recipient, please > notify the sender immediately by return e-mail, delete this message, and > destroy all physical and electronic copies. Thank you. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba 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 71, Issue 29 *************************************** ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161018/a27d605b/attachment-0001.html From werner.keil at gmail.com Tue Oct 18 09:29:39 2016 From: werner.keil at gmail.com (Werner Keil) Date: Tue, 18 Oct 2016 15:29:39 +0200 Subject: [cdi-dev] Spliting SE package in an independent jar In-Reply-To: References: Message-ID: Meaning SE API adds stuff to what EE already needs not sub-setting it, so you end up with more interfaces on SE than EE. If the additional SE JAR is simply for bootstrapping on SE, that's understandable, but it does not meet the idea of >5. Define a lightweight container, which takes the annotations specified by the @Inject specification, defines the behaviour of the container (which @Inject failed to do), and adds a couple of popular features from CDI such as producer >methods. This will allow much wider adoption of CDI in the Java world, and provide a great stepping stone between Java SE, a servlet container, OSGi and a full Java EE server. from the proposal. Was that found out of scope or not doable in CDI 2? Having 2 JARs where EE only nees one is not what I would consider "lightweight". Werner On Tue, Oct 18, 2016 at 3:23 PM, John Ament wrote: > Thats why cdi-se-api depends on cdi-api. > > > ------------------------------ > *From:* Werner Keil > *Sent:* Tuesday, October 18, 2016 6:37 AM > *To:* John Ament > *Cc:* cdi-dev > > *Subject:* Re: [cdi-dev] Spliting SE package in an independent jar > > Yes, but on SE you can't just use the "cdi-se-api" on its own. > > So SE on the API level needs 2 JARs not just one. That's what I mean. > I trust the sum of all JARs for an implementation would be somewhat > smaller on SE, otherwise the "Micro" idea of using a self-executable or > "Fat" JAR in those places would be ad-absurdum, if you end up with a "Fat > JAR" that's bigger than most existing app servers;-) > > I would have expected a > core-api > se-api > ee-api > > kind of setup, but if it won't blow implementations on the SE side, I also > understand that. > > Werner > > > On Tue, Oct 18, 2016 at 12:19 PM, John Ament > wrote: > >> Opposite Werner, EE API is larger and has the bulk of the content. SE >> API at this point has two classes. >> >> >> ------------------------------ >> *From:* cdi-dev-bounces at lists.jboss.org >> on behalf of Werner Keil >> *Sent:* Tuesday, October 18, 2016 5:27 AM >> *To:* cdi-dev >> >> *Subject:* Re: [cdi-dev] Spliting SE package in an independent jar >> >> So cdi-se-api is larger than the (core) EE API? >> >> An SE implementation should hopefully have a smaller footprint than >> current EE ones (e.g. Weld)? >> >> Werner >> >> >> On Tue, Oct 18, 2016 at 11:09 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. Re: Spliting SE package in an independent jar (Martin Kouba) >>> 2. [JBoss JIRA] (CDI-45) Optional Injection Points >>> (Martin Kouba (JIRA)) >>> 3. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0 >>> (Antoine Sabot-Durand (JIRA)) >>> 4. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0 >>> (Antoine Sabot-Durand (JIRA)) >>> 5. No meeting tomorrow (Antoine Sabot-Durand) >>> 6. Re: Spliting SE package in an independent jar (Emily Jiang) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Thu, 13 Oct 2016 09:56:24 +0200 >>> From: Martin Kouba >>> Subject: Re: [cdi-dev] Spliting SE package in an independent jar >>> To: John Ament , Antoine Sabot-Durand >>> , cdi-dev >> > >>> Message-ID: <616fdc4e-26f6-a8d7-16d3-fdceb71faa1f at redhat.com> >>> Content-Type: text/plain; charset=windows-1252; format=flowed >>> >>> +1 for John's proposal. >>> >>> So there will be two API artifacts: >>> * cdi-api >>> * cdi-se-api (depends on cdi-api) >>> >>> Martin >>> >>> Dne 12.10.2016 v 12:40 John Ament napsal(a): >>> > the way I've envisioned it: >>> > >>> > >>> > - There is no dedicated EE API (none that I could find that is EE only, >>> > except for perhaps session scoped)t >>> > >>> > - There is SE specific API and the current API could be considered >>> "core" >>> > >>> > >>> > >>> > Take the current API module and create two submodules, one for core and >>> > one for SE. SE depends on core. EE still refers to core as the same >>> > existing coordinates (create new coordinates for the parent). >>> > >>> > ------------------------------------------------------------ >>> ------------ >>> > *From:* cdi-dev-bounces at lists.jboss.org >>> > on behalf of Antoine Sabot-Durand >>> > >>> > *Sent:* Wednesday, October 12, 2016 5:18 AM >>> > *To:* cdi-dev >>> > *Subject:* [cdi-dev] Spliting SE package in an independent jar >>> > >>> > to avoid including CDI SE features in Java EE, we already talk about >>> > creating a specific SE jar. >>> > >>> > Any thought on this approach? >>> > >>> > Antoine >>> > ------------------------------------------------------------ >>> ------------ >>> > NOTICE: This e-mail message and any attachments may contain >>> > confidential, proprietary, and/or privileged information which should >>> be >>> > treated accordingly. If you are not the intended recipient, please >>> > notify the sender immediately by return e-mail, delete this message, >>> and >>> > destroy all physical and electronic copies. Thank you. >>> > >>> > >>> > _______________________________________________ >>> > cdi-dev mailing list >>> > cdi-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/cdi-dev >>> > >>> > Note that for all code provided on this list, the provider licenses >>> the code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> > >>> >>> -- >>> Martin Kouba >>> 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/license >>> s/LICENSE-2.0.html). For all other ideas provided on this list, the >>> provider waives all patent and other intellectual property rights inherent >>> in such information. >>> >>> End of cdi-dev Digest, Vol 71, Issue 29 >>> *************************************** >>> >> >> ------------------------------ >> NOTICE: This e-mail message and any attachments may contain confidential, >> proprietary, and/or privileged information which should be treated >> accordingly. If you are not the intended recipient, please notify the >> sender immediately by return e-mail, delete this message, and destroy all >> physical and electronic copies. Thank you. >> > > ------------------------------ > NOTICE: This e-mail message and any attachments may contain confidential, > proprietary, and/or privileged information which should be treated > accordingly. If you are not the intended recipient, please notify the > sender immediately by return e-mail, delete this message, and destroy all > physical and electronic copies. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161018/2a46a64a/attachment.html From mkouba at redhat.com Wed Oct 19 04:13:38 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 19 Oct 2016 10:13:38 +0200 Subject: [cdi-dev] Team mentions on github Message-ID: <0ab85968-f073-9cec-7a31-c84c4c540d42@redhat.com> Dear EG, I've just found a github feature called "team mentions" [1]. It allows to reference (send notifications to) every member of a team. The syntax is: @orgname/teamname. In cdi-spec organization there is a team called EG [2]. Sometimes it might be useful to reference this team e.g. when a PR is changed/needs review of EG. I've added several active members and invited few others. Feel free to accept/reject invitation or send request to join the team. To reference the EG team in comments/issues: @cdi-spec/eg Thanks, Martin [1] https://guides.github.com/features/issues/#mentions [2] https://github.com/orgs/cdi-spec/teams/eg From issues at jboss.org Wed Oct 19 04:22:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 19 Oct 2016 04:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba reassigned CDI-625: -------------------------------- Assignee: Martin Kouba > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Assignee: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 .Final > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 19 04:23:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 19 Oct 2016 04:23:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-625: ----------------------------- Sprint: Sprint 1 > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Assignee: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 .Final > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 19 04:29:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 19 Oct 2016 04:29:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-546) Constant for default observer priority In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba reassigned CDI-546: -------------------------------- Assignee: Martin Kouba > Constant for default observer priority > -------------------------------------- > > Key: CDI-546 > URL: https://issues.jboss.org/browse/CDI-546 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Assignee: Martin Kouba > Priority: Minor > Fix For: 2.0 .Final > > > Currently we use: > {code:JAVA} > @Override > public default int getPriority() { > return javax.interceptor.Interceptor.Priority.APPLICATION + 500; > }; > {code} > It would be nice to have the value stored as a constant e.g.: > {code:JAVA} > int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500; > {code} > so that other code can reference it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 19 05:07:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 19 Oct 2016 05:07:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-637) Rename builder package to configurator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba reassigned CDI-637: -------------------------------- Assignee: Tomas Remes > Rename builder package to configurator > --------------------------------------- > > Key: CDI-637 > URL: https://issues.jboss.org/browse/CDI-637 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0-EDR2 > Reporter: Antoine Sabot-Durand > Assignee: Tomas Remes > Fix For: 2.0 .Final > > > Since it contains only confgurators, package {{javax.enterprise.inject.spi.builder}} should be renamed {{javax.enterprise.inject.spi.configurator}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 19 05:14:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 19 Oct 2016 05:14:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-500) Clarify @Intercepted Bean metadata injection for EE components In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba reassigned CDI-500: -------------------------------- Assignee: Martin Kouba > Clarify @Intercepted Bean metadata injection for EE components > -------------------------------------------------------------- > > Key: CDI-500 > URL: https://issues.jboss.org/browse/CDI-500 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 2.0 .Final > > > It's not clear what should happen when an interceptor with {{@Intercepted Bean}} metadata is associated with an EE component. > See the CDI spec, "5.5.8. Bean metadata": > {quote} > Additionally, the container must provide beans allowing interceptors and decorators to obtain information about the beans they intercept and decorate: > * a bean with scope @Dependent, qualifier @Intercepted and type Bean which can be injected into any interceptor instance, and > * ... > {quote} > However, most EE components must also support the use of CDI interceptors. See also the Java EE 7 spec, "EE.5.2.5 Annotations and Injection": > {quote} > The component classes listed in Table EE.5-1 with support level "Standard" > all support Java EE resource injection, as well as PostConstruct and PreDestroy callbacks. In addition, if CDI is enabled?which it is by default?these classes also support CDI injection, as described in Section EE.5.24, "Support for Dependency Injection", and the use of interceptors. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From werner.keil at gmail.com Wed Oct 19 05:48:37 2016 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 19 Oct 2016 11:48:37 +0200 Subject: [cdi-dev] Team mentions on github Message-ID: Martin, Thanks for pointing that out. Have to try it on GitHub, e.g. issues or elsewhere. I used quoting individual users before on many cases. However, CDI uses JIRA at JBoss, so not sure, if this would work there, too? It does in the GitHub issue tracker. PRs if there's more discussion there might work, but maybe not the issue tracker, or do we have an EG group there, too? Werner On Wed, Oct 19, 2016 at 10:22 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. Re: Spliting SE package in an independent jar (Werner Keil) > 2. Team mentions on github (Martin Kouba) > 3. [JBoss JIRA] (CDI-625) When exactly are events with > @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > (Martin Kouba (JIRA)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 18 Oct 2016 15:29:39 +0200 > From: Werner Keil > Subject: Re: [cdi-dev] Spliting SE package in an independent jar > To: John Ament > Cc: cdi-dev > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > Meaning SE API adds stuff to what EE already needs not sub-setting it, so > you end up with more interfaces on SE than EE. > > If the additional SE JAR is simply for bootstrapping on SE, that's > understandable, but it does not meet the idea of > > >5. Define a lightweight container, which takes the annotations specified > by the @Inject specification, defines the behaviour of the container (which > @Inject failed to do), and adds a couple of popular features from CDI such > as producer >methods. This will allow much wider adoption of CDI in the > Java world, and provide a great stepping stone between Java SE, a servlet > container, OSGi and a full Java EE server. > from the proposal. > > Was that found out of scope or not doable in CDI 2? > > Having 2 JARs where EE only nees one is not what I would consider > "lightweight". > > Werner > > > On Tue, Oct 18, 2016 at 3:23 PM, John Ament > wrote: > > > Thats why cdi-se-api depends on cdi-api. > > > > > > ------------------------------ > > *From:* Werner Keil > > *Sent:* Tuesday, October 18, 2016 6:37 AM > > *To:* John Ament > > *Cc:* cdi-dev > > > > *Subject:* Re: [cdi-dev] Spliting SE package in an independent jar > > > > Yes, but on SE you can't just use the "cdi-se-api" on its own. > > > > So SE on the API level needs 2 JARs not just one. That's what I mean. > > I trust the sum of all JARs for an implementation would be somewhat > > smaller on SE, otherwise the "Micro" idea of using a self-executable or > > "Fat" JAR in those places would be ad-absurdum, if you end up with a "Fat > > JAR" that's bigger than most existing app servers;-) > > > > I would have expected a > > core-api > > se-api > > ee-api > > > > kind of setup, but if it won't blow implementations on the SE side, I > also > > understand that. > > > > Werner > > > > > > On Tue, Oct 18, 2016 at 12:19 PM, John Ament < > john.ament at spartasystems.com > > > wrote: > > > >> Opposite Werner, EE API is larger and has the bulk of the content. SE > >> API at this point has two classes. > >> > >> > >> ------------------------------ > >> *From:* cdi-dev-bounces at lists.jboss.org org> > >> on behalf of Werner Keil > >> *Sent:* Tuesday, October 18, 2016 5:27 AM > >> *To:* cdi-dev > >> > >> *Subject:* Re: [cdi-dev] Spliting SE package in an independent jar > >> > >> So cdi-se-api is larger than the (core) EE API? > >> > >> An SE implementation should hopefully have a smaller footprint than > >> current EE ones (e.g. Weld)? > >> > >> Werner > >> > >> > >> On Tue, Oct 18, 2016 at 11:09 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. Re: Spliting SE package in an independent jar (Martin Kouba) > >>> 2. [JBoss JIRA] (CDI-45) Optional Injection Points > >>> (Martin Kouba (JIRA)) > >>> 3. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0 > >>> (Antoine Sabot-Durand (JIRA)) > >>> 4. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0 > >>> (Antoine Sabot-Durand (JIRA)) > >>> 5. No meeting tomorrow (Antoine Sabot-Durand) > >>> 6. Re: Spliting SE package in an independent jar (Emily Jiang) > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> > >>> Message: 1 > >>> Date: Thu, 13 Oct 2016 09:56:24 +0200 > >>> From: Martin Kouba > >>> Subject: Re: [cdi-dev] Spliting SE package in an independent jar > >>> To: John Ament , Antoine Sabot-Durand > >>> , cdi-dev < > cdi-dev at lists.jboss.org > >>> > > >>> Message-ID: <616fdc4e-26f6-a8d7-16d3-fdceb71faa1f at redhat.com> > >>> Content-Type: text/plain; charset=windows-1252; format=flowed > >>> > >>> +1 for John's proposal. > >>> > >>> So there will be two API artifacts: > >>> * cdi-api > >>> * cdi-se-api (depends on cdi-api) > >>> > >>> Martin > >>> > >>> Dne 12.10.2016 v 12:40 John Ament napsal(a): > >>> > the way I've envisioned it: > >>> > > >>> > > >>> > - There is no dedicated EE API (none that I could find that is EE > only, > >>> > except for perhaps session scoped)t > >>> > > >>> > - There is SE specific API and the current API could be considered > >>> "core" > >>> > > >>> > > >>> > > >>> > Take the current API module and create two submodules, one for core > and > >>> > one for SE. SE depends on core. EE still refers to core as the same > >>> > existing coordinates (create new coordinates for the parent). > >>> > > >>> > ------------------------------------------------------------ > >>> ------------ > >>> > *From:* cdi-dev-bounces at lists.jboss.org > >>> > on behalf of Antoine Sabot-Durand > >>> > > >>> > *Sent:* Wednesday, October 12, 2016 5:18 AM > >>> > *To:* cdi-dev > >>> > *Subject:* [cdi-dev] Spliting SE package in an independent jar > >>> > > >>> > to avoid including CDI SE features in Java EE, we already talk about > >>> > creating a specific SE jar. > >>> > > >>> > Any thought on this approach? > >>> > > >>> > Antoine > >>> > ------------------------------------------------------------ > >>> ------------ > >>> > NOTICE: This e-mail message and any attachments may contain > >>> > confidential, proprietary, and/or privileged information which should > >>> be > >>> > treated accordingly. If you are not the intended recipient, please > >>> > notify the sender immediately by return e-mail, delete this message, > >>> and > >>> > destroy all physical and electronic copies. Thank you. > >>> > > >>> > > >>> > _______________________________________________ > >>> > cdi-dev mailing list > >>> > cdi-dev at lists.jboss.org > >>> > https://lists.jboss.org/mailman/listinfo/cdi-dev > >>> > > >>> > Note that for all code provided on this list, the provider licenses > >>> the code under the Apache License, Version 2 ( > >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > >>> provided on this list, the provider waives all patent and other > >>> intellectual property rights inherent in such information. > >>> > > >>> > >>> -- > >>> Martin Kouba > >>> 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/license > >>> s/LICENSE-2.0.html). For all other ideas provided on this list, the > >>> provider waives all patent and other intellectual property rights > inherent > >>> in such information. > >>> > >>> End of cdi-dev Digest, Vol 71, Issue 29 > >>> *************************************** > >>> > >> > >> ------------------------------ > >> NOTICE: This e-mail message and any attachments may contain > confidential, > >> proprietary, and/or privileged information which should be treated > >> accordingly. If you are not the intended recipient, please notify the > >> sender immediately by return e-mail, delete this message, and destroy > all > >> physical and electronic copies. Thank you. > >> > > > > ------------------------------ > > NOTICE: This e-mail message and any attachments may contain confidential, > > proprietary, and/or privileged information which should be treated > > accordingly. If you are not the intended recipient, please notify the > > sender immediately by return e-mail, delete this message, and destroy all > > physical and electronic copies. Thank you. > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/ > 20161018/2a46a64a/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Wed, 19 Oct 2016 10:13:38 +0200 > From: Martin Kouba > Subject: [cdi-dev] Team mentions on github > To: cdi-dev > Message-ID: <0ab85968-f073-9cec-7a31-c84c4c540d42 at redhat.com> > Content-Type: text/plain; charset=iso-8859-2; format=flowed > > Dear EG, > > I've just found a github feature called "team mentions" [1]. It allows > to reference (send notifications to) every member of a team. The syntax > is: @orgname/teamname. > > In cdi-spec organization there is a team called EG [2]. Sometimes it > might be useful to reference this team e.g. when a PR is changed/needs > review of EG. > > I've added several active members and invited few others. Feel free to > accept/reject invitation or send request to join the team. > > To reference the EG team in comments/issues: @cdi-spec/eg > > Thanks, > > Martin > > [1] > https://guides.github.com/features/issues/#mentions > > [2] > https://github.com/orgs/cdi-spec/teams/eg > > > ------------------------------ > > Message: 3 > Date: Wed, 19 Oct 2016 04:22:00 -0400 (EDT) > From: "Martin Kouba (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with > @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ https://issues.jboss.org/browse/CDI-625?page=com. > atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Martin Kouba reassigned CDI-625: > -------------------------------- > > Assignee: Martin Kouba > > > > When exactly are events with @Initialized(X.class) and > @Destroyed(X.class) qualifiers fired > > ------------------------------------------------------------ > ------------------------------- > > > > Key: CDI-625 > > URL: https://issues.jboss.org/browse/CDI-625 > > Project: CDI Specification Issues > > Issue Type: Clarification > > Components: Events > > Reporter: Martin Kouba > > Assignee: Martin Kouba > > Labels: F2F2016 > > Fix For: 2.0 .Final > > > > > > The spec states that {{@Initialized(X.class)}} is fired when a context > is initialized and {{@Destroyed(X.class)}} when a context is destroyed > (note that for {{@ApplicationScoped}} the wording leaves out the context: > _"when the application is destroyed"_). > > Does it mean that: > > * {{@Initialized(X.class)}} is fired *after the initialization* of a > context is finished, i.e. the context is ready? > > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context > is finished, i.e. after all the beans are destroyed? > > I'm asking because for {{@Destroyed(X.class)}} it might be useful to > perform some cleanup before the context is actually destroyed - see also > CDI-601. > > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is > currently a little bit inconsistent. For webapps and Weld SE, the event is > fired before the context is destroyed. But for non-web EE modules (e.g. ejb > jar) the event is fired after the context is destroyed. > > I believe this should be more clear. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > _______________________________________________ > 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 71, Issue 32 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161019/a74dc729/attachment-0001.html From mkouba at redhat.com Wed Oct 19 05:52:32 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 19 Oct 2016 11:52:32 +0200 Subject: [cdi-dev] Team mentions on github In-Reply-To: References: Message-ID: <11fdaf6f-ded3-d18e-bf9a-bb8d5797889a@redhat.com> Hi Werner, this only works in GitHub pull request comments. Martin Dne 19.10.2016 v 11:48 Werner Keil napsal(a): > Martin, > > Thanks for pointing that out. Have to try it on GitHub, e.g. issues or > elsewhere. I used quoting individual users before on many cases. > > However, CDI uses JIRA at JBoss, so not sure, if this would work there, too? > It does in the GitHub issue tracker. PRs if there's more discussion > there might work, but maybe not the issue tracker, or do we have an EG > group there, too? > > Werner > > > > On Wed, Oct 19, 2016 at 10:22 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. Re: Spliting SE package in an independent jar (Werner Keil) > 2. Team mentions on github (Martin Kouba) > 3. [JBoss JIRA] (CDI-625) When exactly are events with > @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > (Martin Kouba (JIRA)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 18 Oct 2016 15:29:39 +0200 > From: Werner Keil > > Subject: Re: [cdi-dev] Spliting SE package in an independent jar > To: John Ament > > Cc: cdi-dev > > Message-ID: > > > > Content-Type: text/plain; charset="utf-8" > > Meaning SE API adds stuff to what EE already needs not sub-setting > it, so > you end up with more interfaces on SE than EE. > > If the additional SE JAR is simply for bootstrapping on SE, that's > understandable, but it does not meet the idea of > > >5. Define a lightweight container, which takes the annotations > specified > by the @Inject specification, defines the behaviour of the container > (which > @Inject failed to do), and adds a couple of popular features from > CDI such > as producer >methods. This will allow much wider adoption of CDI in the > Java world, and provide a great stepping stone between Java SE, a > servlet > container, OSGi and a full Java EE server. > from the proposal. > > Was that found out of scope or not doable in CDI 2? > > Having 2 JARs where EE only nees one is not what I would consider > "lightweight". > > Werner > > > On Tue, Oct 18, 2016 at 3:23 PM, John Ament > > > wrote: > > > Thats why cdi-se-api depends on cdi-api. > > > > > > ------------------------------ > > *From:* Werner Keil > > > *Sent:* Tuesday, October 18, 2016 6:37 AM > > *To:* John Ament > > *Cc:* cdi-dev > > > > *Subject:* Re: [cdi-dev] Spliting SE package in an independent jar > > > > Yes, but on SE you can't just use the "cdi-se-api" on its own. > > > > So SE on the API level needs 2 JARs not just one. That's what I mean. > > I trust the sum of all JARs for an implementation would be somewhat > > smaller on SE, otherwise the "Micro" idea of using a > self-executable or > > "Fat" JAR in those places would be ad-absurdum, if you end up with > a "Fat > > JAR" that's bigger than most existing app servers;-) > > > > I would have expected a > > core-api > > se-api > > ee-api > > > > kind of setup, but if it won't blow implementations on the SE > side, I also > > understand that. > > > > Werner > > > > > > On Tue, Oct 18, 2016 at 12:19 PM, John Ament > > > > wrote: > > > >> Opposite Werner, EE API is larger and has the bulk of the > content. SE > >> API at this point has two classes. > >> > >> > >> ------------------------------ > >> *From:* cdi-dev-bounces at lists.jboss.org > > > > >> on behalf of Werner Keil > > >> *Sent:* Tuesday, October 18, 2016 5:27 AM > >> *To:* cdi-dev > >> > >> *Subject:* Re: [cdi-dev] Spliting SE package in an independent jar > >> > >> So cdi-se-api is larger than the (core) EE API? > >> > >> An SE implementation should hopefully have a smaller footprint than > >> current EE ones (e.g. Weld)? > >> > >> Werner > >> > >> > >> On Tue, Oct 18, 2016 at 11:09 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. Re: Spliting SE package in an independent jar (Martin Kouba) > >>> 2. [JBoss JIRA] (CDI-45) Optional Injection Points > >>> (Martin Kouba (JIRA)) > >>> 3. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0 > >>> (Antoine Sabot-Durand (JIRA)) > >>> 4. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0 > >>> (Antoine Sabot-Durand (JIRA)) > >>> 5. No meeting tomorrow (Antoine Sabot-Durand) > >>> 6. Re: Spliting SE package in an independent jar (Emily Jiang) > >>> > >>> > >>> > ---------------------------------------------------------------------- > >>> > >>> Message: 1 > >>> Date: Thu, 13 Oct 2016 09:56:24 +0200 > >>> From: Martin Kouba > > >>> Subject: Re: [cdi-dev] Spliting SE package in an independent jar > >>> To: John Ament >, Antoine Sabot-Durand > >>> >, cdi-dev > > >>> > > >>> Message-ID: <616fdc4e-26f6-a8d7-16d3-fdceb71faa1f at redhat.com > > > >>> Content-Type: text/plain; charset=windows-1252; format=flowed > >>> > >>> +1 for John's proposal. > >>> > >>> So there will be two API artifacts: > >>> * cdi-api > >>> * cdi-se-api (depends on cdi-api) > >>> > >>> Martin > >>> > >>> Dne 12.10.2016 v 12:40 John Ament napsal(a): > >>> > the way I've envisioned it: > >>> > > >>> > > >>> > - There is no dedicated EE API (none that I could find that is > EE only, > >>> > except for perhaps session scoped)t > >>> > > >>> > - There is SE specific API and the current API could be considered > >>> "core" > >>> > > >>> > > >>> > > >>> > Take the current API module and create two submodules, one for > core and > >>> > one for SE. SE depends on core. EE still refers to core as > the same > >>> > existing coordinates (create new coordinates for the parent). > >>> > > >>> > ------------------------------------------------------------ > >>> ------------ > >>> > *From:* cdi-dev-bounces at lists.jboss.org > > >>> > > on behalf of Antoine > Sabot-Durand > >>> > > > >>> > *Sent:* Wednesday, October 12, 2016 5:18 AM > >>> > *To:* cdi-dev > >>> > *Subject:* [cdi-dev] Spliting SE package in an independent jar > >>> > > >>> > to avoid including CDI SE features in Java EE, we already talk > about > >>> > creating a specific SE jar. > >>> > > >>> > Any thought on this approach? > >>> > > >>> > Antoine > >>> > ------------------------------------------------------------ > >>> ------------ > >>> > NOTICE: This e-mail message and any attachments may contain > >>> > confidential, proprietary, and/or privileged information which > should > >>> be > >>> > treated accordingly. If you are not the intended recipient, please > >>> > notify the sender immediately by return e-mail, delete this > message, > >>> and > >>> > destroy all physical and electronic copies. Thank you. > >>> > > >>> > > >>> > _______________________________________________ > >>> > cdi-dev mailing list > >>> > cdi-dev at lists.jboss.org > >>> > https://lists.jboss.org/mailman/listinfo/cdi-dev > > >>> > > >>> > Note that for all code provided on this list, the provider > licenses > >>> the code under the Apache License, Version 2 ( > >>> http://www.apache.org/licenses/LICENSE-2.0.html > ). For all other ideas > >>> provided on this list, the provider waives all patent and other > >>> intellectual property rights inherent in such information. > >>> > > >>> > >>> -- > >>> Martin Kouba > >>> 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/license > >>> s/LICENSE-2.0.html). For all other ideas provided on this list, the > >>> provider waives all patent and other intellectual property > rights inherent > >>> in such information. > >>> > >>> End of cdi-dev Digest, Vol 71, Issue 29 > >>> *************************************** > >>> > >> > >> ------------------------------ > >> NOTICE: This e-mail message and any attachments may contain > confidential, > >> proprietary, and/or privileged information which should be treated > >> accordingly. If you are not the intended recipient, please notify the > >> sender immediately by return e-mail, delete this message, and > destroy all > >> physical and electronic copies. Thank you. > >> > > > > ------------------------------ > > NOTICE: This e-mail message and any attachments may contain > confidential, > > proprietary, and/or privileged information which should be treated > > accordingly. If you are not the intended recipient, please notify the > > sender immediately by return e-mail, delete this message, and > destroy all > > physical and electronic copies. Thank you. > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20161018/2a46a64a/attachment-0001.html > > > ------------------------------ > > Message: 2 > Date: Wed, 19 Oct 2016 10:13:38 +0200 > From: Martin Kouba > > Subject: [cdi-dev] Team mentions on github > To: cdi-dev > > Message-ID: <0ab85968-f073-9cec-7a31-c84c4c540d42 at redhat.com > > > Content-Type: text/plain; charset=iso-8859-2; format=flowed > > Dear EG, > > I've just found a github feature called "team mentions" [1]. It allows > to reference (send notifications to) every member of a team. The syntax > is: @orgname/teamname. > > In cdi-spec organization there is a team called EG [2]. Sometimes it > might be useful to reference this team e.g. when a PR is changed/needs > review of EG. > > I've added several active members and invited few others. Feel free to > accept/reject invitation or send request to join the team. > > To reference the EG team in comments/issues: @cdi-spec/eg > > Thanks, > > Martin > > [1] > https://guides.github.com/features/issues/#mentions > > > [2] > https://github.com/orgs/cdi-spec/teams/eg > > > > ------------------------------ > > Message: 3 > Date: Wed, 19 Oct 2016 04:22:00 -0400 (EDT) > From: "Martin Kouba (JIRA)" > > Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with > @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > > ] > > Martin Kouba reassigned CDI-625: > -------------------------------- > > Assignee: Martin Kouba > > > > When exactly are events with @Initialized(X.class) and > @Destroyed(X.class) qualifiers fired > > > ------------------------------------------------------------------------------------------- > > > > Key: CDI-625 > > URL: https://issues.jboss.org/browse/CDI-625 > > > Project: CDI Specification Issues > > Issue Type: Clarification > > Components: Events > > Reporter: Martin Kouba > > Assignee: Martin Kouba > > Labels: F2F2016 > > Fix For: 2.0 .Final > > > > > > The spec states that {{@Initialized(X.class)}} is fired when a > context is initialized and {{@Destroyed(X.class)}} when a context is > destroyed (note that for {{@ApplicationScoped}} the wording leaves > out the context: _"when the application is destroyed"_). > > Does it mean that: > > * {{@Initialized(X.class)}} is fired *after the initialization* of > a context is finished, i.e. the context is ready? > > * {{@Destroyed(X.class)}} is fired *after the destruction* of a > context is finished, i.e. after all the beans are destroyed? > > I'm asking because for {{@Destroyed(X.class)}} it might be useful > to perform some cleanup before the context is actually destroyed - > see also CDI-601. > > In RI/Weld, the behaivour of > {{@Destroyed(ApplicationScoped.class)}} is currently a little bit > inconsistent. For webapps and Weld SE, the event is fired before the > context is destroyed. But for non-web EE modules (e.g. ejb jar) the > event is fired after the context is destroyed. > > I believe this should be more clear. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > _______________________________________________ > 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 71, Issue 32 > *************************************** > > > > > _______________________________________________ > 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 Wed Oct 19 06:41:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 19 Oct 2016 06:41: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:all-tabpanel ] Tomas Remes reassigned CDI-623: ------------------------------- Assignee: Tomas Remes > 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 > Assignee: Tomas Remes > Labels: F2F2016 > Fix For: 2.0 .Final > > > 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 issues at jboss.org Wed Oct 19 08:13:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 19 Oct 2016 08:13:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-592) Consider adding ObserverMethod.notify() method which also accepts EventMetadata In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba reassigned CDI-592: -------------------------------- Assignee: Martin Kouba > Consider adding ObserverMethod.notify() method which also accepts EventMetadata > ------------------------------------------------------------------------------- > > Key: CDI-592 > URL: https://issues.jboss.org/browse/CDI-592 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 2.0 .Final > > > {code:java} > // Make the original method also default so that new impls don't need to implement two methods > default void notify(T event) { > // No-op > } > // The container should always call this method... > default void notify(T event, EventMetadata metadata) { > notify(event); > } > {code} > This should not break existing implementations. The truth is a custom impl will not be forced to implement any {{notify()}} method. But I think the benefits are worth it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 19 08:47:01 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 19 Oct 2016 08:47:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-495) What happens if an illegal bean type is found in the set of bean types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309280#comment-13309280 ] Tomas Remes commented on CDI-495: --------------------------------- I am just wondering if it's worth of specifying. Wasn't there any special case when it is problematic? > What happens if an illegal bean type is found in the set of bean types > ---------------------------------------------------------------------- > > Key: CDI-495 > URL: https://issues.jboss.org/browse/CDI-495 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 19 09:07:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 19 Oct 2016 09:07:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-495) What happens if an illegal bean type is found in the set of bean types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309292#comment-13309292 ] Martin Kouba commented on CDI-495: ---------------------------------- [~tremes] See also WELD-1831 and [DELTASPIKE-817|https://issues.apache.org/jira/browse/DELTASPIKE-817]. > What happens if an illegal bean type is found in the set of bean types > ---------------------------------------------------------------------- > > Key: CDI-495 > URL: https://issues.jboss.org/browse/CDI-495 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 19 09:56:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 19 Oct 2016 09:56:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-497) session scope doesn't follow session lifecycle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309330#comment-13309330 ] Martin Kouba commented on CDI-497: ---------------------------------- [~agoncal] Yes, but the quoted sentence only applies to session timeouts. Servlet spec does not mention {{HttpSession.invalidate()}} at all. I think we should ask Servlet EG first. [~antoinesabot-durand] Isn't this a candidate for CDI 2.1 which targets Java EE 8? > session scope doesn't follow session lifecycle > ---------------------------------------------- > > Key: CDI-497 > URL: https://issues.jboss.org/browse/CDI-497 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > Fix For: 2.0 .Final > > > ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case). > Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Thu Oct 20 04:14:08 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 20 Oct 2016 08:14:08 +0000 Subject: [cdi-dev] Open PR validation Message-ID: Hi all, As the feature freeze date approach we have a lot of PR pending. Some are big ones and ask a lot of discussion, some are rather obvious. For these PR, I started to merge them if they were 1 week old and have at least one person ok with its content. I'd prefer to have more than one review of these, but we have a schedule to meet. Try to check these small PR to be sure that we don't miss something, but after one week with only positive feedback there will be merged. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161020/66219660/attachment.html From EMIJIANG at uk.ibm.com Thu Oct 20 11:47:56 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Thu, 20 Oct 2016 16:47:56 +0100 Subject: [cdi-dev] Open PR validation In-Reply-To: References: Message-ID: I'm trying to push my changes on cdi-616, but got the following error message: C:\cdi-2.0\cdi>git push -u origin emily-cdi remote: Permission to cdi-spec/cdi.git denied to Emily-Jiang. fatal: unable to access 'https://github.com/cdi-spec/cdi.git/': The requested URL returned error: 403 Any thoughts on what went wrong? 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: 20/10/2016 09:16 Subject: [cdi-dev] Open PR validation Sent by: cdi-dev-bounces at lists.jboss.org Hi all, As the feature freeze date approach we have a lot of PR pending. Some are big ones and ask a lot of discussion, some are rather obvious. For these PR, I started to merge them if they were 1 week old and have at least one person ok with its content. I'd prefer to have more than one review of these, but we have a schedule to meet. Try to check these small PR to be sure that we don't miss something, but after one week with only positive feedback there will be merged. 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/20161020/fe85252a/attachment.html From john.ament at spartasystems.com Thu Oct 20 11:53:38 2016 From: john.ament at spartasystems.com (John Ament) Date: Thu, 20 Oct 2016 15:53:38 +0000 Subject: [cdi-dev] Open PR validation In-Reply-To: References: , Message-ID: You need to fork the repository and push to your fork. ________________________________ From: cdi-dev-bounces at lists.jboss.org on behalf of Emily Jiang Sent: Thursday, October 20, 2016 11:47 AM To: Antoine Sabot-Durand Cc: cdi-dev Subject: Re: [cdi-dev] Open PR validation I'm trying to push my changes on cdi-616, but got the following error message: C:\cdi-2.0\cdi>git push -u origin emily-cdi remote: Permission to cdi-spec/cdi.git denied to Emily-Jiang. fatal: unable to access 'https://github.com/cdi-spec/cdi.git/': The requested URL returned error: 403 Any thoughts on what went wrong? 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: 20/10/2016 09:16 Subject: [cdi-dev] Open PR validation Sent by: cdi-dev-bounces at lists.jboss.org ________________________________ Hi all, As the feature freeze date approach we have a lot of PR pending. Some are big ones and ask a lot of discussion, some are rather obvious. For these PR, I started to merge them if they were 1 week old and have at least one person ok with its content. I'd prefer to have more than one review of these, but we have a schedule to meet. Try to check these small PR to be sure that we don't miss something, but after one week with only positive feedback there will be merged. 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 Info Page - JBoss Developer lists.jboss.org List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives. Apache License, Version 2.0 www.apache.org Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1. Definitions. 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 ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161020/e846ab5f/attachment-0001.html From antoine at sabot-durand.net Thu Oct 20 12:00:53 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 20 Oct 2016 16:00:53 +0000 Subject: [cdi-dev] Open PR validation In-Reply-To: References: Message-ID: Emily, As John said, create your fork of the repo and then follow this guide: https://help.github.com/articles/creating-a-pull-request-from-a-fork/ Antoine On Thu, Oct 20, 2016 at 5:53 PM John Ament wrote: > You need to fork the repository and push to your fork. > > > ------------------------------ > *From:* cdi-dev-bounces at lists.jboss.org > on behalf of Emily Jiang > *Sent:* Thursday, October 20, 2016 11:47 AM > *To:* Antoine Sabot-Durand > *Cc:* cdi-dev > *Subject:* Re: [cdi-dev] Open PR validation > > I'm trying to push my changes on cdi-616, but got the following error > message: > > C:\cdi-2.0\cdi>git push -u origin emily-cdi > remote: Permission to cdi-spec/cdi.git denied to Emily-Jiang. > fatal: unable to access 'https://github.com/cdi-spec/cdi.git/': The > requested URL returned error: 403 > > Any thoughts on what went wrong? > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 <+44%201962%20816278> Internal: 246278 > > Email: emijiang at uk.ibm.com > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Antoine Sabot-Durand > To: cdi-dev > Date: 20/10/2016 09:16 > Subject: [cdi-dev] Open PR validation > Sent by: cdi-dev-bounces at lists.jboss.org > ------------------------------ > > > > Hi all, > > As the feature freeze date approach we have a lot of PR pending. Some are > big ones and ask a lot of discussion, some are rather obvious. > > For these PR, I started to merge them if they were 1 week old and have at > least one person ok with its content. I'd prefer to have more than one > review of these, but we have a schedule to meet. > > Try to check these small PR to be sure that we don't miss something, but > after one week with only positive feedback there will be merged. > > 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 Info Page - JBoss Developer > > lists.jboss.org > List to discuss the development of CDI (the specification) To see the > collection of prior postings to the list, visit the cdi-dev Archives. > > Apache License, Version 2.0 > > www.apache.org > Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ > TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1. > Definitions. > > > > 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 > ------------------------------ > NOTICE: This e-mail message and any attachments may contain confidential, > proprietary, and/or privileged information which should be treated > accordingly. If you are not the intended recipient, please notify the > sender immediately by return e-mail, delete this message, and destroy all > physical and electronic copies. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161020/06062380/attachment.html From issues at jboss.org Thu Oct 20 17:42:00 2016 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Thu, 20 Oct 2016 17:42:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-616) Injection point declared as transient is not useful In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310128#comment-13310128 ] Emily Jiang commented on CDI-616: --------------------------------- On f2f, the suggestion is to add "Injection in transient field is not supported. Non portable behaviour will occur" under 5.2.5. After some more thinking, I still think what I proposed originally is better, which is to add the following sentences under 5.5.7. " If this injection point is declared as transient, after bean's passivation, the value will not be restored. Instance<> injection point is the preferred approach. " Thoughts? > Injection point declared as transient is not useful > --------------------------------------------------- > > Key: CDI-616 > URL: https://issues.jboss.org/browse/CDI-616 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > Priority: Minor > Fix For: 2.0 .Final > > > An injection point declared as 'transient' is not useful, due to the fact of after bean's passivation, the transient field will not be reinjected and its value will be lost. This causes confusion. See Weld forum discussion [link title|https://developer.jboss.org/thread/179486]. In the section 5.5.7, how about to make the following changes? > The isTransient() method returns true if the injection point is a transient field, and > false otherwise. If the injection point represents a dynamically obtained instance then the > isTransient() method returns true if the Instance injection point is a transient field, and > false otherwise. > => > The isTransient() method returns true if the injection point is a transient field, and > false otherwise. If the injection point represents a dynamically obtained instance then the > isTransient() method returns true if the Instance injection point is a transient field, and > false otherwise. If this injection point is declared as transient, after bean's passivation, the value will not be restored. Instance injection point is the preferred approach. > Any other better suggestions? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From EMIJIANG at uk.ibm.com Fri Oct 21 04:22:30 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Fri, 21 Oct 2016 09:22:30 +0100 Subject: [cdi-dev] Open PR validation In-Reply-To: References: Message-ID: Thanks Antoine and John! done! 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: John Ament , Emily Jiang/UK/IBM at IBMGB Cc: cdi-dev Date: 20/10/2016 17:04 Subject: Re: [cdi-dev] Open PR validation Sent by: cdi-dev-bounces at lists.jboss.org Emily, As John said, create your fork of the repo and then follow this guide: https://help.github.com/articles/creating-a-pull-request-from-a-fork/ Antoine On Thu, Oct 20, 2016 at 5:53 PM John Ament wrote: You need to fork the repository and push to your fork. From: cdi-dev-bounces at lists.jboss.org on behalf of Emily Jiang Sent: Thursday, October 20, 2016 11:47 AM To: Antoine Sabot-Durand Cc: cdi-dev Subject: Re: [cdi-dev] Open PR validation I'm trying to push my changes on cdi-616, but got the following error message: C:\cdi-2.0\cdi>git push -u origin emily-cdi remote: Permission to cdi-spec/cdi.git denied to Emily-Jiang. fatal: unable to access 'https://github.com/cdi-spec/cdi.git/': The requested URL returned error: 403 Any thoughts on what went wrong? 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: 20/10/2016 09:16 Subject: [cdi-dev] Open PR validation Sent by: cdi-dev-bounces at lists.jboss.org Hi all, As the feature freeze date approach we have a lot of PR pending. Some are big ones and ask a lot of discussion, some are rather obvious. For these PR, I started to merge them if they were 1 week old and have at least one person ok with its content. I'd prefer to have more than one review of these, but we have a schedule to meet. Try to check these small PR to be sure that we don't miss something, but after one week with only positive feedback there will be merged. 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 Info Page - JBoss Developer lists.jboss.org List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives. Apache License, Version 2.0 www.apache.org Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1. Definitions. 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 NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. 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/20161021/b217c441/attachment-0001.html From issues at jboss.org Fri Oct 21 07:13:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 21 Oct 2016 07:13:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310309#comment-13310309 ] Tomas Remes commented on CDI-627: --------------------------------- This will need additional fix - see my comment https://github.com/cdi-spec/cdi/pull/309 > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 .Final > > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 21 08:13:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 21 Oct 2016 08:13:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-449) beans.xml examples are not valid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba reassigned CDI-449: -------------------------------- Assignee: Tomas Remes > beans.xml examples are not valid > -------------------------------- > > Key: CDI-449 > URL: https://issues.jboss.org/browse/CDI-449 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Tomas Remes > Fix For: 2.0 .Final > > > The {{beans.xml}} examples in "5.1.1. Declaring selected alternatives", "8.2.2. Decorator enablement and ordering for a bean archive" and "9.4. Interceptor enablement and ordering" (which contain a reference to beans_1_1.xsd) are not valid - {{bean-discovery-mode}} attribute is required. I think it would be appropriate to specify the version attribute as well. > The last {{beans.xml}} example in "12.4.2. Exclude filters" does not even define the reference to an XSD. Again, I believe the version and bean-discovery-mode attributes should be specified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Fri Oct 21 09:23:27 2016 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 21 Oct 2016 15:23:27 +0200 Subject: [cdi-dev] beans.xml quiz for Friday afternoon Message-ID: <7896708b-5d3c-8971-d2ab-60705f76fb00@redhat.com> Hi all, today I struggled with weird beans.xml parsing problems and I found out that this part of CDI might deserve some clarification. Below are few examples. And not all of them have obvious interpretation. Also note that the spec still contains invalid beans.xml snippets (see also CDI-449). 1. empty beans.xml marker file - spec VALID, bean-discovey-mode="ALL" - XSD validation not needed 2. - spec VALID, bean-discovey-mode="ALL" - XSD validation not possible 3. - spec VALID, Java EE 6 namespace, ie. CDI 1.0, bean-discovey-mode="ALL" - XSD validation OK (against beans_1_0.xsd) 4. - spec VALID - XSD validation ERROR - Java EE 7 namespace, i.e. CDI 1.1+ and bean-discovey-mode attribute is required - note that version is defaulted to "1.1" (and e.g. SAXParser fills this value automatically) - what's the correct bean-discovey-mode? => I would expect ANNOTATED because we're in EE 7 and it's the default bean discovery mode - bean-discovey-mode attribute is required, not defaulted - current Weld behavior: ALL 5. - spec INVALID, "A bean archive which contains a beans.xml file with version 1.1 (or later) must specify the bean-discovey-mode attribute. The default value for the attribute is annotated." - XSD validation ERROR, bean-discovey-mode attribute is required - what's the correct bean-discovey-mode? => I would expect ANNOTATED - current Weld behavior: ALL 6. - spec INVALID, the same as above - XSD validation not possible - what's the correct bean-discovey-mode? => I would expect ANNOTATED - current Weld behavior: ALL 7. - spec VALID, bean-discovey-mode="ANNOTATED" - XSD validation not possible 8. - spec VALID, bean-discovey-mode="ALL" - XSD VALID We may consider adding default value for bean-discovey-mode, and maybe rewording the spec text. But I'm no XML guru so maybe I'm missing something. Thanks, Martin From antoine at sabot-durand.net Fri Oct 21 09:45:24 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 21 Oct 2016 15:45:24 +0200 Subject: [cdi-dev] beans.xml quiz for Friday afternoon In-Reply-To: <7896708b-5d3c-8971-d2ab-60705f76fb00@redhat.com> References: <7896708b-5d3c-8971-d2ab-60705f76fb00@redhat.com> Message-ID: Usually I like quizzes, but this one is a bit harsh for a Friday ;). Since the spec doesn?t say anything about xml validation, I don?t think we can take it into consideration for container behaviour. > Le 21 oct. 2016 ? 15:23, Martin Kouba a ?crit : > > Hi all, > > today I struggled with weird beans.xml parsing problems and I found out > that this part of CDI might deserve some clarification. Below are few > examples. And not all of them have obvious interpretation. > > Also note that the spec still contains invalid beans.xml snippets (see > also CDI-449). Do you mean, there are still invalid snipers after Tomas PR ? > 1. empty beans.xml marker file > - spec VALID, bean-discovey-mode="ALL" > - XSD validation not needed > 2. > - spec VALID, bean-discovey-mode="ALL" > - XSD validation not possible > 3. > - spec VALID, Java EE 6 namespace, ie. CDI 1.0, bean-discovey-mode="ALL" > - XSD validation OK (against beans_1_0.xsd) > > 4. > - spec VALID > - XSD validation ERROR - Java EE 7 namespace, i.e. CDI 1.1+ and > bean-discovey-mode attribute is required > - note that version is defaulted to "1.1" (and e.g. SAXParser fills this > value automatically) > - what's the correct bean-discovey-mode? => I would expect ANNOTATED > because we're in EE 7 and it's the default bean discovery mode > - bean-discovey-mode attribute is required, not defaulted > - current Weld behavior: ALL As I said in introduction I don?t think we can take xsd into consideration to decide container behaviour. So IMO here Weld behaviour is the expected one: "A bean archive which contains a beans.xml file with no version has a default bean discovery mode of all" > > 5. > - spec INVALID, "A bean archive which contains a beans.xml file with > version 1.1 (or later) must specify the bean-discovey-mode attribute. > The default value for the attribute is annotated." > - XSD validation ERROR, bean-discovey-mode attribute is required > - what's the correct bean-discovey-mode? => I would expect ANNOTATED > - current Weld behavior: ALL IMO, deployment should fail or we should rephrase the spec (backward compatibility?) > > 6. > - spec INVALID, the same as above > - XSD validation not possible > - what's the correct bean-discovey-mode? => I would expect ANNOTATED > - current Weld behavior: ALL Same as 5 for me > > 7. > - spec VALID, bean-discovey-mode="ANNOTATED" > - XSD validation not possible > NP > 8. xmlns="http://xmlns.jcp.org/xml/ns/javaee"> > - spec VALID, bean-discovey-mode="ALL" > - XSD VALID > > > We may consider adding default value for bean-discovey-mode, and maybe > rewording the spec text. But I'm no XML guru so maybe I'm missing something. Again we don?t have any mention of valid XML file (regarding XSD) in the spec, so there might be a lot of broken beans.xml file around. Making this straight could break these apps. wdyt ? > Thanks, > > Martin Antoine From tremes at redhat.com Fri Oct 21 10:01:30 2016 From: tremes at redhat.com (Tomas Remes) Date: Fri, 21 Oct 2016 10:01:30 -0400 (EDT) Subject: [cdi-dev] beans.xml quiz for Friday afternoon In-Reply-To: References: <7896708b-5d3c-8971-d2ab-60705f76fb00@redhat.com> Message-ID: <1010672288.5586839.1477058490462.JavaMail.zimbra@redhat.com> Comment inline. T. ----- Original Message ----- From: "Antoine Sabot-Durand" To: "Martin Kouba" Cc: "cdi-dev" Sent: Friday, October 21, 2016 3:45:24 PM Subject: Re: [cdi-dev] beans.xml quiz for Friday afternoon >> Usually I like quizzes, but this one is a bit harsh for a Friday ;). >> Since the spec doesn?t say anything about xml validation, I don?t think we can take it into consideration for container behaviour. > Le 21 oct. 2016 ? 15:23, Martin Kouba a ?crit : > > Hi all, > > today I struggled with weird beans.xml parsing problems and I found out > that this part of CDI might deserve some clarification. Below are few > examples. And not all of them have obvious interpretation. > > Also note that the spec still contains invalid beans.xml snippets (see > also CDI-449). >> Do you mean, there are still invalid snipers after Tomas PR ? > 1. empty beans.xml marker file > - spec VALID, bean-discovey-mode="ALL" > - XSD validation not needed > 2. > - spec VALID, bean-discovey-mode="ALL" > - XSD validation not possible > 3. > - spec VALID, Java EE 6 namespace, ie. CDI 1.0, bean-discovey-mode="ALL" > - XSD validation OK (against beans_1_0.xsd) > > 4. > - spec VALID > - XSD validation ERROR - Java EE 7 namespace, i.e. CDI 1.1+ and > bean-discovey-mode attribute is required > - note that version is defaulted to "1.1" (and e.g. SAXParser fills this > value automatically) > - what's the correct bean-discovey-mode? => I would expect ANNOTATED > because we're in EE 7 and it's the default bean discovery mode > - bean-discovey-mode attribute is required, not defaulted > - current Weld behavior: ALL >> As I said in introduction I don?t think we can take xsd into consideration to decide container behaviour. >> So IMO here Weld behaviour is the expected one: >> "A bean archive which contains a beans.xml file with no version has a default bean discovery mode of all" That was my reasoning as well but note that when you specify beans_1_1.xsd then there is _always_ version 1.1 as Martin pointed out. > > 5. > - spec INVALID, "A bean archive which contains a beans.xml file with > version 1.1 (or later) must specify the bean-discovey-mode attribute. > The default value for the attribute is annotated." > - XSD validation ERROR, bean-discovey-mode attribute is required > - what's the correct bean-discovey-mode? => I would expect ANNOTATED > - current Weld behavior: ALL >> IMO, deployment should fail or we should rephrase the spec (backward compatibility?) > > 6. > - spec INVALID, the same as above > - XSD validation not possible > - what's the correct bean-discovey-mode? => I would expect ANNOTATED > - current Weld behavior: ALL >> Same as 5 for me > > 7. > - spec VALID, bean-discovey-mode="ANNOTATED" > - XSD validation not possible > >> NP > 8. xmlns="http://xmlns.jcp.org/xml/ns/javaee"> > - spec VALID, bean-discovey-mode="ALL" > - XSD VALID > > > We may consider adding default value for bean-discovey-mode, and maybe > rewording the spec text. But I'm no XML guru so maybe I'm missing something. >> Again we don?t have any mention of valid XML file (regarding XSD) in the spec, so there might be a lot of broken beans.xml file around. Making this straight could break these apps. We don't but we have default version="1.1" in beans_1_1.xsd which makes the situation little bit more complicated. Otherwise I agree. >> wdyt ? > Thanks, > > Martin 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. -- Tomas Remes From issues at jboss.org Sat Oct 22 12:15:01 2016 From: issues at jboss.org (Martin Andersson (JIRA)) Date: Sat, 22 Oct 2016 12:15:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-523) CDI spec tries to dispose a container-managed entity manager. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310630#comment-13310630 ] Martin Andersson commented on CDI-523: -------------------------------------- There is one provided on the second link in the post. This example look up an application-managed entity manager (with disposer): {code:java} @RequestScoped public class EntityManagerProducer { @PersistenceUnit EntityManagerFactory factory; @Produces @RequestScoped public EntityManager newEntityManager() { return factory.createEntityManager(); } public void closeEntityManager(@Disposes EntityManager em) { em.close(); } } public class EntityManagerConsumer { @Inject EntityManager em; // ... } {code} > CDI spec tries to dispose a container-managed entity manager. > ------------------------------------------------------------- > > Key: CDI-523 > URL: https://issues.jboss.org/browse/CDI-523 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final, 1.1.Final > Reporter: Martin Andersson > Assignee: John Ament > Fix For: 2.0 .Final > > > Section "3.5.2. Declaring a disposer method" has this example: > {code:java} > public class Resources { > @PersistenceContext > @Produces @UserDatabase > private EntityManager em; > > public void close(@Disposes @UserDatabase EntityManager em) { > em.close(); > } > } > {code} > The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says: > {quote} > The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager. > {quote} > This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java]. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Mon Oct 24 03:55:34 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 24 Oct 2016 09:55:34 +0200 Subject: [cdi-dev] beans.xml quiz for Friday afternoon In-Reply-To: References: <7896708b-5d3c-8971-d2ab-60705f76fb00@redhat.com> Message-ID: Dne 21.10.2016 v 15:45 Antoine Sabot-Durand napsal(a): > Usually I like quizzes, but this one is a bit harsh for a Friday ;). > > Since the spec doesn?t say anything about xml validation, I don?t think we can take it into consideration for container behaviour. Sounds weird. We provide a contract (XSD) but don't require the contract to be fulfilled.. From impl point of view - there might be problems similar to the SAXParser example I mentioned. If you provide an XSD, the tool/library may automatically fill the version with default value. I'm not really sure what to do here. Maybe look at other specs first? > >> Le 21 oct. 2016 ? 15:23, Martin Kouba a ?crit : >> >> Hi all, >> >> today I struggled with weird beans.xml parsing problems and I found out >> that this part of CDI might deserve some clarification. Below are few >> examples. And not all of them have obvious interpretation. >> >> Also note that the spec still contains invalid beans.xml snippets (see >> also CDI-449). > > Do you mean, there are still invalid snipers after Tomas PR ? > >> 1. empty beans.xml marker file >> - spec VALID, bean-discovey-mode="ALL" >> - XSD validation not needed >> 2. >> - spec VALID, bean-discovey-mode="ALL" >> - XSD validation not possible >> 3. >> - spec VALID, Java EE 6 namespace, ie. CDI 1.0, bean-discovey-mode="ALL" >> - XSD validation OK (against beans_1_0.xsd) >> >> 4. >> - spec VALID >> - XSD validation ERROR - Java EE 7 namespace, i.e. CDI 1.1+ and >> bean-discovey-mode attribute is required >> - note that version is defaulted to "1.1" (and e.g. SAXParser fills this >> value automatically) >> - what's the correct bean-discovey-mode? => I would expect ANNOTATED >> because we're in EE 7 and it's the default bean discovery mode >> - bean-discovey-mode attribute is required, not defaulted >> - current Weld behavior: ALL > > As I said in introduction I don?t think we can take xsd into consideration to decide container behaviour. > So IMO here Weld behaviour is the expected one: > > "A bean archive which contains a beans.xml file with no version has a default bean discovery mode of all" > >> >> 5. >> - spec INVALID, "A bean archive which contains a beans.xml file with >> version 1.1 (or later) must specify the bean-discovey-mode attribute. >> The default value for the attribute is annotated." >> - XSD validation ERROR, bean-discovey-mode attribute is required >> - what's the correct bean-discovey-mode? => I would expect ANNOTATED >> - current Weld behavior: ALL > > IMO, deployment should fail or we should rephrase the spec (backward compatibility?) > >> >> 6. >> - spec INVALID, the same as above >> - XSD validation not possible >> - what's the correct bean-discovey-mode? => I would expect ANNOTATED >> - current Weld behavior: ALL > > Same as 5 for me > >> >> 7. >> - spec VALID, bean-discovey-mode="ANNOTATED" >> - XSD validation not possible >> > > NP > >> 8. > xmlns="http://xmlns.jcp.org/xml/ns/javaee"> >> - spec VALID, bean-discovey-mode="ALL" >> - XSD VALID >> >> >> We may consider adding default value for bean-discovey-mode, and maybe >> rewording the spec text. But I'm no XML guru so maybe I'm missing something. > > Again we don?t have any mention of valid XML file (regarding XSD) in the spec, so there might be a lot of broken beans.xml file around. Making this straight could break these apps. > > wdyt ? > >> Thanks, >> >> Martin > > Antoine > From john.ament at spartasystems.com Mon Oct 24 21:27:17 2016 From: john.ament at spartasystems.com (John Ament) Date: Tue, 25 Oct 2016 01:27:17 +0000 Subject: [cdi-dev] Probably late to tomorrow's meeting Message-ID: I'll probably be late, possibly not going to make it. I do want to get a path forward on CDI-30. E.g.: - Changes needed - Clarifications in other sections of the spec John ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161025/b69dc6a4/attachment.html From issues at jboss.org Tue Oct 25 09:23:02 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 25 Oct 2016 09:23:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-631) Improve AnnotationLiteral for empty annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311518#comment-13311518 ] Martin Kouba commented on CDI-631: ---------------------------------- For the record - {{AnnotationLiteral#hashCode()}} is already optimized for annotations with no members (see also https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/util/AnnotationLiteral.java#L66), the same applies to {{#equals()}}. {{#toString()}} is not cached and I don't think it should be (by the way it's not even cached in the referenced OWB's {{EmptyAnnotationLiteral}}). Also I don't think we should cache hashCode and toString for annotations with members - it could work in most cases but it's not 100%. > Improve AnnotationLiteral for empty annotations > ----------------------------------------------- > > Key: CDI-631 > URL: https://issues.jboss.org/browse/CDI-631 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > Annotation hashCode() and equals() operations are fairly expensive as they always invoke getDeclaredMethods() even if there are no such. And getDeclaredMethods involves the SecurityManager + wrapper classes + Exception handling + + + > That's horrible expensive. > In OWB I improved this by introducing an own base class for dynamic annotations which do not have any members: > https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/EmptyAnnotationLiteral.java > The method returns a hardcoded String for toString(), returns hardcoded 0 as hashCode and the equals() method invokes the equals on the annotation type. > We might support this improvements directly in the AnnotationLiteral class or introduce a similar 2nd class especially for empty annotations? -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Wed Oct 26 07:41:02 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 26 Oct 2016 07:41:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-639) Clarify purpose of InjectionPointConfigurator.bean(Bean bean) method In-Reply-To: References: Message-ID: Tomas Remes created CDI-639: ------------------------------- Summary: Clarify purpose of InjectionPointConfigurator.bean(Bean bean) method Key: CDI-639 URL: https://issues.jboss.org/browse/CDI-639 Project: CDI Specification Issues Issue Type: Clarification Components: Portable Extensions Affects Versions: 2.0-EDR2 Reporter: Tomas Remes Dear EG, I would like to ask for clarification of {{javax.enterprise.inject.spi.builder.InjectionPointConfigurator#bean}} method. I am not really sure what's the benefit of this method and what would be the suitable use case for this method. I think using this method when I have my custom bean doesn't have any significant advantage since I can declare set of injection points in my custom bean impl. Maybe I would remove this method from the {{InjectionPointConfigurator}} interface. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Wed Oct 26 07:43:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 26 Oct 2016 07:43:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-639) Clarify purpose of InjectionPointConfigurator.bean(Bean bean) method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Remes updated CDI-639: ---------------------------- Fix Version/s: 2.0 .Final > Clarify purpose of InjectionPointConfigurator.bean(Bean bean) method > ----------------------------------------------------------------------- > > Key: CDI-639 > URL: https://issues.jboss.org/browse/CDI-639 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 2.0-EDR2 > Reporter: Tomas Remes > Fix For: 2.0 .Final > > > Dear EG, > I would like to ask for clarification of {{javax.enterprise.inject.spi.builder.InjectionPointConfigurator#bean}} method. I am not really sure what's the benefit of this method and what would be the suitable use case for this method. > I think using this method when I have my custom bean doesn't have any significant advantage since I can declare set of injection points in my custom bean impl. > Maybe I would remove this method from the {{InjectionPointConfigurator}} interface. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Wed Oct 26 08:39:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 26 Oct 2016 08:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-640) Improve javadoc for SeContainer methods In-Reply-To: References: Message-ID: Tomas Remes created CDI-640: ------------------------------- Summary: Improve javadoc for SeContainer methods Key: CDI-640 URL: https://issues.jboss.org/browse/CDI-640 Project: CDI Specification Issues Issue Type: Bug Components: Java SE Integration Affects Versions: 2.0-EDR2 Reporter: Tomas Remes Priority: Minor Javadoc for following methods doesn't say anything about {{IllegalStateException}} (which is mentioned in the spec text): * {{javax.enterprise.inject.se.SeContainer#close}} * {{javax.enterprise.inject.se.SeContainer#getBeanManager}} -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Wed Oct 26 08:39:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 26 Oct 2016 08:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-640) Improve javadoc for SeContainer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Remes reassigned CDI-640: ------------------------------- Assignee: Tomas Remes > Improve javadoc for SeContainer methods > --------------------------------------- > > Key: CDI-640 > URL: https://issues.jboss.org/browse/CDI-640 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java SE Integration > Affects Versions: 2.0-EDR2 > Reporter: Tomas Remes > Assignee: Tomas Remes > Priority: Minor > Fix For: 2.0 .Final > > > Javadoc for following methods doesn't say anything about {{IllegalStateException}} (which is mentioned in the spec text): > * {{javax.enterprise.inject.se.SeContainer#close}} > * {{javax.enterprise.inject.se.SeContainer#getBeanManager}} -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Wed Oct 26 08:39:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 26 Oct 2016 08:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-640) Improve javadoc for SeContainer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Remes updated CDI-640: ---------------------------- Fix Version/s: 2.0 .Final > Improve javadoc for SeContainer methods > --------------------------------------- > > Key: CDI-640 > URL: https://issues.jboss.org/browse/CDI-640 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java SE Integration > Affects Versions: 2.0-EDR2 > Reporter: Tomas Remes > Assignee: Tomas Remes > Priority: Minor > Fix For: 2.0 .Final > > > Javadoc for following methods doesn't say anything about {{IllegalStateException}} (which is mentioned in the spec text): > * {{javax.enterprise.inject.se.SeContainer#close}} > * {{javax.enterprise.inject.se.SeContainer#getBeanManager}} -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Thu Oct 27 05:59:00 2016 From: issues at jboss.org (=?UTF-8?Q?Bj=C3=B6rn_Kautler_=28JIRA=29?=) Date: Thu, 27 Oct 2016 05:59:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-641) Invalid manifest section in cdi-api JAR In-Reply-To: References: Message-ID: Bj?rn Kautler created CDI-641: --------------------------------- Summary: Invalid manifest section in cdi-api JAR Key: CDI-641 URL: https://issues.jboss.org/browse/CDI-641 Project: CDI Specification Issues Issue Type: Bug Components: Packaging and Deployment Affects Versions: 2.0-EDR2, 1.0 Reporter: Bj?rn Kautler In the {{MANIFEST.MF}} of your {{cdi-api}} JAR you have a section {{Build-Information}}. This violates that JAR specification. A section in the manifest always refers to an entry in the JAR. If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest. ---- In my concrete use-case this happened with other JARs with invalid manifest entries: - I have signed those JARs and included them in a WebStart application - I started the application with 8u102 32-bit {{javaws}} - The JARs were downloaded and their entries signatures verified - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse: - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Thu Oct 27 06:09:00 2016 From: issues at jboss.org (=?UTF-8?Q?Bj=C3=B6rn_Kautler_=28JIRA=29?=) Date: Thu, 27 Oct 2016 06:09:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-641) Invalid manifest section in cdi-api JAR In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bj?rn Kautler updated CDI-641: ------------------------------ Description: In the {{MANIFEST.MF}} of your {{cdi-api}} JAR you have a section {{Build-Information}}. This violates that JAR specification. A section in the manifest always refers to an entry in the JAR. If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest. Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file. ---- In my concrete use-case this happened with other JARs with invalid manifest entries: - I have signed those JARs and included them in a WebStart application - I started the application with 8u102 32-bit {{javaws}} - The JARs were downloaded and their entries signatures verified - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse: - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections. was: In the {{MANIFEST.MF}} of your {{cdi-api}} JAR you have a section {{Build-Information}}. This violates that JAR specification. A section in the manifest always refers to an entry in the JAR. If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest. ---- In my concrete use-case this happened with other JARs with invalid manifest entries: - I have signed those JARs and included them in a WebStart application - I started the application with 8u102 32-bit {{javaws}} - The JARs were downloaded and their entries signatures verified - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse: - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections. > Invalid manifest section in cdi-api JAR > --------------------------------------- > > Key: CDI-641 > URL: https://issues.jboss.org/browse/CDI-641 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: 1.0, 2.0-EDR2 > Reporter: Bj?rn Kautler > > In the {{MANIFEST.MF}} of your {{cdi-api}} JAR you have a section {{Build-Information}}. > This violates that JAR specification. > A section in the manifest always refers to an entry in the JAR. > If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest. > Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file. > ---- > In my concrete use-case this happened with other JARs with invalid manifest entries: > - I have signed those JARs and included them in a WebStart application > - I started the application with 8u102 32-bit {{javaws}} > - The JARs were downloaded and their entries signatures verified > - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed > This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse: > - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM > - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again > - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between > - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution > Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Thu Oct 27 06:39:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Thu, 27 Oct 2016 06:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-641) Invalid manifest section in cdi-api JAR In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312878#comment-13312878 ] Tomas Remes commented on CDI-641: --------------------------------- Hi, You are likely true that this section is not valid according to manifest specification (was looking at https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html). I was wondering where this comes from and finally discovered this definition in weld-parent pom (see related issue). > Invalid manifest section in cdi-api JAR > --------------------------------------- > > Key: CDI-641 > URL: https://issues.jboss.org/browse/CDI-641 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: 1.0, 2.0-EDR2 > Reporter: Bj?rn Kautler > > In the {{MANIFEST.MF}} of your {{cdi-api}} JAR you have a section {{Build-Information}}. > This violates that JAR specification. > A section in the manifest always refers to an entry in the JAR. > If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest. > Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file. > ---- > In my concrete use-case this happened with other JARs with invalid manifest entries: > - I have signed those JARs and included them in a WebStart application > - I started the application with 8u102 32-bit {{javaws}} > - The JARs were downloaded and their entries signatures verified > - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed > This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse: > - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM > - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again > - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between > - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution > Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Thu Oct 27 06:42:00 2016 From: issues at jboss.org (=?UTF-8?Q?Bj=C3=B6rn_Kautler_=28JIRA=29?=) Date: Thu, 27 Oct 2016 06:42:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-641) Invalid manifest section in cdi-api JAR In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312884#comment-13312884 ] Bj?rn Kautler commented on CDI-641: ----------------------------------- Yep, most older JBoss libs that us jboss-parent 6 or 7 have the same problem. In jboss-parent 8 and newer this is fixed by adding the information to the main section instead of to an own section. :-) > Invalid manifest section in cdi-api JAR > --------------------------------------- > > Key: CDI-641 > URL: https://issues.jboss.org/browse/CDI-641 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: 1.0, 2.0-EDR2 > Reporter: Bj?rn Kautler > > In the {{MANIFEST.MF}} of your {{cdi-api}} JAR you have a section {{Build-Information}}. > This violates that JAR specification. > A section in the manifest always refers to an entry in the JAR. > If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest. > Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file. > ---- > In my concrete use-case this happened with other JARs with invalid manifest entries: > - I have signed those JARs and included them in a WebStart application > - I started the application with 8u102 32-bit {{javaws}} > - The JARs were downloaded and their entries signatures verified > - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed > This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse: > - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM > - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again > - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between > - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution > Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Thu Oct 27 07:11:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Thu, 27 Oct 2016 07:11:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-641) Invalid manifest section in cdi-api JAR In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312902#comment-13312902 ] Tomas Remes commented on CDI-641: --------------------------------- [~vampire] I see. Can you please check if https://github.com/weld/parent/pull/6 can solve your issue? Thank's in advance. > Invalid manifest section in cdi-api JAR > --------------------------------------- > > Key: CDI-641 > URL: https://issues.jboss.org/browse/CDI-641 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: 1.0, 2.0-EDR2 > Reporter: Bj?rn Kautler > > In the {{MANIFEST.MF}} of your {{cdi-api}} JAR you have a section {{Build-Information}}. > This violates that JAR specification. > A section in the manifest always refers to an entry in the JAR. > If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest. > Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file. > ---- > In my concrete use-case this happened with other JARs with invalid manifest entries: > - I have signed those JARs and included them in a WebStart application > - I started the application with 8u102 32-bit {{javaws}} > - The JARs were downloaded and their entries signatures verified > - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed > This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse: > - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM > - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again > - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between > - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution > Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Thu Oct 27 09:49:00 2016 From: issues at jboss.org (=?UTF-8?Q?Bj=C3=B6rn_Kautler_=28JIRA=29?=) Date: Thu, 27 Oct 2016 09:49:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-641) Invalid manifest section in cdi-api JAR In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313032#comment-13313032 ] Bj?rn Kautler commented on CDI-641: ----------------------------------- Yes, I think so. If that PR gets applied and all use the new parent (for me it is cdi-api and weld-se), then it should be fine. > Invalid manifest section in cdi-api JAR > --------------------------------------- > > Key: CDI-641 > URL: https://issues.jboss.org/browse/CDI-641 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: 1.0, 2.0-EDR2 > Reporter: Bj?rn Kautler > > In the {{MANIFEST.MF}} of your {{cdi-api}} JAR you have a section {{Build-Information}}. > This violates that JAR specification. > A section in the manifest always refers to an entry in the JAR. > If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest. > Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file. > ---- > In my concrete use-case this happened with other JARs with invalid manifest entries: > - I have signed those JARs and included them in a WebStart application > - I started the application with 8u102 32-bit {{javaws}} > - The JARs were downloaded and their entries signatures verified > - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed > This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse: > - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM > - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again > - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between > - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution > Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Thu Oct 27 13:30:00 2016 From: issues at jboss.org (Laird Nelson (JIRA)) Date: Thu, 27 Oct 2016 13:30:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-641) Invalid manifest section in cdi-api JAR In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313167#comment-13313167 ] Laird Nelson commented on CDI-641: ---------------------------------- Where in the manifest specification does it state that per-entry attributes must have a corresponding jar file entry? I read this: bq. Per-entry attributes apply only to the individual JAR file entry to which the manifest entry is associated with. Rephrased so it is valid English: bq. Per-entry attributes apply only to the individual JAR file entry with which the manifest entry is associated. Then a {{Build-Info}} manifest per-entry attribute would apply only to a {{Build-Info}} jar file entry. Let us suppose that no such entry exists. Does this render the {{Build-Info}} per-entry attribute invalid? I don't read it that way. I read this as saying only: the {{Build-Info}} per-entry attribute _would_ apply to a jar file entry named {{Build-Info}}, but since no such entry exists, this per-entry attribute has undefined behavior, which is of course exactly what it's being used for at the moment. (I have no stake in the presence or absence of this particular per-entry attribute, nor in this bug. I just want to make sure that I am properly understanding the manifest specification in this regard.) > Invalid manifest section in cdi-api JAR > --------------------------------------- > > Key: CDI-641 > URL: https://issues.jboss.org/browse/CDI-641 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: 1.0, 2.0-EDR2 > Reporter: Bj?rn Kautler > > In the {{MANIFEST.MF}} of your {{cdi-api}} JAR you have a section {{Build-Information}}. > This violates that JAR specification. > A section in the manifest always refers to an entry in the JAR. > If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest. > Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file. > ---- > In my concrete use-case this happened with other JARs with invalid manifest entries: > - I have signed those JARs and included them in a WebStart application > - I started the application with 8u102 32-bit {{javaws}} > - The JARs were downloaded and their entries signatures verified > - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed > This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse: > - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM > - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again > - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between > - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution > Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Thu Oct 27 20:26:00 2016 From: issues at jboss.org (=?UTF-8?Q?Bj=C3=B6rn_Kautler_=28JIRA=29?=) Date: Thu, 27 Oct 2016 20:26:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-641) Invalid manifest section in cdi-api JAR In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313239#comment-13313239 ] Bj?rn Kautler commented on CDI-641: ----------------------------------- [~ljnelson] well, there maybe is room for interpretation, but let me also quote another sentence from the spec a bit above yours: {quote}The individual sections define various attributes for packages or files contained in this JAR file. [...] Each section must start with an attribute with the name as "Name", and the value must be a relative path to the file, or an absolute URL referencing data outside the archive.{quote} I interpret this in a way that means if the section id is not an absolute URL, the folder or file has to exist in the JAR, if not it is considered missing and thus tampered with. But I may interpret it wrongly of course. But even if I interpret it wrongly, having such dummy sections has just negative effects (more RAM needed, more CPU needed, more IO needed, triggering bugs unnecessarily :-) ), while it does not really gain much. How often did you look at a manifest to get such a piece of information and would it be that much harder to read it from the main section instead of from a dedicated section? > Invalid manifest section in cdi-api JAR > --------------------------------------- > > Key: CDI-641 > URL: https://issues.jboss.org/browse/CDI-641 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: 1.0, 2.0-EDR2 > Reporter: Bj?rn Kautler > > In the {{MANIFEST.MF}} of your {{cdi-api}} JAR you have a section {{Build-Information}}. > This violates that JAR specification. > A section in the manifest always refers to an entry in the JAR. > If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest. > Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file. > ---- > In my concrete use-case this happened with other JARs with invalid manifest entries: > - I have signed those JARs and included them in a WebStart application > - I started the application with 8u102 32-bit {{javaws}} > - The JARs were downloaded and their entries signatures verified > - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed > This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse: > - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM > - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again > - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between > - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution > Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Sat Oct 29 10:26:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sat, 29 Oct 2016 10:26:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-642) Allow defining interceptor binding or qualifier via an AnnotatedTypeConfigurator in BeforeBeandiscovery In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-642: ---------------------------------------- Summary: Allow defining interceptor binding or qualifier via an AnnotatedTypeConfigurator in BeforeBeandiscovery Key: CDI-642 URL: https://issues.jboss.org/browse/CDI-642 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 2.0-EDR2 Reporter: Antoine Sabot-Durand We should consider adding a new version of {{BeforeBeanDiscovery.addInterceptorBinding()}} and {{BeforeBeanDiscovery.addQualifier()}} methods returning an {{AnnotatedTypeConfigurator}} to ease addition of of 3rd party annotation as interceptor binding or qualifier. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Sat Oct 29 10:27:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sat, 29 Oct 2016 10:27:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-642) Allow defining interceptor binding or qualifier via an AnnotatedTypeConfigurator in BeforeBeandiscovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-642: ------------------------------------- Fix Version/s: 2.0 .Final > Allow defining interceptor binding or qualifier via an AnnotatedTypeConfigurator in BeforeBeandiscovery > -------------------------------------------------------------------------------------------------------- > > Key: CDI-642 > URL: https://issues.jboss.org/browse/CDI-642 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0-EDR2 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > We should consider adding a new version of {{BeforeBeanDiscovery.addInterceptorBinding()}} and {{BeforeBeanDiscovery.addQualifier()}} methods returning an {{AnnotatedTypeConfigurator}} to ease addition of of 3rd party annotation as interceptor binding or qualifier. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Sat Oct 29 11:34:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sat, 29 Oct 2016 11:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-643) Provide a way to easily configure injection point of an InjectionTarget In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-643: ---------------------------------------- Summary: Provide a way to easily configure injection point of an InjectionTarget Key: CDI-643 URL: https://issues.jboss.org/browse/CDI-643 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Antoine Sabot-Durand Creating an {{InjectionTarget}} requires an AnnotatedType. It is often convenient to create a custom {{AnnotatedType}} to add injection points in it (i.e. add {{@Inject}} on fields or methods). We Introduced the {{AnnotatedTypeConfigurator}} helper but didn't provide a way to use it to create an {{InjectionTarget}}. I think we should add {{BeanManager.createAnnotatedTypeConfigurator()}} to solve this and perhaps simplify other places where we could use an {{AnnotatedTypeConfigurator}} like in CDI-642 -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Sat Oct 29 11:34:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sat, 29 Oct 2016 11:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-643) Provide a way to easily configure injection point of an InjectionTarget In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-643: ------------------------------------- Fix Version/s: 2.0 .Final > Provide a way to easily configure injection point of an InjectionTarget > ----------------------------------------------------------------------- > > Key: CDI-643 > URL: https://issues.jboss.org/browse/CDI-643 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Creating an {{InjectionTarget}} requires an AnnotatedType. It is often convenient to create a custom {{AnnotatedType}} to add injection points in it (i.e. add {{@Inject}} on fields or methods). > We Introduced the {{AnnotatedTypeConfigurator}} helper but didn't provide a way to use it to create an {{InjectionTarget}}. > I think we should add {{BeanManager.createAnnotatedTypeConfigurator()}} to solve this and perhaps simplify other places where we could use an {{AnnotatedTypeConfigurator}} like in CDI-642 -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Mon Oct 31 06:01:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 31 Oct 2016 06:01:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-643) Provide a way to easily configure injection point of an InjectionTarget In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314014#comment-13314014 ] Matej Novotny commented on CDI-643: ----------------------------------- bq. I think we should add BeanManager.createAnnotatedTypeConfigurator() I think this relates to lengthy conversations we had around {{Configurators}} and their usage outside of container lifecycle events. I think there were some implementation challenges which limited us in this way. > Provide a way to easily configure injection point of an InjectionTarget > ----------------------------------------------------------------------- > > Key: CDI-643 > URL: https://issues.jboss.org/browse/CDI-643 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Creating an {{InjectionTarget}} requires an AnnotatedType. It is often convenient to create a custom {{AnnotatedType}} to add injection points in it (i.e. add {{@Inject}} on fields or methods). > We Introduced the {{AnnotatedTypeConfigurator}} helper but didn't provide a way to use it to create an {{InjectionTarget}}. > I think we should add {{BeanManager.createAnnotatedTypeConfigurator()}} to solve this and perhaps simplify other places where we could use an {{AnnotatedTypeConfigurator}} like in CDI-642 -- This message was sent by Atlassian JIRA (v7.2.2#72004)