[JBoss JIRA] (CDI-427) Review all annotations for inclusion to bean defining annotations
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-427?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-427:
-------------------------------------
Labels: CDI_spec_chge CDI_tck_chge (was: )
> Review all annotations for inclusion to bean defining annotations
> -----------------------------------------------------------------
>
> Key: CDI-427
> URL: https://issues.jboss.org/browse/CDI-427
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Affects Versions: 1.1.FD
> Reporter: Jozef Hartinger
> Labels: CDI_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> The CDI spec change, which adds @Interceptor, @Decorator and stereotypes to the set of bean defining annotations, was merged. This made me think whether this approach where we add annotations based on demand is the right one. Instead, I think we should review all the annotations defined in the CDI API and evaluate if it makes to have them as bean defining annotations. I think that this would yield more consistent and less ad-hoc result.
> Two candidates that come to mind are @Alternative and @Specializes.
> This issue depends on the resolution of CDI-408
--
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, 9 months
[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:
------------------------------------------
Since the behavior of these extension is not predictable on Weld 2.x, wouldn't be a better idea to remove the mention and the support (don't even know if Weld 2.x implement this non portable behavior) to make things clear ? Correct me if I'm wrong but Seam Solder is deprecated ?
> 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, 9 months
[JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-280:
----------------------------------
+1 for postponing
> 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: 1.2 Proposed
>
>
> 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<T> extends Contextual<T>. 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 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, 9 months
[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}This subclass will not get picked up if we don't look up in the class hierarchy.{quote}
I find the fact that only classes that declare a bean defining annotation within their definition are picked up quite easy to grasp by application developers.
{quote}There is no reason why picking @Observes and @Produces but not @Inject... So either we have a clear class-only or we go the full route imo.{quote}
I agree that picking up based on @Produces but not on @Inject is counter-intuitive. However, we cannot go "the full route" because @Inject is not CDI-specific which means that we would end up in a situation similar to the one with @Singletons. So after all, option 3 is probably the best one.
> 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, 9 months
[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:
-----------------------------------
[jharting] you have a class which has some CDI 'features'. Then you create a subclass for it. This subclass will *not* get picked up if we don't look up in the class hierarchy.
To be honest. If we start with 1. then people will complain why we cannot pickup beans as @Dependent if they have an @Inject field. There is no reason why picking @Observes and @Produces but not @Inject... So either we have a clear class-only or we go the full route imo.
> 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, 9 months
[JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-280:
-------------------------------------
+1
> 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: 1.2 Proposed
>
>
> 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<T> extends Contextual<T>. 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 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, 9 months
[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:
-----------------------------------
Well, the whole wording that 'containers may provide some flag to enable a different mode' is not worth mentioning throughout the spec, because every container is free to provide different behaviour for everything - as long as it is not enabled by default!
The only thing worth mentioning is if a container _must_ provide such a mode.
> 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, 9 months
[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}but we would also need to look up all fields and methods in the super-classes!{quote}
Why?
> 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, 9 months
[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:
-------------------------------------
It's there because extensions existed (and may still exist) that called these BM methods in ABD (e.g. Seam Solder).
> 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, 9 months
[JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-392:
-------------------------------
I can't honestly remember why it is there. Have you checked the commit log?
> 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, 9 months