Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Critical
-
Resolution: Partially Completed
-
Affects Version/s: None
-
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 {
public ProjectImpl(final File rootDirectory)
{ projectRoot = rootDirectory; }}
@Singleton
public class CurrentProject
@Inject Project project;
should in this case just consider getCurrent() the only injection source because Abstract class cannot be instantatiated nor can the PRojectImpl since it has no-noarg constructor but does have a constructor with arguments.
Gliffy Diagrams
Issue Links
- cloned to
-
JBIDE-7950
Abstract classes is being considered injectable
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
I have checked the example in the description above, and found that model provides exactly one injection getCurrent(); type ProjectImpl is not a bean and is not injectable. I have found only the bug of validation. When I create/remove constructor in ProjectImpl, cdi builder removes/adds this type from project beans set; after that cdi validation is invoked for the changed file ProjectImpl.java but not for files that have the injection point. Manual invoking action 'Validate' on those files results in a correct state. So, in cdi validator, when building dependencies, we probably should consider file with injection point as dependent on every file having type assignable to the type of the injection point.
Viacheslav Kabanovich
added a comment - I have checked the example in the description above, and found that model provides exactly one injection getCurrent(); type ProjectImpl is not a bean and is not injectable. I have found only the bug of validation. When I create/remove constructor in ProjectImpl, cdi builder removes/adds this type from project beans set; after that cdi validation is invoked for the changed file ProjectImpl.java but not for files that have the injection point. Manual invoking action 'Validate' on those files results in a correct state. So, in cdi validator, when building dependencies, we probably should consider file with injection point as dependent on every file having type assignable to the type of the injection point. Yes, Slava is right. It's a problem of incremental validation.
Alexey Kazakov
added a comment - Yes, Slava is right. It's a problem of incremental validation. Partially fixed.
1. Full build/validation works for the case.
2. If there is an ambiguous injection because ProjectImpl has default or @Inject constructor then the injection is marked as a problem. If you make the ProjectImpl a not-valid bean then CurrentProject will be re-validated and the marker disappears.
3. If there is no ambiguous injections because ProjectImpl is not a valid bean then ProjectImpl is not included in CDI model and making ProjectImpl a valid bean won't force CurrentProject to be re-validated. The manual re-validating (or incremental/full build of CurrentProject) is needed there to mark its injections as a problem. It's a restriction of current CDI tools model. Let's have a separate issue (not critical for CR1) for that.
Alexey Kazakov
added a comment - Partially fixed.
1. Full build/validation works for the case.
2. If there is an ambiguous injection because ProjectImpl has default or @Inject constructor then the injection is marked as a problem. If you make the ProjectImpl a not-valid bean then CurrentProject will be re-validated and the marker disappears.
3. If there is no ambiguous injections because ProjectImpl is not a valid bean then ProjectImpl is not included in CDI model and making ProjectImpl a valid bean won't force CurrentProject to be re-validated. The manual re-validating (or incremental/full build of CurrentProject) is needed there to mark its injections as a problem. It's a restriction of current CDI tools model. Let's have a separate issue (not critical for CR1) for that. v. in v20110121-0004-H124-CR1
Lukas Jungmann
added a comment - v. in v20110121-0004-H124-CR1 
It's already implemented. But there is a bug. If a class is a valid bean type then it's treated as a bean. So it's a reason why ProjectImpl is injectable in JBT (this is a bug).