Metadata
- Source
- FLUID-4626
- Type
- Bug
- Priority
- Major
- Status
- Closed
- Resolution
- Fixed
- Assignee
- Antranig Basman
- Reporter
- Antranig Basman
- Created
2012-02-29T00:28:52.884-0500 - Updated
2014-03-03T13:00:01.591-0500 - Versions
- N/A
- Fixed Versions
- N/A
- Component
-
- IoC System
Description
The following report is triggered -
fluid.fail("Error in applyInstantiator: user instantiator supplied with id " + userInstantiator.id
+ " which differs from that for currently active instantiation with id " + existing.id);
}
We actually need to move back to the historical scheme of maintaining an instantiator stack in parallel with the execution stack, if we want to continue with the facility for restoring a "local" instantiator across an event boundary, which we probably do. This created a problem with UIOptions/videoPlayer integration as an event dispatched from UIOptions model update to an invoker within the videoPlayer which resulted from a separate instantiation. This has probably never been seen in CSpace since it follows a more "modern" model of using a single instantiator throughout.
Comments
-
Antranig Basman commented
2012-02-29T00:32:29.212-0500 Note that FLUID-4192 ("broken trees") also requests an instantiator stack
-
Michelle D'Souza commented
2012-03-21T16:45:31.415-0400 Merged into project repo at edc04019823ec25614286d262589ab5fca33a0f6