Details
-
Type:
Improvement
-
Status:
Closed
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.1
-
Component/s: None
-
Labels:None
-
Number of attachments :
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.
Issue Links
- duplicates
-
PICO-163
Better pluggable lifecycle
-
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 -
| Attachment | DefaultLifecycleManagerFactory.java [ 12604 ] |
Aslak Hellesøy
made changes -
| Attachment | LifecycleManagerFactory.java [ 12605 ] |
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
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 -
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
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 ] |
Forgotten to close.
Jörg Schaible
added a comment - Forgotten to close. Jörg Schaible
made changes -
| Status | Resolved [ 5 ] | Closed [ 6 ] |
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.