Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Critical
-
Resolution: Done
-
Affects Version/s: 3.2.0.Beta2
-
Fix Version/s: 3.2.0.CR1
-
Component/s: cdi
-
Labels:None
Description
public interface Project {
}
public abstract class AbstractProject implements Project {
}
public class ProjectImpl extends AbstractProject {
}
@Singleton
public class CurrentProject
and then:
@Inject Project project;
And I get "Multiple beans are eligible for injection to the injection point"
Open All elgible beans seem to consider getCurrent() and the abstract class - but for some reason not ProjectImpl as elgible.
Should it not just be getCurrent() ?
Gliffy Diagrams
Issue Links
- cloned from
-
JBIDE-7967
nonannotated classes without default constructor and no CDI scope or inject annotations on class or constructor should not be considered beans
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
AbstractProject is an abstract class, so it can be injected. But ProjectImpl seems to be ok. We should figure out why this example works in seam-forge projects and what we do wrong.
Alexey Kazakov
added a comment - AbstractProject is an abstract class, so it can be injected. But ProjectImpl seems to be ok. We should figure out why this example works in seam-forge projects and what we do wrong. Which are the ambiguous resolves according to the log?
My guess:
We have the injection type Project.
AbstractProject is abstract so it shouldn't be a candidate for injection
ProjectImpl is an actual Project so we have one candidate
The producer method CurrentProject.getCurrent is another candidate for Project so there we have our second
I think you'll have to strangle ProjectImpl with @Typed({}) so your producer method is free to produce the one we need.
Nicklas Karlsson
added a comment - Which are the ambiguous resolves according to the log?
My guess:
We have the injection type Project.
AbstractProject is abstract so it shouldn't be a candidate for injection
ProjectImpl is an actual Project so we have one candidate
The producer method CurrentProject.getCurrent is another candidate for Project so there we have our second
I think you'll have to strangle ProjectImpl with @Typed({}) so your producer method is free to produce the one we need.
I excluded abstract classes from candidates to injection and created test based on classes in description. Now, it checks that ProjectImpl and CurrentProject.getCurrent are injectable. Is it ok?
Viacheslav Kabanovich
added a comment - I excluded abstract classes from candidates to injection and created test based on classes in description. Now, it checks that ProjectImpl and CurrentProject.getCurrent are injectable. Is it ok? Yes, for this example outlined in the jira description there is both ProjectImpl and getCurrent() as candidate injections which means ambiguity.
Max Rydahl Andersen
added a comment - Yes, for this example outlined in the jira description there is both ProjectImpl and getCurrent() as candidate injections which means ambiguity. v. in v20110121-0004-H124-CR1
Lukas Jungmann
added a comment - v. in v20110121-0004-H124-CR1 
marked as critical that this seems to be a very common pattern.