In Oracle ADF, each definition object (those objects which are used as the templates for actual objects) has a scope which can be either session based or application based (shared between sessions). The following diagram shows a rough (and probably somewhat incomplete) overview of the runtime structure of some of the most common objects (Entity object, View object, Application Module) and their corresponding definition objects:
Creating definition objects
Essentially, there are two possible ways how to create a definition object:
- From an .xml file, as shown on the left side of the diagram. This is what the framework does automatically in the background. Each of the definition objects has a protected static loadFromXML() method which is used by the framework to load the corresponding .xml file.
- Programmatically by calling the default (or single parameter name) constructor of a definition object, as shown on the right side of the diagram.
The meta object manager
When a new definition object has been created, it should be registered with the meta object manager so that it can be looked up by its name later. This is done by calling the registerDefObject() method on the definition object:
ViewDefImpl mydef = new ViewDefImpl("view.DataVO"); ... mydef.registerDefObject();
The meta object manager is an application wide singleton, and it has a method dumpMOM() which can be used to dump the definition objects which are currently registered:
MetaObjectManager mom = MetaObjectManager.getSingleton(); mom.dumpMOM(new PrintWriter(System.err), true);
<< Shared DefinitionContext >> -- oracle.jbo.mom.DefinitionContextAgeable.dumpMOM -- ... << Session DefinitionContext >> -- oracle.jbo.mom.DefinitionContextAgeable.dumpMOM -- ...
Note that the parameter-less dumpMOM() overload prints to System.out, which might overlap with other ad-hoc debug output on System.err you might be using in your test application (you would never use System.out or System.err in production code anyway). Internally, the meta object manager uses entries in the ADFContext‘s applicationScope and sessionScope maps – so it is capable of managing session specific objects even though itself it is an application singleton.
When modifying definition objects at runtime, make sure that you are not modifying application scoped definition objects (unless your intention is that all objects in all sessions derived afterwards will inherit this modification). Instead, programmatically create a session scoped definition object, or use the instance specific methods for the modifications. For example, instead of modifying or creating a new ViewDefImpl object with a specific query string and then create a ViewObjectImpl based on it, it is also possible to set the query string directly on the ViewObjectImpl itself – it then only affects this particular view object instance.