Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Won't Fix
-
Affects Version/s: 1.0-RC-1
-
Fix Version/s: 2.3
-
Component/s: PicoContainer (Java)
-
Labels:None
-
Number of attachments :
Description
Right now when you use the SICA on a bean which has setters other than those which match to components it throws an exception. This is undesirable behavior as quite frequently a bean will have a mix of component setters and normal setters.
[editorial]
Yes, SI is a hack, but it is a useful one in some places.
[/editorial]
Issue Links
- relates to
-
PICO-188
Support mutual dependencies for setter injection components
-
Activity
Not every Setter on a Bean is necessarily a dependency. But thats a problem if you want to mix type-2 DI and normal setters.
I don't use SI at all yet I think that an Exception for an unstatisfiable Setter is wrong. We should at least allow to configure wether an Exception should be thrown or we should remain silent.
Thomas Heller
added a comment - Not every Setter on a Bean is necessarily a dependency. But thats a problem if you want to mix type-2 DI and normal setters.
I don't use SI at all yet I think that an Exception for an unstatisfiable Setter is wrong. We should at least allow to configure wether an Exception should be thrown or we should remain silent. I call these kinds of design decisions "policy decisions". IMHO two options:
1) feed the SICA a policy (could be a SICAConfig, a boolean value, ...)
2) use OO and create another CA with a different policy
In general I prefer #2. How about an AbstractSICA, a LenientSICA and a StrictSICA?
Leo Simons
added a comment - I call these kinds of design decisions "policy decisions". IMHO two options:
1) feed the SICA a policy (could be a SICAConfig, a boolean value, ...)
2) use OO and create another CA with a different policy
In general I prefer #2. How about an AbstractSICA, a LenientSICA and a StrictSICA? Maybe wen can combine such a policy with PICO-181, which starts looking related.
Jörg Schaible
added a comment - Maybe wen can combine such a policy with PICO-181 , which starts looking related. I think that Martin Fowler may have been right with a suggestion that initXXX() should be used to differentiate component setters from ordinary setters.
I suggest that we relax it. If the developer is naieve enough to choose setter injection over CDI, then let them have a component in an indeterminate state.
It will result in an NPE sometime or other.... 
Paul Hammant
added a comment - I think that Martin Fowler may have been right with a suggestion that initXXX() should be used to differentiate component setters from ordinary setters.
I suggest that we relax it. If the developer is naieve enough to choose setter injection over CDI, then let them have a component in an indeterminate state.
It will result in an NPE sometime or other.... Jörg Schaible
made changes -
Jörg Schaible
made changes -
| Fix Version/s | 2.0 [ 10411 ] | |
| Environment |
Michael Rimov
made changes -
| Fix Version/s | 2.0 [ 10411 ] | |
| Fix Version/s | 2.2 [ 14251 ] |
Michael Rimov
made changes -
| Fix Version/s | 2.2 [ 14251 ] | |
| Fix Version/s | 2.3 [ 14303 ] |
With Pico 2.x choose ...
String differentSetterPrefix = "inject";
new SetterInjection(differentSetterPrefix);
.. as a work around.
Paul Hammant
added a comment - With Pico 2.x choose ...
String differentSetterPrefix = "inject";
new SetterInjection(differentSetterPrefix);
.. as a work around. Paul Hammant
made changes -
| Resolution | Won't Fix [ 2 ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
Hi Brian,
this is a design question. Pico's main task is to resolve any dependency of a component. SI maps this behaviour to a JavaBean. So any setter found by reflection is supposed to be a dependency, that must be resolved. The implementation has to assume, that the bean is only properly initialized, if any dependency introduced by setters is resolved.
IMHO you have not a proper JavaBean in your situation. You may introduce an additional ctor with all the necessary dependencies and use a CI for this hybrid.
Regards,
Jörg