[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 commented on CDI-408:
------------------------------------------
[~pmuir] I'm not a big fan ever but in fact I'm not a big fan of the annotated mode and this is linked to it. That said I really think we should try to avoid option 3 IMO. Or at least request that the impl logs the list of ignored class in annotated mode.
> 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, 1 month
[JBoss JIRA] (CDI-408) bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-408:
-------------------------------
I have to say that from a functional perspective I am quite ambivalent about this feature.
> 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, 1 month
@New deprecation: when will be "real"
by Luc
Hi!
I've been using CDI-1.0 for a long time, and one of the features used in my
project is @New qualifier.
A few weeks ago I migrated to CDI-1.1, but was principal for performance
promises than features. I didn't found anything really different (except
extensions), so you all woked relly good with the backward compatiblity :)
But today, I got to the @New section of docs, where it is told that the
annotation is deprecated.
It is planed in which release will be deleted the annotation, and its
associated functionality? Or not yet?
Thanks!
--
Lucas
10 years, 1 month
[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 edited comment on CDI-408 at 3/11/14 4:46 AM:
-------------------------------------------------------------------
Honestly I don't understand [~struberg]. Today in CDI 1.0 and in CDI 1.1 with {{bean-discovery-mode=all}} mode we do these deep class analysis. So the code is already there in implementations. Ok, it probably has to be adapted but I don't see where is the "much more work" in term of dev.
Solution at the impl level are multiple :
* Start as if we where in {{bean-discovery-mode=all}} and use the same mechanism that reject non eligible class (after finding no default constructor for instance) or that {{@Vetoed}} it, if it doesn't contain bean defining annotation
* Use annotation processing to decide at compile time.
My understanding of the {{annotated}} bean discovery mode is not about optimization, it's about CDI automatic activation. If it's optimized it's better but the first goal is to provide CDI implicitly. For me it's not important if the {{annotated}} bean discovery mode take the same amount of time at boot time than {{all}} bean-discovery-mode and that's the only risk we take here in term of "much more work".
IMO The real question is "does this feature is interesting for the end user ?" and then "how much does it costs in terms of dev and perf ?".
In this particular case I won't say the feature is awesome but the lack of it is very not user friendly.
We have zillion forum post and stack exchange "bug" out there about CDI 1.0 users forgetting {{beans.xml}} in their app. Now that we provide the mean in CDI 1.1+ to get rid of this file I really think we should do it as complete as possible.
Regarding the producer method in superclass, I'm not sure to totally understand your use case. Can you give an example ?
was (Author: antoinesabot-durand):
Honestly I don't understand [~struberg]. Today in CDI 1.0 and in CDI 1.1 with {{bean-discovery-mode=all}} mode we do these deep class analysis. So the code is already there in implementations. Ok, it probably has to be adapted but it don't see where is the "much more work" in term of dev.
Solution at the impl level are multiple :
* Start as if we where in {{bean-discovery-mode=all}} and use the same mechanism that reject non eligible class (after finding no default constructor for instance) or that {{@Vetoed}} it, if it doesn't contain bean defining annotation
* Use annotation processing to decide at compile time.
My understanding of the {{annotated}} bean discovery mode is not about optimization, it's about CDI automatic activation. If it's optimized it's better but the first goal is to provide CDI implicitly. For me it's not important if the {{annotated}} bean discovery mode take the same amount of time at boot time than {{all}} bean-discovery-mode and that's the only risk we take here in term of "much more work".
IMO The real question is "does this feature is interesting for the end user ?" and then "how much does it costs in terms of dev and perf ?".
In this particular case I won't say the feature is awesome but the lack of it is very not user friendly.
We have zillion forum post and stack exchange "bug" out there about CDI 1.0 users forgetting {{beans.xml}} in their app. Now that we provide the mean in CDI 1.1+ to get rid of this file I really think we should do it as complete as possible.
Regarding the producer method in superclass, I'm not sure to totally understand your use case. Can you give an example ?
> 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, 1 month
[JBoss JIRA] (CDI-408) bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-408:
-------------------------------------
{quote}You should also think about what happens with a producer method which is contained in a super class.{quote}
I think that if we go with option 1 we should only detect classes that declare an observer/producer method. This would be consistent with how we treat bean defining annotations now where we require them to be declared on a class (if they are inherited that is not enough).
> 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, 1 month
[JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-392:
-------------------------------------
Kind of backwards compatibility with CDI 1.0 where there were no rules of when a BM method may be called.
> 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, 1 month
[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 commented on CDI-408:
------------------------------------------
Honestly I don't understand [~struberg]. Today in CDI 1.0 and in CDI 1.1 with {{bean-discovery-mode=all}} mode we do these deep class analysis. So the code is already there in implementations. Ok, it probably has to be adapted but it don't see where is the "much more work" in term of dev.
Solution at the impl level are multiple :
* Start as if we where in {{bean-discovery-mode=all}} and use the same mechanism that reject non eligible class (after finding no default constructor for instance) or that {{@Vetoed}} it, if it doesn't contain bean defining annotation
* Use annotation processing to decide at compile time.
My understanding of the {{annotated}} bean discovery mode is not about optimization, it's about CDI automatic activation. If it's optimized it's better but the first goal is to provide CDI implicitly. For me it's not important if the {{annotated}} bean discovery mode take the same amount of time at boot time than {{all}} bean-discovery-mode and that's the only risk we take here in term of "much more work".
IMO The real question is "does this feature is interesting for the end user ?" and then "how much does it costs in terms of dev and perf ?".
In this particular case I won't say the feature is awesome but the lack of it is very not user friendly.
We have zillion forum post and stack exchange "bug" out there about CDI 1.0 users forgetting {{beans.xml}} in their app. Now that we provide the mean in CDI 1.1+ to get rid of this file I really think we should do it as complete as possible.
Regarding the producer method in superclass, I'm not sure to totally understand your use case. Can you give an example ?
> 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, 1 month
[JBoss JIRA] (CDI-408) bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-408:
-----------------------------------
extending the bean defining annotations with annotations from the class itself is no problem. But having to go into the class and define producer methods or fields, etc as bean defining would be much more work.
You should also think about what happens with a producer method which is contained in a super class. Does that mean we should pick up the child class as dependent scoped?
Imo we should have a few very clear rules. Not too many rules and not too complex ones. If a user expects a class to get picked up is only a matter the learning curve ;)
> 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, 1 month
[JBoss JIRA] (CDI-426) Clarify the applied scope of an extension.
by John Ament (JIRA)
John Ament created CDI-426:
------------------------------
Summary: Clarify the applied scope of an extension.
Key: CDI-426
URL: https://issues.jboss.org/browse/CDI-426
Project: CDI Specification Issues
Issue Type: Clarification
Components: Portable Extensions
Affects Versions: 1.1.PFD
Reporter: John Ament
Clarify that a portable extension is applied to an entire application, rather than inferring that it's scope is application scoped.
--
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, 1 month
[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 edited comment on CDI-408 at 3/10/14 12:46 PM:
--------------------------------------------------------------------
Thanks [~jason.greene] and [~pmuir] .
That means that we should enhanced the list of _bean defining annotations_ by adding {{@Observes}} and {{@Produces}} to them and introduce the fact that _bean defining annotations_ can be *inside* a class.
Is it ok for everyone?
was (Author: antoinesabot-durand):
Thanks [~jason.greene] and [~pmuir] .
That means that we should enhanced the list of _bean defining annotations_ by adding {{@Observes}} and {{@Produces}} to them and introduce the fact that _bean defining annotations_ can be *inside* a class.
Is it ok for everyone?
And last question what about {{@Observes(notifyObserver = Reception.IF_EXISTS)}}?
> 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, 1 month
