Metadata
- Source
- FLUID-4711
- Type
- Bug
- Priority
- Major
- Status
- Closed
- Resolution
- Fixed
- Assignee
- Antranig Basman
- Reporter
- Antranig Basman
- Created
2012-05-23T01:13:09.178-0400 - Updated
2012-08-06T00:28:56.598-0400 - Versions
-
- 1.4
- Fixed Versions
-
- 1.5
- Component
-
- IoC System
Description
GPII framework "requests.js" exposed this issue. At the lifecycle point of request end, that framework calls instantiator.clearComponent on the "request component" in order to clear it away. For a start, this is by default a very aggressive method which by default rips through all component found, recursively clearing their subcomponents - as well as removing them from both the "idToPath" and "pathToComponent" records. The former effect can be defeated by the rather messy extended signature using the "noModTree" option as in
instantiator.clearComponent(that, name, null, null, true);
but the idToPath effect cannot be defeated, which ends up corrupting the instantiators records, in the case the component had subcomponents which were injected from a larger scope (that is, "application scope" in Spring-speak).
This implementation needs to be improved in order to keep records of components which were delivered through direct injection rather than being constructed "in situ" by the action of initDependent, and to ensure that ONLY the pathToComponent record is cleared in this case.
Comments
-
Colin Clark commented
2012-08-02T20:01:18.326-0400 Reviewed and pushed to master at 67da204..722ba14