Oracle ADF & JDeveloper

Determining the domain home directory of integrated weblogic server

In JDeveloper, the integrated weblogic server creates its runtime domain in a directory like $HOME/.jdeveloper/system12. or $HOME/.jdeveloper/system/ While $HOME and the fixed DefaultDomain are well known, it is not so easy to determine the actual name of the system directory – one could assume that there is only one and use system* as the name, but there could be more than one, especially if more than one JDeveloper version is installed at the same time and each of them had been creating its own WLS domain. What we actually need is to get the JDeveloper version since that is what is used in the system directory name. Assumed that $JDEV_HOME is the installation directory of the JDeveloper installation for which we would like to get its domain home directory (like /opt/Oracle/Middleware/Oracle_Home/jdeveloper), then the file $JDEV_HOME/jdev/bin/ contains the full version number of JDeveloper, which is identical to the version number used in the system directory name:

$ grep VER_FULL $JDEV_HOME/jdev/bin/

To extract the version number, we can use a simple sed script like

$ sed -n 's/^VER_FULL=\([0-9.]*\).*$/\1/p' $JDEV_HOME/jdev/bin/

(we need to make sure not to include the terminating line feed, hence we only collect digits and dots after the =). Finally we can now generate the complete directoy path to the domain directory:

$ JDEV_VER=`sed -n 's/^VER_FULL=\([0-9.]*\).*$/\1/p' $JDEV_HOME/jdev/bin/`
$ DOMAIN_HOME="${HOME}/.jdeveloper/system${JDEV_VER}/DefaultDomain"
$ ls $DOMAIN_HOME/servers
AdminServerTag  DefaultServer

This can be useful for any kind of automation tasks.

Runtime-defined properties in EL expressions

Expression Language (EL) is used to access application logic (Managed Beans) from the presentation logic (JSF pages and page fragments). Assume that we have a class called com.example.SomeBeanImpl which is registered as a managed bean called someBean. Then, an expression like #{someBean.someProperty} essentially calls the getSomeProperty() method of the com.example.SomeBeanImpl class whenever the expression is used in a read operation, and calls the setSomeProperty() method of the com.example.SomeBeanImpl class whenever the expression is used in a write operation. Note that this requires that there are explicit setter and getter methods for each property accessible from an EL expression. If the expression tries to access a property for which there is no corresponding getter or setter, an exception is thrown. So, adding the getters and setters for the properties is a compile time operation – the class needs to contain the required methods. However, for some scenarios, it might be useful to be able to define properties at runtime. In fact, the ADF engine does this in several places – one example are the “row” or “node” variables for the <af:table> or <af:treeTable> components to reference one row of a table or a tree table. Even though there is one specific java class used inside the ADF runtime which represents one row or node, it is possible to access all of the table’s attributes through those classes (and the ADF runtime does not synthesize any specific classes during build- or runtime):

<af:table value="#{myManagedBean.allEmployees}"  
          var="emp">    <!-- Internally, instanciates a class used as the container for one row -->
    <af:outputText value="#{emp.ename}"/>   <!-- Accesses the "ename" property of the row -->
    <af:outputText value="#{emp.deptno}"/>  <!-- Accesses the "deptno" property of the row -->

In this example, we can access the ename and the depto properties of the row container class, even through this internal container class will certainly not have corresponding getters and setters available (as their names depend on the attributes of the associated view objects). ADF internally further routes those accesses to the proper view object rows.

EL Resolvers

The J2EE concept which allows such “dynamic” beans with properties defined at runtime is called “EL Resolvers”. Essentially, the EL engine is using EL resolvers each time it needs to evaluate an expression. For example, by default there is a BeanELResolver which resolves properties which correspond to the JavaBeans specification, using getter and setter methods as described above. However, there are also other resolvers like MapELResolver which can access properties which are stored in a Map, and it is also possible to define custom EL resolvers to implement a custom property resolver for more unique requirements. Resolvers can be chained together by using a CompositeELResolver – the CompositeELResolver iterates over all its resolvers until one resolver was able to evaluate the expression. The Java EE 5 Tutorial: EL Resolvers  gives additional information and shows a list of standard resolvers. The JavaServer Pages Specification, chapter JSP2.9: Resolution of Variables and their Properties describes the resolution process in more detail and shows the order in which the CompositeELResolver resolves properties by default. The JavaDoc at describes the Java classes used in the EL resolvers API.


A simple approach to implement beans with runtime properties as described above is to have the managed bean implement the Map interface. This lets the default CompositeELResolver use the MapELResolver to resolve its expressions. According to 5 Reasons to Use Composition over Inheritance in Java and OOP, we will not inherit from a container class, but implement the required interface and then delegate to a HashMap instance:

public class DynamicPropertyBean implements Map<String, Object> {
    public DynamicPropertyBean() {
        put("value1", 42L);
        put("value2", "Hello");

    private Map<String, Object> theMap = new HashMap<>();

    public int size() {
        return theMap.size();

    public boolean isEmpty() {
        return theMap.isEmpty();

    // All additional required methods from the Map interface

If this bean is registered with the name dynamicBean, we can access the properties “value1” and “value2” like #{dynamicBean.value1} and #{dynamicBean.value2}. All other property names will return an empty value – there will be no exception thrown, and the CompositeELResolver will also not try any other resolver further down in the chain, such as BeanELResolver, to resolve the property name. If we want to catch accesses to unknown properties, we either need to further tweek the methods which implement the Map interface (instead of simply delegating), or implement a custom EL resolver.