Correcting Failures to Display Data (continued)
To debug all executables for the binding container, perform the following steps:
1. In the oracle.adf.model.binding.DCBindingContainer class, set a breakpoint on internalRefreshControl(int, boolean) as the entry point to debug the executables.
2. In the oracle.adf.model.binding.DCIteratorBinding class, set a breakpoint on callInitSourceRSI() to halt processing and step into the method.
3. When processing pauses, look for callInitSourceRSI() in the Stack window. The result displayed in the Smart Data window should show the result that you expect.
When your Web page fails to display data from a method iterator binding, you can drill down to the entry point in JUMethodIteratorDef.java and its nested class JUMethodIteratorBinding to debug its execution.
To debug the method iterator executable for the binding container, perform the following steps:
1. In the oracle.jbo.uicli.binding.JUMethodIteratorDef class, set a breakpoint on initSourceRSI() as the entry point to debug a method iterator binding executable.
2. Set a breakpoint on invokeMethodAction() to halt processing and step into the method. Note that if the method returns a valid collection or a bean, then that object becomes the data source for the rowset iterator that this iterator binding is bound to. For bean data controls, an instance of DCRowSetIteratorImpl is created to provide the rowset iterator functionality for the iterator binding to work with. (Note that for ADF Business Components, this method would ideally return a ADF Business Components rowset iterator so that ADF Business Components can manage the state of the collection.)
3. When initSourceRSI() returns a rowset iterator, pause processing and look for mProvider in the Smart Data window. The mProvider variable is the data source fetched for this rowset iterator. If the method completes successfully, it should show a collection bound to an iterator or a bean.
When the executable that produced the exception is identified, check that the <executables> element in the page definition file specifies the correct attribute settings.
Whether the executable is refreshed during the Prepare Model phase, depends on the value of Refresh and RefreshCondition (if they exist). If Refresh is set to prepareModel, or if no value is supplied (meaning it uses the default, ifneeded), then the RefreshCondition attribute value is evaluated. If no RefreshCondition value exists, the executable is invoked. If a value for RefreshCondition exists, then that value is evaluated, and if the return value of the evaluation is true, then the executable is invoked. If the value evaluates to false, the executable is not invoked. The default value always enforces execution.