[JBoss JIRA] (CDI-331) Instance.iterator() shouldn't include non-alternatives that haven't been replaced
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-331?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-331 started by Antoine Sabot-Durand.
> Instance.iterator() shouldn't include non-alternatives that haven't been replaced
> ---------------------------------------------------------------------------------
>
> Key: CDI-331
> URL: https://issues.jboss.org/browse/CDI-331
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Affects Versions: 1.1.PRD
> Reporter: Jozef Hartinger
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> The specification currently says that:
> {quote}
> The iterator() method must:
> • Identify the set of beans that have the required type and required qualifiers and are eligible for injection into the class into
> which the parent Instance was injected, according to the rules of typesafe resolution, as defined in Section 5.2.1.
> {quote}
> The ambiguity resolution algorithm as defined in 5.2.2 should be applied.
> This is explicitly required for get() but is not required for iterator(). This causes the following inconsistency:
> Assume two classes Foo and Bar which both implement common interface Common. Bar is an enabled alternative.
> Assume further the following
> {noformat}
> @Inject @Any Instance<Common> instance
> {noformat}
> injection point.
> It is clear that instance.get() returns Bar.
> It is however not clear whether instance.iterator() iterates over:
> a) Bar
> b) Foo, Bar
> and whether instance.isAmbiguous() returns:
> a) true
> b) false
--
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-331) Instance.iterator() shouldn't include non-alternatives that haven't been replaced
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-331?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-331:
----------------------------------------
Assignee: Antoine Sabot-Durand (was: Pete Muir)
> Instance.iterator() shouldn't include non-alternatives that haven't been replaced
> ---------------------------------------------------------------------------------
>
> Key: CDI-331
> URL: https://issues.jboss.org/browse/CDI-331
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Affects Versions: 1.1.PRD
> Reporter: Jozef Hartinger
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> The specification currently says that:
> {quote}
> The iterator() method must:
> • Identify the set of beans that have the required type and required qualifiers and are eligible for injection into the class into
> which the parent Instance was injected, according to the rules of typesafe resolution, as defined in Section 5.2.1.
> {quote}
> The ambiguity resolution algorithm as defined in 5.2.2 should be applied.
> This is explicitly required for get() but is not required for iterator(). This causes the following inconsistency:
> Assume two classes Foo and Bar which both implement common interface Common. Bar is an enabled alternative.
> Assume further the following
> {noformat}
> @Inject @Any Instance<Common> instance
> {noformat}
> injection point.
> It is clear that instance.get() returns Bar.
> It is however not clear whether instance.iterator() iterates over:
> a) Bar
> b) Foo, Bar
> and whether instance.isAmbiguous() returns:
> a) true
> b) false
--
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-398) Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-398?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-398 started by Antoine Sabot-Durand.
> Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-398
> URL: https://issues.jboss.org/browse/CDI-398
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Affects Versions: 1.1.PFD
> Reporter: Marko Lukša
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> Section 2.2.1 says:
> {quote}
> Almost any Java type may be a bean type of a bean:
> • A bean type may be an array type.
> {quote}
> and:
> {quote}
> A type variable is not a legal bean type. A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> This should be clarified that array types that have a type variable or a parameterized type that contains a wildcard type parameter as the array's component type are also not legal bean types.
> Also, all other sections that mention type variables/wildcards should also be reviewed and, if necessary, updated to also specifically mention array types with these kinds of component types.
--
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-398) Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-398?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reopened CDI-398:
--------------------------------------
Forgot to treat return types from producer fields and methods.
> Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-398
> URL: https://issues.jboss.org/browse/CDI-398
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Affects Versions: 1.1.PFD
> Reporter: Marko Lukša
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> Section 2.2.1 says:
> {quote}
> Almost any Java type may be a bean type of a bean:
> • A bean type may be an array type.
> {quote}
> and:
> {quote}
> A type variable is not a legal bean type. A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> This should be clarified that array types that have a type variable or a parameterized type that contains a wildcard type parameter as the array's component type are also not legal bean types.
> Also, all other sections that mention type variables/wildcards should also be reviewed and, if necessary, updated to also specifically mention array types with these kinds of component types.
--
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-320) Clarify whether ProcessAnnotatedType should be fired for annotations
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-320?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-320:
-----------------------------
Labels: CDI_spec_chge CDI_tck_chge Ready_to_fix (was: CDI_spec_chge Ready_to_fix)
> Clarify whether ProcessAnnotatedType should be fired for annotations
> --------------------------------------------------------------------
>
> Key: CDI-320
> URL: https://issues.jboss.org/browse/CDI-320
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Reporter: Ron Šmeral
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> It should be stated clearly whether {{ProcessAnnotatedType}} should be fired for annotations.
> Currently, *11.5.6 ProcessAnnotatedType event* says:
> {quote}
> The container must fire an event, before it processes a type, for each:
> * Java class, interface or enum in a bean archive,
> {quote}
> The word "annotation" has been introduced into the above line and later reverted.
> {quote}
> * Annotated type added by {{BeforeBeanDiscovery.addAnnotatedType()}},
> {quote}
> The wording used here, however, doesn't exclude the option of the annotated type being an Annotation.
--
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-372) clarify behaviour of implicit bean archive
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-372?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand edited comment on CDI-372 at 3/24/14 12:48 PM:
--------------------------------------------------------------------
https://github.com/cdi-spec/cdi/pull/225
This PR also resolve CDI-408
was (Author: antoinesabot-durand):
https://github.com/cdi-spec/cdi/pull/225
This PR also resolve CDi-428
> clarify behaviour of implicit bean archive
> ------------------------------------------
>
> Key: CDI-372
> URL: https://issues.jboss.org/browse/CDI-372
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Packaging and Deployment
> Affects Versions: 1.1.PFD
> Reporter: David Konecny
> Assignee: Antoine Sabot-Durand
> Priority: Minor
> Labels: CDI_spec_chge
> Fix For: 1.2 Proposed
>
>
> I read chapter "12.1 Bean archives" which defines 'explicit bean archive' and 'implicit bean archive' and following that I removed beans.xml from my existing application only to find out that deployment of my app now fails because of unsatisfied dependencies. It took me a while to figure out the problem: there is behavioural difference between explicit and implicit bean archive which is mentioned later in the middle of chapter "12.4 Bean discovery":
> The container discovers:
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class interface, or enum with a bean defining annotation in an implicit bean archive.
> The fact that implicit bean archive provides only beans with defining annotations is very important piece of information and I would like to suggest to mention that early in chapter 12.1 when the bean archive concepts are defined. Thanks.
--
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-372) clarify behaviour of implicit bean archive
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-372?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand edited comment on CDI-372 at 3/24/14 12:48 PM:
--------------------------------------------------------------------
https://github.com/cdi-spec/cdi/pull/225
This PR also resolve CDi-428
was (Author: antoinesabot-durand):
https://github.com/cdi-spec/cdi/pull/225
This PR also resolve CDi-408
> clarify behaviour of implicit bean archive
> ------------------------------------------
>
> Key: CDI-372
> URL: https://issues.jboss.org/browse/CDI-372
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Packaging and Deployment
> Affects Versions: 1.1.PFD
> Reporter: David Konecny
> Assignee: Antoine Sabot-Durand
> Priority: Minor
> Labels: CDI_spec_chge
> Fix For: 1.2 Proposed
>
>
> I read chapter "12.1 Bean archives" which defines 'explicit bean archive' and 'implicit bean archive' and following that I removed beans.xml from my existing application only to find out that deployment of my app now fails because of unsatisfied dependencies. It took me a while to figure out the problem: there is behavioural difference between explicit and implicit bean archive which is mentioned later in the middle of chapter "12.4 Bean discovery":
> The container discovers:
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class interface, or enum with a bean defining annotation in an implicit bean archive.
> The fact that implicit bean archive provides only beans with defining annotations is very important piece of information and I would like to suggest to mention that early in chapter 12.1 when the bean archive concepts are defined. Thanks.
--
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-372) clarify behaviour of implicit bean archive
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-372?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-372 started by Antoine Sabot-Durand.
> clarify behaviour of implicit bean archive
> ------------------------------------------
>
> Key: CDI-372
> URL: https://issues.jboss.org/browse/CDI-372
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Packaging and Deployment
> Affects Versions: 1.1.PFD
> Reporter: David Konecny
> Assignee: Antoine Sabot-Durand
> Priority: Minor
> Labels: CDI_spec_chge
> Fix For: 1.2 Proposed
>
>
> I read chapter "12.1 Bean archives" which defines 'explicit bean archive' and 'implicit bean archive' and following that I removed beans.xml from my existing application only to find out that deployment of my app now fails because of unsatisfied dependencies. It took me a while to figure out the problem: there is behavioural difference between explicit and implicit bean archive which is mentioned later in the middle of chapter "12.4 Bean discovery":
> The container discovers:
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class interface, or enum with a bean defining annotation in an implicit bean archive.
> The fact that implicit bean archive provides only beans with defining annotations is very important piece of information and I would like to suggest to mention that early in chapter 12.1 when the bean archive concepts are defined. Thanks.
--
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-372) clarify behaviour of implicit bean archive
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-372?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-372:
----------------------------------------
Assignee: Antoine Sabot-Durand
> clarify behaviour of implicit bean archive
> ------------------------------------------
>
> Key: CDI-372
> URL: https://issues.jboss.org/browse/CDI-372
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Packaging and Deployment
> Affects Versions: 1.1.PFD
> Reporter: David Konecny
> Assignee: Antoine Sabot-Durand
> Priority: Minor
> Labels: CDI_spec_chge
> Fix For: 1.2 Proposed
>
>
> I read chapter "12.1 Bean archives" which defines 'explicit bean archive' and 'implicit bean archive' and following that I removed beans.xml from my existing application only to find out that deployment of my app now fails because of unsatisfied dependencies. It took me a while to figure out the problem: there is behavioural difference between explicit and implicit bean archive which is mentioned later in the middle of chapter "12.4 Bean discovery":
> The container discovers:
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class interface, or enum with a bean defining annotation in an implicit bean archive.
> The fact that implicit bean archive provides only beans with defining annotations is very important piece of information and I would like to suggest to mention that early in chapter 12.1 when the bean archive concepts are defined. Thanks.
--
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... ]
Work on CDI-408 started by Antoine Sabot-Durand.
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
> Key: CDI-408
> URL: https://issues.jboss.org/browse/CDI-408
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Beans
> Reporter: Jens Schumann
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge
> Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>
> Btw: Which JIRA version is CDI 1.1 Final?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 1 month