[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:
------------------------------------------
I won't go back in terminology war. I'm the newbie here and understand my user / usage oriented pov is not widely shared ;).
Anyway, I think we're too late to produce a quality work on this. I propose we postpone this lexical dispute for 2.0 where most of the spec will more deeply reviewed. So I think we should remove this ticket from 1.2.
WDYT?
> 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 John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-408:
--------------------------------
I'd vote for option 2, but looks a bit too expensive so I'd vote for #3.
> 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 Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-392:
------------------------------------------
I agree with [~struberg]. I've experienced this bug in CDI 1.0, I'd prefer to have an exception. Unless there's another reason I think we should get rid of this "container is permitted to define a non-portable mode..." mention
> 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 Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-392:
-----------------------------------
[~jharting] I'm not sure we need the backward compatibility in this case. We just prevent something which creates a random behaviour because the result of e.g. getBeans(Type) during bootstrap depends only on the order in which the classes get scanned. And this is absolutely random.
> 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 Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-408:
-----------------------------------
+1 for option 3. Simply because option 1 would need us to not only look inside a class for annotations, but we would *also* need to look up all fields and methods in the super-classes!
> 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-388) Session bean specialization example is not valid
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-388?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-388 started by Antoine Sabot-Durand.
> Session bean specialization example is not valid
> ------------------------------------------------
>
> Key: CDI-388
> URL: https://issues.jboss.org/browse/CDI-388
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: Martin Kouba
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> {code}
> @Stateless
> public class LoginActionBean implements LoginAction { ... }
> @Stateless @Mock @Specializes
> public class MockLoginActionBean extends LoginActionBean { ... }
> {code}
> {{LoginAction}} is a local interface (whether it's annotated with {{@Local}} or not) therefore the bean types of {{LoginActionBean}} are {{LoginAction}}, {{Object}}. On the other hand {{MockLoginActionBean}} does not have a local interface (client views exposed by a particular session bean are not inherited by a subclass; see also the EJB spec 4.9.2.1 Session Bean Superclasses). Therefore the bean types of {{MockLoginActionBean}} are {{MockLoginActionBean}}, {{LoginActionBean}} and {{Object}} (3.2.2 Bean types of a session bean: "the unrestricted set of bean types contains the bean class and all superclasses").
> The spec also states (4.3.1 Direct and indirect specialization):
> {quote}
> Furthermore, X must have all the bean types of Y. If X does not have some bean type of Y, the container automatically detects the problem and treats it as a definition error.
> {quote}
> So I believe the aforementioned example should result in a definition exception. To make it valid the {{MockLoginActionBean}} should also implement {{LoginAction}}.
--
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-388) Session bean specialization example is not valid
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-388?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-388:
----------------------------------------
Assignee: Antoine Sabot-Durand
> Session bean specialization example is not valid
> ------------------------------------------------
>
> Key: CDI-388
> URL: https://issues.jboss.org/browse/CDI-388
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: Martin Kouba
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> {code}
> @Stateless
> public class LoginActionBean implements LoginAction { ... }
> @Stateless @Mock @Specializes
> public class MockLoginActionBean extends LoginActionBean { ... }
> {code}
> {{LoginAction}} is a local interface (whether it's annotated with {{@Local}} or not) therefore the bean types of {{LoginActionBean}} are {{LoginAction}}, {{Object}}. On the other hand {{MockLoginActionBean}} does not have a local interface (client views exposed by a particular session bean are not inherited by a subclass; see also the EJB spec 4.9.2.1 Session Bean Superclasses). Therefore the bean types of {{MockLoginActionBean}} are {{MockLoginActionBean}}, {{LoginActionBean}} and {{Object}} (3.2.2 Bean types of a session bean: "the unrestricted set of bean types contains the bean class and all superclasses").
> The spec also states (4.3.1 Direct and indirect specialization):
> {quote}
> Furthermore, X must have all the bean types of Y. If X does not have some bean type of Y, the container automatically detects the problem and treats it as a definition error.
> {quote}
> So I believe the aforementioned example should result in a definition exception. To make it valid the {{MockLoginActionBean}} should also implement {{LoginAction}}.
--
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
Vote on CDI-408 bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
by Antoine Sabot-Durand
Hi all,
Vote is open between the following options :
1) Add to the bean defining annotation list @Produces and @Observes. That will add to the list annotations inside a class.
2) Detect @Produces and @Observes in class that don't have bean defining annotation and warn the user at boot time. It seems to be a work very close to previous point in term of scanning.
3) Do nothing in the container and only document in spec the fact that in annotated mode these will be ignored silently.
Vote on the JIRA ticket please.
Antoine
10 years, 9 months
[JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-280:
-------------------------------
I don't want us to start redefining all the terms. That will be super-confusing for everyone.
I think it would be more useful to compile a complete list of all terms used, with references, and see if there is incorrect usage, or two terms referencing the same thing. If we have two terms used for exactly the same thing, then we should choose one.
> 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 Jens Schumann (JIRA)
[ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.sy... ]
Jens Schumann commented on CDI-408:
-----------------------------------
(Even though my vote will not count) I vote for option 1 but we will be happy with option 3 if documentation takes place in MR 1.2.
Just in case we go with option 3 I will create a new ticket containing option 1 for CDI 2.0;).
Thanks for the discussion.
> 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
