Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.1
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      5

      Description

      This refactoring introduces two new classes: LifecycleManager and LifecycleManagerFactory.

      The rationale behind this refactoring is to allow pluggable lifecycle mechanisms/strategies. The motivation for this is that users have different requirements for lifecycle algorithms.

      Lifecycle management (LM) and dependency resolution (DR) are two separate concerns. This refactoring moves these separate concerns into different interfaces.

      An instance of a LifecycleManagerFactory can now be passed to a DefaultPicoContainer's constructor. The other (old) constructors remain the same, calling the new constructor with a DefaultLifecycleManagerFactory. This factory creates DefaultLifecycleManager instances, which encapsulate the previous lifecycle algorithm that used to be in DefaultPicoContainer.

      The lifecycle methods start(), stop() and dispose() remain on DefaultPicoContainer for backwards compatibility, but they have been deprecated in order to favour the new design.

      If this refactoring is backed by a majority of the developers, the exixting code in NanoContainer should be refactored from pico.start() to pico.getLifecycleManager().start() etc. (Very simple).

      Another nice effect from this refactoring is that we can now allow component developers to cherry-pick their own lifecycle methods, removing the requirement to implement the PicoContainer Startable and Disposable interfaces when lifecycle is needed. Additional LifecycleManager/LifecycleManagerFactory classes leveraging proxytoys multicast or other can now be used in conjunction with DefaultPicoContainer and everything in NanoContainer.

      1. DefaultLifecycleManager.java
        3 kB
        Aslak Hellesøy
      2. DefaultLifecycleManagerFactory.java
        0.5 kB
        Aslak Hellesøy
      3. LifecycleManager.java
        0.2 kB
        Aslak Hellesøy
      4. LifecycleManager.patch
        19 kB
        Aslak Hellesøy
      5. LifecycleManagerFactory.java
        0.3 kB
        Aslak Hellesøy

        Issue Links

          Activity

          Aslak Hellesøy made changes -
          Field Original Value New Value
          Attachment LifecycleManager.patch [ 12601 ]
          Aslak Hellesøy made changes -
          Attachment LifecycleManager.java [ 12602 ]
          Aslak Hellesøy made changes -
          Attachment DefaultLifecycleManager.java [ 12603 ]
          Aslak Hellesøy made changes -
          Aslak Hellesøy made changes -
          Attachment LifecycleManagerFactory.java [ 12605 ]
          Hide
          Paul Hammant added a comment -

          Neat. I particularly like the way that makeChildContainer() passes on the same LMF.

          Methods start(), stop(), dispose() are still on PicoCOntainer. The new pluggable LM stuff is on MutablePicoContainer. Clearly at some point the were going to have to remove methods from PC.

          We've added another (optional) ctor param to DPC. I've heard comment that we should not in respect of other things like a Monitor interface.

          Show
          Paul Hammant added a comment - Neat. I particularly like the way that makeChildContainer() passes on the same LMF. Methods start(), stop(), dispose() are still on PicoCOntainer. The new pluggable LM stuff is on MutablePicoContainer. Clearly at some point the were going to have to remove methods from PC. We've added another (optional) ctor param to DPC. I've heard comment that we should not in respect of other things like a Monitor interface.
          Hide
          Paul Hammant added a comment -

          From MutablePicoContainer

          + Collection getChildContainers();

          Ack. Should this expose impl ? Some vistor concept instead ? Just a thought.

          + List getComponentInstancesOfType(Class type) throws PicoException;

          Should this not go to PC?

          Also, perhaps the to-be-deprecated start() stop() dispose() methods on PC, should be added (non-deprecated) to MPC

          Show
          Paul Hammant added a comment - From MutablePicoContainer + Collection getChildContainers(); Ack. Should this expose impl ? Some vistor concept instead ? Just a thought. + List getComponentInstancesOfType(Class type) throws PicoException; Should this not go to PC? Also, perhaps the to-be-deprecated start() stop() dispose() methods on PC, should be added (non-deprecated) to MPC
          Jörg Schaible made changes -
          Link This issue duplicates PICO-163 [ PICO-163 ]
          Hide
          Aslak Hellesøy added a comment -

          Applied. Introduced visitors and moved the getComponentInstancesOfType up to PicoContainer.

          CVS was tagged with PRE_VISITOR_REFACTORING prior to committing this, so arollback is possible should this be necessary.

          This issue is not closed yet - people can still comment on the current implementation.

          Show
          Aslak Hellesøy added a comment - Applied. Introduced visitors and moved the getComponentInstancesOfType up to PicoContainer. CVS was tagged with PRE_VISITOR_REFACTORING prior to committing this, so arollback is possible should this be necessary. This issue is not closed yet - people can still comment on the current implementation.
          Aslak Hellesøy made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Jörg Schaible added a comment -

          Forgotten to close.

          Show
          Jörg Schaible added a comment - Forgotten to close.
          Jörg Schaible made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Aslak Hellesøy
              Reporter:
              Aslak Hellesøy
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: