A common pattern observed on OTN is the use of the createRootApplicationModule method on
an ADF Business Components Application Module (AM) to access a View Object.
Usually a question and associated sample code is posted by developers
struggling to see data updates displayed in ADF views. The Fusion Developer's Guide for
Oracle Application Development Framework product documentation explains the use of the createRootApplicationModule method in the
context of creating a command line test case for 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
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
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.
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)
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
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
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
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