[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:
------------------------------------------
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, 2 months
[JBoss JIRA] (CDI-405) Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-405?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-405:
------------------------------------------
Reproducing IRC discussion between [~pmuir] (pmuir) and [~antoinesabot-durand] (asd) about this ticket and corresponding PR
{code}
<+pmuir> asd: for https://github.com/cdi-spec/cdi/pull/204
<+pmuir> I think the new wording is too verbose and wooly
<+asd> +1. Your input as an english native speaker would be very appreciated here
<+pmuir> I wonder if we can't say something like (i.e. to paraphrase) "The container must provide an implementation of the @RequestScoped, @ApplicationScoped and @SessionScoped annotations defined in [builtin_contexts] representing the standard scopes defined by the Java Servlets specification."
<+pmuir> we would need to reword the second bullet as well, to keep the definitions consistent
<+asd> with that you remove the idea that these context are not restrict to servlet scopes IMO
<+asd> the main idea should be "it's like scope in servlet spec but it could be more"
<+asd> the main issue with this is nowhere in the spec we indicate how a third party spec could extend @RequestScoped...
<+pmuir> that I think we should add to 6.2
<+pmuir> "A context object may be defined for any of the built-in scopes"
<+pmuir> agreed?
<+asd> ok
{code}
So the reword should be simplified and a new mention should be put regarding built-in scopes extension.
I'm modifying the PR with this new approach.
> Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1
> --------------------------------------------------------------------------------
>
> Key: CDI-405
> URL: https://issues.jboss.org/browse/CDI-405
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Martin Kouba
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> @RequestScoped and @ApplicationScoped are not servlet-specific (see sections 6.7.1 and 6.7.3 for more use cases).
--
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, 2 months
[JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-280:
-------------------------------------
Labels: CDI_api_chge CDI_spec_chge (was: CDI_api_chge CDI_spec_chge Ready_to_fix)
> 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, 2 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 [mine|#comment-12947802]? No
Now we have this question [~pmuir] about the Javadoc and the presence of
{quote}
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}
There must be a reason to create this complexity but I really didn't find it...
> 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, 2 months
[JBoss JIRA] (CDI-408) bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.sy... ]
Jason Greene commented on CDI-408:
----------------------------------
It's not a problem to pick up on annotations at the method level, since that information is already analyzed. So I would go with option 1 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, 2 months
[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:
-------------------------------
[~jason.greene], [~swd847] can you comment on any performance concerns with [~antoinesabot-durand] summary of options?
> 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, 2 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:
-------------------------------
Do we have an updated version of the change?
> 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, 2 months
[JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-280:
------------------------------------------
As mentioned in one of my previous comment the term "Bean Metadata" is already widely used in the spec in 5.5.8 for this concept. Other places in chapter 11 talk about "the Bean Interface". I don't understand your point : are suggesting replacing the term "Bean Metadata" for "Bean" ?
On the orher hand the term "Bean" is already used in a lot of place (like 2.2) and nowhere it point to Bean<T>.
So again as I stated twice in this ticket, if we agree on the terms "Bean Class" and "Bean Metadata" (which are in use in the spec) and want to be consistent "Bean Instance" and "Bean Reference" makes sense. I agree that we should avoid using the lonely term "Bean" in the spec but should keep it's usage for the day-to-day work of our users to abbreviate "Bean Instance" or "Bean reference".
> 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, Ready_to_fix
> 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, 2 months
[JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-280:
-----------------------------------
I'm strongly -1 to re-coining the term Bean inside the spec. This terminus tecnicus is already used in the CDI area for the Metadata. This is why BeanManager#getBeans() is named that way and also the name of our Bean<T> class.
> 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, Ready_to_fix
> 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, 2 months