text: When to use "createRootApplicationModule" in Oracle ADF
  By Frank Nimphius on Nov testing ADF Business Components models. Further it explicitly mentions that "... you typically won't need to write these two lines of code in the context of an ADF-based web or Swing application. The ADF Model data binding layer cooperates automatically with the ADF Business Components layer ..."
  A question posted on OTN started a discussion about if at all there exists a use case for which the use of createRootApplicationModule in an ADF environment is appropriate. The outcome of the thread is that there doesn't seem to be a use case that requires this method call.
  All you - as a developer - want to access in ADF Business Components is accessible through the ADF BC DataControl, which is exposed by the ADF BindingContext object. I think its save to call the use of "createRootApplicationModule" in the context of ADF an anti pattern that causes more problems that it solves. Best practices for accessing the ADF Business Components Application Module to execute, write or read objects are listed below
  1. Avoid direct access to the ADF Business Components Application Module and View Object instances. Always work through the ADF binding layer in that you expose the AM functionality as a binding entry in the PageDef file. This handles the case in which managed beans are used to access functionality on the AM
  2. If you need to access an Application Module outside of an ADF bound page, for example in a servlet, then make sure the Binding Context is established. For servlets you achieve this by configuring the ADF binding filter to be used when the custom servlet is requested. This configuration can be declaratively defined in the web.xml file. When the servlet is invoked, the ADF binding filter is called and ensures the BindingContext is created.
  3. If a servlet needs to access a binding layer, or participate in ADF Security protection, you need to create a Pagedef.xml file for it and edit the Databindings.cpx file to contain a mapping that links the servlet path with the physical PageDef.xml file. Best is to copy and modify and existing entry (carefully though)
  4. Invoking a servlet, which invokes the ADF binding filter, from an ADF Faces application creates a new Data Control frame. This however means that the servlet accesses a DataControl state and AM instance that is different from what the ADF Faces application "sees". You should be aware of this and - if you need to access the exact same state - access the Data Control Frame of the calling application from the BindingContext "findDataControlFrame(String)
  ...
  import
  oracle.adf.model.BindingContext;
  import oracle.adf.model.DataControlFrame;
  import oracle.binding.DataControl;
  ...
  BindingContext
  bctx = BindingContext.getCurrent();
  DataControlFrame dcframe = bctx.findDataControlFrame(name);
  DataControl dc = dcframe.findDataControl(dcName);
  You access the current Data Control frame in the calling application from the BindingContext in a call to BindingContext.getCurrent().getCurrentDataControlFrame(). The returned string can be saved in a session variable to make it accessible for servlets.
  In general it is recommended to always work with the framework and not against it. Therefore I think we can rule out the use of the "createRootApplicationModule" method call in the context of an ADF. I also want to rule out the use of direct access to the DataControl if it is performed from a managed bean. In this case the recommendation is to expose the functionality to work with on the binding layer (unless you need to get information about the Data Control).
  Note: Credits to where credits belong. Jan Vervecken and Dimitar Dimitrov did the ground work on the thread leading to this harvest entry