PicoContainer

SICA throws Exception when setter cannot be resolved

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor 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 :
    0

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

This issue relates to:
PICO-188 Support mutual dependencies for setter injection components Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Joerg Schaible added a comment -

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

Show
Joerg Schaible added a comment - 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
Hide
Permalink
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.

Show
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.
Hide
Permalink
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?

Show
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?
Hide
Permalink
Joerg Schaible added a comment -

Maybe wen can combine such a policy with PICO-181, which starts looking related.

Show
Joerg Schaible added a comment - Maybe wen can combine such a policy with PICO-181, which starts looking related.
Hide
Permalink
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....

Show
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....
Hide
Permalink
Paul Hammant added a comment -

With Pico 2.x choose ...
String differentSetterPrefix = "inject";
new SetterInjection(differentSetterPrefix);

.. as a work around.

Show
Paul Hammant added a comment - With Pico 2.x choose ... String differentSetterPrefix = "inject"; new SetterInjection(differentSetterPrefix); .. as a work around.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.