PicoContainer
  1. PicoContainer
  2. PICO-249

Support component specific lifecycle

          Details

          • Type: Improvement Improvement
          • Status: Resolved Resolved
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 1.1
          • Fix Version/s: 1.2
          • Component/s: PicoContainer (Java)
          • Labels:
            None
          • Number of attachments :
            0

            Description

            Current lifecycle implementation implies that all components in a container have the same lifecycle model. although the lifecycle support is part of the component's implementation. An Avalon component has a completely different LC than a component utilizing the Pico default. We mix also the LC of our own DPC with the one of the components, although the semantic of the container's LC is different:

            Container LC:
            ===========
            1. instantiation and setup
            2. explicit start of container LC support
            3. explicit stop of container LC support, may continue with (2)
            4. explicit shutdown of the container's LC

            (2) shall instantiate all components with a LC on first call and start the LC of these components resulting in an active component state
            (3) shall inactivate all activated components (but they must be activatable again)
            (4) shall end the life of the component (like finalize)

            The implementation of an individual component lifecycle can be realized with a similar approach as taken for the monitoring, but without the possibility to exchange it. We would introduce also a LifecylceStrategy interface, that can be implemented by a CA.

              Issue Links

              is depended upon by

              New Feature - A new feature of the product, which has yet to be developed. MICRO-2 Apache Avalon Phoenix compatiblity

              • Major - Major loss of function.
              • Open - The issue is open and ready for the assignee to start work on it.

                Activity

                Hide
                Permalink
                Jörg Schaible added a comment -

                After a chat we concluded, that:

                • the CA can implement a LCM and will therefore have/know a LCS instance
                • the pico will call CA.start(pico) no all CAs
                • the CA will delegate to the LCS, which may instantiate the component
                • the instantiation order will respected the pico by handling all already instantiated CAs first (and vice versa for stop/dispose)
                • the pico does not need a LCM anymore
                • InstanceCA, CachingCA and DecoratingCA will currently implement the LCM
                • the current behavior is default
                • the LCS is not changable
                Show
                Jörg Schaible added a comment - After a chat we concluded, that: the CA can implement a LCM and will therefore have/know a LCS instance the pico will call CA.start(pico) no all CAs the CA will delegate to the LCS, which may instantiate the component the instantiation order will respected the pico by handling all already instantiated CAs first (and vice versa for stop/dispose) the pico does not need a LCM anymore InstanceCA, CachingCA and DecoratingCA will currently implement the LCM the current behavior is default the LCS is not changable
                Hide
                Permalink
                Mauro Talevi added a comment -

                Moved fix version to 1.2-RC1

                Show
                Mauro Talevi added a comment - Moved fix version to 1.2-RC1
                Mauro Talevi made changes -
                Field Original Value New Value
                Fix Version/s 1.2-RC1 [ 11979 ]
                Fix Version/s 1.2 [ 11330 ]
                Affects Version/s 1.1 [ 10307 ]
                Mauro Talevi made changes -
                Assignee Joerg Schaible [ joehni ] Mauro Talevi [ maurotalevi ]
                Mauro Talevi made changes -
                Status Open [ 1 ] In Progress [ 3 ]
                Hide
                Permalink
                peter royal added a comment -

                looks good to me so far!

                Show
                peter royal added a comment - looks good to me so far!
                peter royal made changes -
                Link This issue is depended upon by MICRO-2 [ MICRO-2 ]
                Hide
                Permalink
                Mauro Talevi added a comment -

                The current solution is workable but feels like it's going against the grain of the Law of Demeter
                http://www.ccs.neu.edu/home/lieber/LoD.html

                It should remove the currentLCS() method in LCM in favour of CAs implementing LCS (optionally)
                and delegating to the injected instance of LCS.

                Show
                Mauro Talevi added a comment - The current solution is workable but feels like it's going against the grain of the Law of Demeter http://www.ccs.neu.edu/home/lieber/LoD.html It should remove the currentLCS() method in LCM in favour of CAs implementing LCS (optionally) and delegating to the injected instance of LCS.
                Hide
                Permalink
                Mauro Talevi added a comment -

                Refactor done.

                Still todo: remove reference of LCM from MPCs, as lifecycle is now managed by the CAs.
                On invoking the LC methods the MPCs should delegate to each of the CAs.

                The DefaultLCM and CustomLCM are now obsolete and should be removed.

                Show
                Mauro Talevi added a comment - Refactor done. Still todo: remove reference of LCM from MPCs, as lifecycle is now managed by the CAs. On invoking the LC methods the MPCs should delegate to each of the CAs. The DefaultLCM and CustomLCM are now obsolete and should be removed.
                Mauro Talevi made changes -
                Summary Support component specific lifecylce Support component specific lifecycle
                Hide
                Permalink
                Mauro Talevi added a comment -

                Refactor finished.

                I've replaced DefaultLCM and CustomLCM with a DelegatingLCM which is not injected but used as an impl detail
                by DPC. It has been left as a separate class not to clutter up the DPC impl, and to allow an easy change of impl,
                as well as re-use in other impls of MPC.

                If we move towards an inheritance impl model for the MPCs, it could also become a protected inner class in DPC.

                Thoughts?

                As for the outstanding work - I think it would only benefit with writing additional testcases with unusual LC scenarios
                in the new refactored impl.

                Show
                Mauro Talevi added a comment - Refactor finished. I've replaced DefaultLCM and CustomLCM with a DelegatingLCM which is not injected but used as an impl detail by DPC. It has been left as a separate class not to clutter up the DPC impl, and to allow an easy change of impl, as well as re-use in other impls of MPC. If we move towards an inheritance impl model for the MPCs, it could also become a protected inner class in DPC. Thoughts? As for the outstanding work - I think it would only benefit with writing additional testcases with unusual LC scenarios in the new refactored impl.
                Hide
                Permalink
                Mauro Talevi added a comment -

                Perhaps DelegatingLCM could be renamed ComponentAdapterLCM,
                as usually DelegatingXXX implies a delegate being injected?

                Show
                Mauro Talevi added a comment - Perhaps DelegatingLCM could be renamed ComponentAdapterLCM, as usually DelegatingXXX implies a delegate being injected?
                Hide
                Permalink
                peter royal added a comment -

                I agree on the rename. CALCM makes more sense.

                Looks good from the commits, will review more in depth later.

                Show
                peter royal added a comment - I agree on the rename. CALCM makes more sense. Looks good from the commits, will review more in depth later.
                Hide
                Permalink
                Mauro Talevi added a comment -

                Refactored DelegatingLCM to DPC.OrderedComponentAdapterLCM inner class to ensure order of dependency of instantiation of components is preserved.

                Show
                Mauro Talevi added a comment - Refactored DelegatingLCM to DPC.OrderedComponentAdapterLCM inner class to ensure order of dependency of instantiation of components is preserved.
                Mauro Talevi made changes -
                Status In Progress [ 3 ] Closed [ 6 ]
                Resolution Fixed [ 1 ]
                Mauro Talevi made changes -
                Resolution Fixed [ 1 ]
                Status Closed [ 6 ] Reopened [ 4 ]
                Hide
                Permalink
                Mauro Talevi added a comment -

                Changed fix version of 1.2-RC-1 to 1.2 to have a complete changelog for 1.2

                Show
                Mauro Talevi added a comment - Changed fix version of 1.2-RC-1 to 1.2 to have a complete changelog for 1.2
                Mauro Talevi made changes -
                Fix Version/s 1.2-RC1 [ 11979 ]
                Fix Version/s 1.2 [ 11330 ]
                Mauro Talevi made changes -
                Resolution Fixed [ 1 ]
                Status Reopened [ 4 ] Resolved [ 5 ]

                  People

                  • Assignee:
                    Mauro Talevi
                    Reporter:
                    Jörg Schaible
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    0 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: