Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The instantiator is the central record-keeping structure of the IoC system, and so is usually an enormous help in debugging when encountering a situation where the framework's understanding of a situation seems to disagree with yours. In current incarnations of the framework, these are harder this is very easy to come by naturally occuring on the framework's own stackframes than they used to be - although the core loop passing through fluid.initDependent for each component instantiation remains a good place. These days, the framework tends to look these up as needed using the call fluid.getInstantiator(that) given any component instance, and you can do the same. In the future, when FLUID-5249 is implemented, there will just be one instantiator per instance of Infusion and it will be conveniently advertised at a well-known public place, since the global instantiator holding records of all currently instantiated components is kept in the well-known global fluid.globalInstantiator. It's very helpful to permanently keep a "watch" expression in whatever debugger you are using pointed at this value.

What to see inside the instantiator

The most useful instantiator contents are the two giant lookup tables pathToComponent and idToShadow. The first can be used to quickly see the global layout of the entire component tree of which this component is a part - it is keyed by the EL path of each component with respect to the component root, and the values are the components themselves. The second is less generally useful to users, but is a lookup keyed by the component's id to its shadow record. This table is useful in cases where the framework has logged a diagnostic mentioning the id of a component - information about the component can be looked up by id here. Each component has such a bookkeeping record associated with it, most of the contents of which are not very helpful for debugging. However, generally useful members include that, holding a reference back to the original component, path, holding its EL path as appearing in pathToComponent, and contextHash, holding a hash of all of the context names of the component to true. Another useful member of the shadow is injectedPaths which lists all the paths in the component tree to which this component has been injected.

How to deal with timing issues during construction

...