LifecycleManager refactoring

Details

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

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. Java Source File
    DefaultLifecycleManager.java
    23/Jul/04 5:11 PM
    3 kB
    Aslak Hellesøy
  2. Java Source File
    DefaultLifecycleManagerFactory.java
    23/Jul/04 5:11 PM
    0.5 kB
    Aslak Hellesøy
  3. Java Source File
    LifecycleManager.java
    23/Jul/04 5:10 PM
    0.2 kB
    Aslak Hellesøy
  4. Text File
    LifecycleManager.patch
    23/Jul/04 5:09 PM
    19 kB
    Aslak Hellesøy
  5. Java Source File
    LifecycleManagerFactory.java
    23/Jul/04 5:11 PM
    0.3 kB
    Aslak Hellesøy

Issue Links

duplicates

Improvement - An improvement or enhancement to an existing feature or task. PICO-163 Better pluggable lifecycle

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Hide
Permalink
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.
Hide
Permalink
Joerg Schaible added a comment -

Forgotten to close.

Show
Joerg Schaible added a comment - Forgotten to close.

People

  • Assignee:
    Aslak Hellesøy
    Reporter:
    Aslak Hellesøy
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: