February 2014 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-404) adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated"

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-404?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand edited comment on CDI-404 at 2/26/14 9:17 AM: ------------------------------------------------------------------- As CDI-377 is now focused on redefining list of bean defining annotations, I added it as a dependency of this ticket. To avoid a new CDI-377, I checked that the 3 big frameworks implementing JSR-330 : * Guice (and Maven3 new extension mechanism), * Spring, * Dagger, don't implement Interceptor Spec as well. So I can tell they don't use {{@Interceptor}} annotation so it is safe to add it to the list of bean defining annotations. There is no such problem regarding {{@Decorator}} since it's part of CDI spec. I'll change PR 208 to include this ticket. was (Author: antoinesabot-durand): As CDI-377 is now focused on redefining list of bean defining annotations, I added it as a dependency of this ticket. To avoid a new CDI-377, I checked that the 3 big frameworks implementing JSR-330 : * Guice (and Maven3 new extension mechanism), * Spring, * Dagger, to be sure they don't implement Interceptor Spec as well. So I can tell they don't use {{@Interceptor}} annotation so it is safe to add it to the list of bean defining annotations. There is no such problem regarding {{@Decorator}} since it's part of CDI spec. I'll change PR 208 to include this ticket. > adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" > ----------------------------------------------------------------------------------------------- > > Key: CDI-404 > URL: https://issues.jboss.org/browse/CDI-404 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.1.PFD > Reporter: Tang Yong > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > [1] and [2] has reported an issue about > bean-discovery-mode="annotated". Although there are some workarounds for > the issue, I think that in the future, we should support interceptor > implict scanning while an user uses bean-discovery-mode="annotated". > Apparently, just as bean-discovery-mode="annotated", CDI Spec and > Interceptor Spec are disconnected. > [1]:https://java.net/jira/browse/GLASSFISH-20667 > [2]:http://stackoverflow.com/questions/17258639/interceptor-issue-with-jav... > About detailed discussion, please seeing the following, > https://java.net/projects/javaee-spec/lists/users/archive/2013-09/message/7 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-404) adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated"

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-404?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand edited comment on CDI-404 at 2/26/14 9:16 AM: ------------------------------------------------------------------- As CDI-377 is now focused on redefining list of bean defining annotations, I added it as a dependency of this ticket. To avoid a new CDI-377, I checked that the 3 big frameworks implementing JSR-330 : * Guice (and Maven3 new extension mechanism), * Spring, * Dagger, to be sure they don't implement Interceptor Spec as well. So I can tell they don't use {{@Interceptor}} annotation so it is safe to add it to the list of bean defining annotations. There is no such problem regarding {{@Decorator}} since it's part of CDI spec. I'll change PR 208 to include this ticket. was (Author: antoinesabot-durand): As CDI-377 is now focused on redefining list of bean defining annotations, I added it as a dependency of this ticket. To avoid compatibility issues with existing JSR-330 implementing framework (issue describe in CDI-377). I checked that the 3 big framework implementing JSR-330 : * Guice (and Maven3 new extension mechanism), * Spring, * Dagger, to be sure they don't implement Interceptor Spec as well. So I can tell they don't use {{@Interceptor}} annotation so it is safe to add it to the list of bean defining annotations. There is no such problem regarding {{@Decorator}} since it's part of CDI spec. I'll change PR 208 to include this ticket. > adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" > ----------------------------------------------------------------------------------------------- > > Key: CDI-404 > URL: https://issues.jboss.org/browse/CDI-404 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.1.PFD > Reporter: Tang Yong > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > [1] and [2] has reported an issue about > bean-discovery-mode="annotated". Although there are some workarounds for > the issue, I think that in the future, we should support interceptor > implict scanning while an user uses bean-discovery-mode="annotated". > Apparently, just as bean-discovery-mode="annotated", CDI Spec and > Interceptor Spec are disconnected. > [1]:https://java.net/jira/browse/GLASSFISH-20667 > [2]:http://stackoverflow.com/questions/17258639/interceptor-issue-with-jav... > About detailed discussion, please seeing the following, > https://java.net/projects/javaee-spec/lists/users/archive/2013-09/message/7 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-404) adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated"

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-404?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-404: ------------------------------------------ As CDI-377 is now focused on redefining list of bean defining annotations, I added it as a dependency of this ticket. To avoid compatibility issues with existing JSR-330 implementing framework (issue describe in CDI-377). I checked that the 3 big framework implementing JSR-330 : * Guice (and Maven3 new extension mechanism), * Spring, * Dagger, to be sure they don't implement Interceptor Spec as well. So I can tell they don't use {{@Interceptor}} annotation so it is safe to add it to the list of bean defining annotations. There is no such problem regarding {{@Decorator}} since it's part of CDI spec. I'll change PR 208 to include this ticket. > adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" > ----------------------------------------------------------------------------------------------- > > Key: CDI-404 > URL: https://issues.jboss.org/browse/CDI-404 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.1.PFD > Reporter: Tang Yong > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > [1] and [2] has reported an issue about > bean-discovery-mode="annotated". Although there are some workarounds for > the issue, I think that in the future, we should support interceptor > implict scanning while an user uses bean-discovery-mode="annotated". > Apparently, just as bean-discovery-mode="annotated", CDI Spec and > Interceptor Spec are disconnected. > [1]:https://java.net/jira/browse/GLASSFISH-20667 > [2]:http://stackoverflow.com/questions/17258639/interceptor-issue-with-jav... > About detailed discussion, please seeing the following, > https://java.net/projects/javaee-spec/lists/users/archive/2013-09/message/7 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-404) adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated"

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-404?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand edited comment on CDI-404 at 2/26/14 9:15 AM: ------------------------------------------------------------------- As CDI-377 is now focused on redefining list of bean defining annotations, I added it as a dependency of this ticket. To avoid compatibility issues with existing JSR-330 implementing framework (issue describe in CDI-377). I checked that the 3 big framework implementing JSR-330 : * Guice (and Maven3 new extension mechanism), * Spring, * Dagger, to be sure they don't implement Interceptor Spec as well. So I can tell they don't use {{@Interceptor}} annotation so it is safe to add it to the list of bean defining annotations. There is no such problem regarding {{@Decorator}} since it's part of CDI spec. I'll change PR 208 to include this ticket. was (Author: antoinesabot-durand): As CDI-377 is now focused on redefining list of bean defining annotations, I added it as a dependency of this ticket. To avoid compatibility issues with existing JSR-330 implementing framework (issue describe in CDI-377). I checked that the 3 big framework implementing JSR-330 : * Guice (and Maven3 new extension mechanism), * Spring, * Dagger, to be sure they don't implement Interceptor Spec as well. So I can tell they don't use {{@Interceptor}} annotation so it is safe to add it to the list of bean defining annotations. There is no such problem regarding {{@Decorator}} since it's part of CDI spec. I'll change PR 208 to include this ticket. > adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" > ----------------------------------------------------------------------------------------------- > > Key: CDI-404 > URL: https://issues.jboss.org/browse/CDI-404 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.1.PFD > Reporter: Tang Yong > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > [1] and [2] has reported an issue about > bean-discovery-mode="annotated". Although there are some workarounds for > the issue, I think that in the future, we should support interceptor > implict scanning while an user uses bean-discovery-mode="annotated". > Apparently, just as bean-discovery-mode="annotated", CDI Spec and > Interceptor Spec are disconnected. > [1]:https://java.net/jira/browse/GLASSFISH-20667 > [2]:http://stackoverflow.com/questions/17258639/interceptor-issue-with-jav... > About detailed discussion, please seeing the following, > https://java.net/projects/javaee-spec/lists/users/archive/2013-09/message/7 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

Updated Invitation: CDI 1.2 MR meeting @ Weekly from 6pm to 7pm on Monday from Mon Jan 27 to Mon Mar 31 (Perso)

by antoine.sabotdurand＠gmail.com

This event has been changed. Title: CDI 1.2 MR meeting Proposed agenda : - Ready to fix review and assignation - Discussion on other ticket - Progess and obstacles View your event at http://www.google.com/calendar/event?action=VIEW&eid=XzhjbzQyZGE2ODUzNDJi.... When: Weekly from 6pm to 7pm on Monday from Mon Jan 27 to Mon Mar 31 Paris (changed) Where: IRC #jsr346 Channel on Freenode Calendar: Perso Who: (Guest list has been hidden at organizer's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=XzhjbzQyZGE2ODUzNDJ... Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev(a)lists.jboss.org because you are an attendee of this event. To stop receiving future notifications 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.

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand edited comment on CDI-392 at 2/26/14 8:06 AM: ------------------------------------------------------------------- {quote} Well, there is nothing in the API which says that this is optional for the BeanManager. {quote} If I look at the javadoc of {{getBeans(Type beanType, Annotation... qualifiers)}} at the end I read {quote} *Throws :* *IllegalStateException* - if called during application initialization, before the AfterDeploymentValidation event is fired The container is permitted to define a non-portable mode in which getBeans(Type, Annotation...) may be called from an observer of the AfterBeanDiscovery event. {quote} My understanding was that it's not allowed but that an implementation is allowed to define a non-portable behavior by allowing the call after AfterBeanDiscovery event is fired. >From what you say [~struberg], I understand that I misunderstood that point. So why don't we forbid definitively call to these operations before AfterDeploymentValidation event to avoid junior developers to create futur bugs ? was (Author: antoinesabot-durand): {quote} Well, there is nothing in the API which says that this is optional for the BeanManager. {quote} If I look at the javadoc of `getBeans(Type beanType, Annotation... qualifiers)` at the end I read {quote} *Throws :* *IllegalStateException* - if called during application initialization, before the AfterDeploymentValidation event is fired The container is permitted to define a non-portable mode in which getBeans(Type, Annotation...) may be called from an observer of the AfterBeanDiscovery event. {quote} My understanding was that it's not allowed but that an implementation is allowed to define a non-portable behavior by allowing the call after AfterBeanDiscovery event is fired. >From what you say [~struberg], I understand that I misunderstood that point. So why don't we forbid definitively call to these operations before AfterDeploymentValidation event to avoid junior developers to create futur bugs ? > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-392: ----------------------------------- Ah oki, well didn't see that this is optional. In that case the non-portable wording is fine. I also agree about thinking whether we remove this non-portable thingy. It's really just broken. > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-392: ------------------------------------------ {quote} Well, there is nothing in the API which says that this is optional for the BeanManager. {quote} If I look at the javadoc of `getBeans(Type beanType, Annotation... qualifiers)` at the end I read {quote} *Throws :* *IllegalStateException* - if called during application initialization, before the AfterDeploymentValidation event is fired The container is permitted to define a non-portable mode in which getBeans(Type, Annotation...) may be called from an observer of the AfterBeanDiscovery event. {quote} My understanding was that it's not allowed but that an implementation is allowed to define a non-portable behavior by allowing the call after AfterBeanDiscovery event is fired. >From what you say [~struberg], I understand that I misunderstood that point. So why don't we forbid definitively call to these operations before AfterDeploymentValidation event to avoid junior developers to create futur bugs ? > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-404) adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated"

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-404?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand reassigned CDI-404: ---------------------------------------- Assignee: Antoine Sabot-Durand > adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" > ----------------------------------------------------------------------------------------------- > > Key: CDI-404 > URL: https://issues.jboss.org/browse/CDI-404 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.1.PFD > Reporter: Tang Yong > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > [1] and [2] has reported an issue about > bean-discovery-mode="annotated". Although there are some workarounds for > the issue, I think that in the future, we should support interceptor > implict scanning while an user uses bean-discovery-mode="annotated". > Apparently, just as bean-discovery-mode="annotated", CDI Spec and > Interceptor Spec are disconnected. > [1]:https://java.net/jira/browse/GLASSFISH-20667 > [2]:http://stackoverflow.com/questions/17258639/interceptor-issue-with-jav... > About detailed discussion, please seeing the following, > https://java.net/projects/javaee-spec/lists/users/archive/2013-09/message/7 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-408) bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand reassigned CDI-408: ---------------------------------------- Assignee: Antoine Sabot-Durand > bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans > --------------------------------------------------------------------------- > > Key: CDI-408 > URL: https://issues.jboss.org/browse/CDI-408 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Reporter: Jens Schumann > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge > Fix For: 1.2 Proposed > > > Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly. > However there are two impacts: > 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere. > 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere. > I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier. > If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD. > -- > [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;) > > Btw: Which JIRA version is CDI 1.1 Final? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev February 2014