[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Alexey Kazakov updated JBIDE-9347: ---------------------------------- Description: *Let's see what we have right now.* If there is an ambiguous injection point and user Ctrl+Click on it then we show two hyperlinks. The first one is *Open @Inject Bean <Type>* which opens a random bean from all the assignable beans. The second hyperlink is *Show All Eligible Beans...* that is not quite accurate, btw: !OldAmbiguous.png! *What I suggest to change.* First at all let's rename "Show All *Eligible* Beans..." to "Show All *Assignable* Beans..." since we show all the assignable beans (beans which match the type and the qualifiers) but not eligible (assignable & enabled). For instance a set of assignable beans includes decorators and interceptors. Then, in case of an ambiguous injection, I think we should suggest show two sets of beans: *resolved* and *assignable* instead of *random bean from the assignable set* and *assignable*. It will looks like the following dialog: !Ambiguous.png! Where *Show All Resolved Beans...* open a dialog with all the beans which match the injection (if such set had the only resolved bean then the injection wouldn't be ambiguous): !Resolved.png! And *Show All Assignable Beans...* which shows all the assignable beans (right now we have that dialog by "Show All Eligible Beans..." label): !Assignable.png! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Alexey Kazakov updated JBIDE-9347: ---------------------------------- Description: *Let's see what we have right now.* If there is an ambiguous injection point and user Ctrl+Click on it then we show two hyperlinks. The first one is *Open @Inject Bean <Type>* which opens a random bean from all the assignable beans. The second hyperlink is *Show All Eligible Beans...* that is not quite accurate, btw: !OldAmbiguous.png! *What I suggest to change.* First at all let's rename "Show All *Eligible* Beans..." to "Show All *Assignable* Beans..." since we show all the assignable beans (beans which match the type and the qualifiers) but not eligible (assignable & enabled). For instance a set of assignable beans includes decorators and interceptors. Then, in case of an ambiguous injection, I think we should suggest to show two sets of beans: *resolved* and *assignable* instead of *random bean from the assignable set* and *assignable*. It will looks like the following dialog: !Ambiguous.png! Where *Show All Resolved Beans...* open a dialog with all the beans which match the injection (if such set had the only resolved bean then the injection wouldn't be ambiguous): !Resolved.png! And *Show All Assignable Beans...* which shows all the assignable beans (right now we have that dialog by "Show All Eligible Beans..." label): !Assignable.png! was: *Let's see what we have right now.* If there is an ambiguous injection point and user Ctrl+Click on it then we show two hyperlinks. The first one is *Open @Inject Bean <Type>* which opens a random bean from all the assignable beans. The second hyperlink is *Show All Eligible Beans...* that is not quite accurate, btw: !OldAmbiguous.png! *What I suggest to change.* First at all let's rename "Show All *Eligible* Beans..." to "Show All *Assignable* Beans..." since we show all the assignable beans (beans which match the type and the qualifiers) but not eligible (assignable & enabled). For instance a set of assignable beans includes decorators and interceptors. Then, in case of an ambiguous injection, I think we should suggest show two sets of beans: *resolved* and *assignable* instead of *random bean from the assignable set* and *assignable*. It will looks like the following dialog: !Ambiguous.png! Where *Show All Resolved Beans...* open a dialog with all the beans which match the injection (if such set had the only resolved bean then the injection wouldn't be ambiguous): !Resolved.png! And *Show All Assignable Beans...* which shows all the assignable beans (right now we have that dialog by "Show All Eligible Beans..." label): !Assignable.png! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Alexey Kazakov updated JBIDE-9347: ---------------------------------- Description: *Let's see what we have right now.* If there is an ambiguous injection point and user Ctrl+Click on it then we show two hyperlinks. The first one is *Open @Inject Bean <Type>* which opens a random bean from all the assignable beans. The second hyperlink is *Show All Eligible Beans...* that is not quite accurate, btw: !OldAmbiguous.png! *What I suggest to change.* First at all let's rename "Show All *Eligible* Beans..." to "Show All *Assignable* Beans..." since we show all the assignable beans (beans which match the type and the qualifiers) but not eligible (assignable & enabled). For instance a set of assignable beans includes decorators and interceptors. Then, in case of an ambiguous injection, I think we should suggest to show two sets of beans: *resolved* and *assignable* instead of *random bean from the assignable set* and *assignable*. It will look like the following dialog: !Ambiguous.png! Where *Show All Resolved Beans...* opens a dialog with all the beans which match the injection (if such set had the only resolved bean then the injection wouldn't be ambiguous): !Resolved.png! And *Show All Assignable Beans...* which shows all the assignable beans (right now we have that dialog by "Show All Eligible Beans..." label): !Assignable.png! was: *Let's see what we have right now.* If there is an ambiguous injection point and user Ctrl+Click on it then we show two hyperlinks. The first one is *Open @Inject Bean <Type>* which opens a random bean from all the assignable beans. The second hyperlink is *Show All Eligible Beans...* that is not quite accurate, btw: !OldAmbiguous.png! *What I suggest to change.* First at all let's rename "Show All *Eligible* Beans..." to "Show All *Assignable* Beans..." since we show all the assignable beans (beans which match the type and the qualifiers) but not eligible (assignable & enabled). For instance a set of assignable beans includes decorators and interceptors. Then, in case of an ambiguous injection, I think we should suggest to show two sets of beans: *resolved* and *assignable* instead of *random bean from the assignable set* and *assignable*. It will look like the following dialog: !Ambiguous.png! Where *Show All Resolved Beans...* open a dialog with all the beans which match the injection (if such set had the only resolved bean then the injection wouldn't be ambiguous): !Resolved.png! And *Show All Assignable Beans...* which shows all the assignable beans (right now we have that dialog by "Show All Eligible Beans..." label): !Assignable.png! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Alexey Kazakov updated JBIDE-9347: ---------------------------------- Description: *Let's see what we have right now.* If there is an ambiguous injection point and user Ctrl+Click on it then we show two hyperlinks. One of thous hyperlinks is *Show All Eligible Beans...* that is not quite accurate, btw. The the other one is *Open @Inject Bean <Type>* which opens a random bean from all the resolved beans. If we have more than one eligible bean than we try to resolve them. If we still have a few "resolved" beans then we mark an injection as ambiguous and our OpenOn dialog uses a random bean from this resolved set. !OldAmbiguous.png! *What I suggest to change.* First at all let's rename "Show All *Eligible* Beans..." to "Show All *Assignable* Beans..." since we show all the assignable beans (beans which match the type and the qualifiers) but not eligible (assignable & enabled). For instance a set of assignable beans includes decorators and interceptors. Then, in case of an ambiguous injection, I think we should suggest to show two sets of beans: *resolved* and *assignable* instead of *random bean from the resolved set* and *assignable*. It will look like the following dialog: !Ambiguous.png! Where *Show All Resolved Beans...* opens a dialog with all the beans which match the injection (if such a set had the only resolved bean then the injection wouldn't be ambiguous): !Resolved.png! And *Show All Assignable Beans...* which shows all the assignable beans (right now we have that dialog by "Show All Eligible Beans..." label): !Assignable.png! I'm not sure that *resolved* is good term for the dialog *Show All Resolved Beans...* since actually this is a list of beans that we got trying to resolve the eligible beans and failed to resolve it to the only bean. Any ideas how we can name such a set? was: *Let's see what we have right now.* If there is an ambiguous injection point and user Ctrl+Click on it then we show two hyperlinks. One of thous hyperlinks is *Show All Eligible Beans...* that is not quite accurate, btw. The the other one is *Open @Inject Bean <Type>* which opens a random bean from all the resolved beans. If we have more than one eligible bean than we try to resolve them. If we still have a few "resolved" beans then we mark an injection as ambiguous and our OpenOn dialog uses a random bean from this resolved set. !OldAmbiguous.png! *What I suggest to change.* First at all let's rename "Show All *Eligible* Beans..." to "Show All *Assignable* Beans..." since we show all the assignable beans (beans which match the type and the qualifiers) but not eligible (assignable & enabled). For instance a set of assignable beans includes decorators and interceptors. Then, in case of an ambiguous injection, I think we should suggest to show two sets of beans: *resolved* and *assignable* instead of *random bean from the assignable set* and *assignable*. It will look like the following dialog: !Ambiguous.png! Where *Show All Resolved Beans...* opens a dialog with all the beans which match the injection (if such a set had the only resolved bean then the injection wouldn't be ambiguous): !Resolved.png! And *Show All Assignable Beans...* which shows all the assignable beans (right now we have that dialog by "Show All Eligible Beans..." label): !Assignable.png! I'm not sure that *resolved* is good term for the dialog *Show All Resolved Beans...* since actually this is a list of beans that we got trying to resolve the eligible beans and failed to resolve it to the only bean. Any ideas how we can name such a set? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen commented on JBIDE-9347: -------------------------------------------- "other one is Open @Inject Bean <Type> which opens a random bean from all the resolved beans" ?! Has this been random always ? I thought it was the one that would get injected ? 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. I believe the spec says something like "If there are multiple eligible beans then that is an error" - and that is exactly what you have here - multiple eligible beans. btw. is Assignable really the right term ? its both matching type *and* qualifiers right ? The only missing part is whether they are alternatives or not right? Why not just show eligible beans when there are more than 1 perfect match? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Alexey Kazakov edited comment on JBIDE-9347 at 7/15/11 12:59 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 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 got 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: {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 producer of alternatives. Maybe it's better to name this set as Unresolved beans... I'm really confused :( 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 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 got 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. For this purpose, primitive types are considered to match their corresponding wrapper types in java.lang and array types are considered to match only if their element types are identical. Parameterized and raw types are considered to match if they are identical or if the bean type is assignable to the required type, as defined in Section 5.2.3, “Assignability of raw and parameterized types” or Section 8.3.1, “Assignability of raw and parameterized types for delegate injection points”. • The bean has all the required qualifiers. If no required qualifiers were explicitly specified, the container assumes the re- quired qualifier @Default. A bean has a required qualifier if it has a qualifier with (a) the same type and (b) the same annotation member value for each member which is not annotated @javax.enterprise.util.Nonbinding. {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: {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 producer of alternatives. 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

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Alexey Kazakov edited comment on JBIDE-9347 at 7/15/11 1:08 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 producer of alternatives. Maybe it's better to name this set as Unresolved beans... I'm really confused :( 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 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 got 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 producer of alternatives. 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

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Alexey Kazakov edited comment on JBIDE-9347 at 7/15/11 2:37 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 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 :( 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. 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

[ 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

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Alexey Kazakov commented on JBIDE-9347: --------------------------------------- "Show ambiguous Beans..." I like it! "Show Eligible beans..." well... we show assignable beans actually since we show all the assignable beans even if there are not available ( for instance decorators which matches types and qualifiers). So I would rename "Show Eligible beans..." to "Show Assignable beans...". Of course we can eliminate all unavailable beans and show only eligible beans but I think it will be more useful to show all the beans which match the types and qualifiers of the injection point. Max WDYT? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Pete Muir commented on JBIDE-9347: ---------------------------------- Rather than change Eligible -> Assignable, I think it would make more sense to make the list actually show the eligible beans, this is what is interesting for people. I would propose "Show possible beans" instead of show all resolved beans... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Viacheslav Kabanovich commented on JBIDE-9347: ---------------------------------------------- For the case of 'unresolvable ambiguous dependency' (exact words taken from JSR-299, 5.2.1), I would dare suggest 'Show All Unresolvable Beans' where already we have so much suggestions as 'Resolved', 'Unresolved', 'Ambiguous', 'Possible'. Guys, please vote. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Alexey Kazakov commented on JBIDE-9347: --------------------------------------- Slava has an idea of having some dialog/view for injection points to show all possible assigned/elegible/available/... beans instead of a plain list of possible beans. Slava is going to prepare some presentation/docs to show how it could look for users. And maybe we can show such a dialog/view if user click on Show All Possible Beans... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Pete Muir commented on JBIDE-9347: ---------------------------------- I like it! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Alexey Kazakov updated JBIDE-9347: ---------------------------------- Fix Version/s: 3.3.0.M4 (was: 3.3.0.M3) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Alexey Kazakov commented on JBIDE-9347: --------------------------------------- I would like to make it similar to Eclipse JDT Open Implementation dialog (available on any method from interfaces). That dialog is not modal but when you click outside of the dialog then it's just closed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Alexey Kazakov commented on JBIDE-9347: --------------------------------------- Agree. Let's use a modal dialog. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Alexey Kazakov updated JBIDE-9347: ---------------------------------- Attachment: ShowAssignibleBorderless.avi -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Denis Golovin commented on JBIDE-9347: -------------------------------------- +1 for border-less dialog -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Viacheslav Kabanovich commented on JBIDE-9347: ---------------------------------------------- Filters can be hidden, but will anyone use them after that? I think some of them quite useful to be applied by one click, opposite to 'Open Implementation' dialog where filters are exotic enough to play once and forget. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Viacheslav Kabanovich commented on JBIDE-9347: ---------------------------------------------- Will it be ok to have expandable form "Filter" above the bean list, as we have it in Properties editor? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Alexey Kazakov updated JBIDE-9347: ---------------------------------- Attachment: final2.png -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen commented on JBIDE-9347: -------------------------------------------- that wont fit on a 1024x screen would it ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Alexey Kazakov resolved JBIDE-9347. ----------------------------------- Assignee: Viacheslav Kabanovich (was: Alexey Kazakov) Resolution: Done fixed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Jaroslav Jankovič closed JBIDE-9347. ------------------------------------ Verified in JBDS 5.0.0.v201111041404M-H44-M4. Closing JIRA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9347?page=com.atlassian.jira.plugin... ] Isaac Rooskov closed JBIDE-9347. -------------------------------- Resolution: Done Re-closing now that release note text has been written -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira