Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.0-beta-5
-
Component/s: PicoContainer (Java)
-
Labels:None
-
Number of attachments :
Description
The current implementation of ComponentParameter.resolve(PicoContainer pico, Class expectedType) does not respect the expected type. The Parameter will either return the component mapped to the key or a component of the class type given in the ctor, but will not ensure that the component is compatible to the type.
=== snip ===
MutablePicoContainer picoContainer = new DefaultPicoContainer();
Parameter parameter = new ComponentParameter(Touchable.class);
picoContainer.registerComponentImplementation(Touchable.class, SimpleTouchable.class);
assertNull(parameter.resolveAdapter(picoContainer, TestCase.class));
=== snap ===
ConstantParameter instead will throw an AssignabilityRegistrationException.
Both versions create big problems, if a component is registered with incompatible parameters, because the implementation will normally just try to resolve the parameter and check for a returned null. To support the best fitting ctor respecting a component's parameters from the registration, the returning-null-behaviour is mandatory.
Activity
Field | Original Value | New Value |
---|---|---|
Attachment | ConstantParameter.java.diff [ 11378 ] |
Attachment | ComponentParameter.java.diff [ 11379 ] |
Attachment | ParameterTestCase.java.diff [ 11380 ] |
Status | Open [ 1 ] | Closed [ 6 ] |
Assignee | Aslak Hellesoy [ rinkrank ] | |
Resolution | Fixed [ 1 ] | |
Fix Version/s | 1.0-beta-5 [ 10145 ] |
src/java/org/picocontainer/defaults/ConstantParameter.java
With this patch resolveAdapter returns null in case of an AssignabilityRegistrationException.