PicoContainer
  1. PicoContainer
  2. PICO-183

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

          Activity

          Hide
          Jörg 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
          Jörg 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
          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
          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
          Jörg Schaible added a comment -

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

          Show
          Jörg Schaible added a comment - Maybe wen can combine such a policy with PICO-181 , which starts looking related.
          Hide
          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....
          Jörg Schaible made changes -
          Field Original Value New Value
          Link This issue is related to PICO-188 [ PICO-188 ]
          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 ]
          Hide
          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.
          Paul Hammant made changes -
          Resolution Won't Fix [ 2 ]
          Status Open [ 1 ] Closed [ 6 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              Brian McCallister
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: