[jbosstools-issues] [JBoss JIRA] Issue Comment Edited: (JBIDE-9347) Show All Resolved Beans dialog

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Alexey Kazakov edited comment on JBIDE-9347 at 7/15/11 2:52 PM: ---------------------------------------------------------------- {quote} ?! Has this been random always ? I thought it was the one that would get injected ? {quote} I considered the case when we get an ambiguous injection. If CDI model resolved the injection successfully then we have the only resolved bean and we have an openOn *Open @Inject Bean <Type>* for that bean. We have it right now and we are not going to change it. But if we try to resolve multiple eligible beans but get a few beans anyway then I suggest to show *Show All Resolved Beans* instead of a random bean from the set of the "resolved" beans. {quote} btw. is Assignable really the right term ? its both matching type and qualifiers right ? {quote} that's right. See the spec: {quote} *5.2. Typesafe resolution* A bean is assignable to a given injection point if: • The bean has a bean type that matches the required type. ... • The bean has all the required qualifiers. ... {quote} {quote} Beyond that if i'm following your explanation then what you want is to have Eligible and Assignable. Where Eligibile is what you call Resolved. {quote} No, it's even more complicated. A bean is eligible only if it is assignable *and* available. For example decorators and interceptors are not available for injections. See the spec: {quote} A bean is eligible for injection to a certain injection point if: • it is available for injection in the module that contains the class that declares the injection point, and • it is assignable to the injection point (using Section 5.2.3, “Assignability of raw and parameterized types”). {quote} But it's not an error to have multiple eligible beans for the injection until the ambiguity is not resolvable: {quote} An ambiguous dependency exists at an injection point when multiple beans are eligible for injection to the injection point. ... When an ambiguous dependency exists, the container attempts to resolve the ambiguity. If any eligible beans are alternat- ives, the container eliminates all eligible beans that are not alternatives, except for producer methods and fields of beans that are alternatives. If there is exactly one bean remaining, the container will select this bean, and the ambiguous depend- ency is called resolvable. {quote} So the set of beans that I call *resolved* is a set of eligible beans minus not alternatives, except for producers of alternatives. If there is no alternatives then the set of the eligible beans equals to the set of "resolved". So we can describe the process of selecting the proper bean for the injection by the following steps: # Collecting *available* beans. Decorators, Interceptors and some other beans are not available for injection. # Collecting *assignable* beans: types, qualifiers should match. *<-- Show All Assignable Beans...* # Collecting *eligible* beans: beans that are available && assignable. # If there are multiple eligible beans and alternatives among them then eliminate not alternatives except for producers of alternatives: -- Got the only bean? *<-- Open @Inject Bean <Type>* -- Got more than one bean? *<-- Show All Resolved Beans...* Maybe it's better to name this set as Unresolved beans... I'm really confused :( BTW having unresolvable dependency for *@Inject <Type> field* is an error but we *can* have multiple beans for *@Inject Instance<Type> field*. So it's even more interesting to see the list of beans that will be injected in *Instance* in runtime. And we have this list only after step #4. was (Author: akazakov): {quote} ?! Has this been random always ? I thought it was the one that would get injected ? {quote} I considered the case when we get an ambiguous injection. If CDI model resolved the injection successfully then we have the only resolved bean and we have an openOn *Open @Inject Bean <Type>* for that bean. We have it right now and we are not going to change it. But if we try to resolve multiple eligible beans but get a few beans anyway then I suggest to show *Show All Resolved Beans* instead of a random bean from the set of the "resolved" beans. {quote} btw. is Assignable really the right term ? its both matching type and qualifiers right ? {quote} that's right. See the spec: {quote} *5.2. Typesafe resolution* A bean is assignable to a given injection point if: • The bean has a bean type that matches the required type. ... • The bean has all the required qualifiers. ... {quote} {quote} Beyond that if i'm following your explanation then what you want is to have Eligible and Assignable. Where Eligibile is what you call Resolved. {quote} No, it's even more complicated. A bean is eligible only if it is assignable *and* available. For example decorators and interceptors are not available for injections. See the spec: {quote} A bean is eligible for injection to a certain injection point if: • it is available for injection in the module that contains the class that declares the injection point, and • it is assignable to the injection point (using Section 5.2.3, “Assignability of raw and parameterized types”). {quote} But it's not an error to have multiple eligible beans for the injection until the ambiguity is not resolvable: {quote} An ambiguous dependency exists at an injection point when multiple beans are eligible for injection to the injection point. ... When an ambiguous dependency exists, the container attempts to resolve the ambiguity. If any eligible beans are alternat- ives, the container eliminates all eligible beans that are not alternatives, except for producer methods and fields of beans that are alternatives. If there is exactly one bean remaining, the container will select this bean, and the ambiguous depend- ency is called resolvable. {quote} So the set of beans that I call *resolved* is a set of eligible beans minus not alternatives, except for producers of alternatives. If there is no alternatives then the set of the eligible beans equals to the set of "resolved". So we can describe the process of selecting the proper bean for the injection by the following steps: # Collecting *available* beans. Decorators, Interceptors and some other beans are not available for injection. # Collecting *assignable* beans: types, qualifiers should match. *<-- Show All Assignable Beans...* # Collecting *eligible* beans: beans that are available && assignable. # If there are multiple eligible beans and alternatives among them then eliminate not alternatives except for producers of alternatives: -- Got the only bean? *<-- Open @Inject Bean <Type>* -- Got more than one bean? *<-- Show All Resolved Beans...* Maybe it's better to name this set as Unresolved beans... I'm really confused :( -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira