PicoContainer
  1. PicoContainer
  2. PICO-56

Removing child containers is impossible

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0-beta-4
    • Component/s: PicoContainer (Java)
    • Labels:
      None
    • Number of attachments :
      0

      Description

      the current container hierachy model doesn't support removing a child containers from a parent since getChildContainers() returns Collections.unmodifiableCollection(children);

      this is big problem when u are using containers for different scopes and one scope ends.

      eg. [servlet enviroment - MPC = MutablePicoContainer]

      MPC sessionPico = (MPC)session.getAttribute(KEY);
      MPC requestPico = createMPC();
      requestPico.addParent(sessionPico);
      request.setAttribute(KEY, requestPico);

      once the request is done requestPico should be removed but u can't. the result is an ever growing collection of picos + the object instances attached to them.

      in addition to that i think a call to addParent(...) shouldn't internally call parent.addChild(...) since this forces 2 ways relationships which might not be appropriate in some cases.

        Activity

        Hide
        Joe Walnes added a comment -

        I second this.

        Show
        Joe Walnes added a comment - I second this.
        Hide
        Niels Bech Nielsen added a comment -

        I "third" that

        It is impossible to circumvent the problem without rewriting the container.

        Perhaps create two styles:
        addParent/addChild - One way explicit reference
        linkParent/linkChild - Two way reference.

        While at it, why the difference in return value:
        public Collection getChildContainers()

        { return Collections.unmodifiableCollection(children); }

        public List getParentContainers()

        { return Collections.unmodifiableList(parents); }

        There seems to be no reasoning on the difference??

        Show
        Niels Bech Nielsen added a comment - I "third" that It is impossible to circumvent the problem without rewriting the container. Perhaps create two styles: addParent/addChild - One way explicit reference linkParent/linkChild - Two way reference. While at it, why the difference in return value: public Collection getChildContainers() { return Collections.unmodifiableCollection(children); } public List getParentContainers() { return Collections.unmodifiableList(parents); } There seems to be no reasoning on the difference??
        Aslak Hellesøy made changes -
        Field Original Value New Value
        Status Unassigned [ 1 ] Assigned [ 2 ]
        Assignee Aslak Hellesoy [ rinkrank ]
        Hide
        Aslak Hellesøy added a comment -

        I have added removeParent and removeChild methods. the add/remove Child/Parent methods still call each other, so that mutual dependencies remain consistent.

        If you want to disable this feature, please raise a separate issue.

        Show
        Aslak Hellesøy added a comment - I have added removeParent and removeChild methods. the add/remove Child/Parent methods still call each other, so that mutual dependencies remain consistent. If you want to disable this feature, please raise a separate issue.
        Aslak Hellesøy made changes -
        Fix Version/s 1.0 [ 10145 ]
        Status Assigned [ 2 ] Closed [ 6 ]
        Resolution Fixed [ 1 ]
        Aslak Hellesøy made changes -
        Resolution Fixed [ 1 ]
        Status Closed [ 6 ] Reopened [ 4 ]
        Aslak Hellesøy made changes -
        Fix Version/s 1.0-beta-4 [ 10412 ]
        Status Reopened [ 4 ] Closed [ 6 ]
        Resolution Fixed [ 1 ]
        Fix Version/s 1.0 [ 10145 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 1 hour
              1h
              Remaining:
              Remaining Estimate - 1 hour
              1h
              Logged:
              Time Spent - Not Specified
              Not Specified