Some Notes since Jun 2015

1. ViewObjectImpl.isManageRowsByKey for non-entity-based View Object:

Copied from its javadoc:

When this flag is true, a small additional overhead will be added in View row management because of the bookkeeping associated with row management by key. However, findByKey will run faster because rows with match key can be found faster. Further, when this flag is true, findByKey can avoid returning duplicate rows in that the system can check to see if the row with the given key is already in the View row cache or not. If this flag is false, findByKey may cause duplicate rows to show up in the View row cache.

This API (setManageRowsByKey) is useful when one wants to create View Object definition and VO instances at runtime.

2. JSF 2.x Exception Handler: javax.faces.context.ExceptionHandler

Sample code from its javadoc:

 } catch (Exception e) {
 FacesContext ctx = FacesContext.getCurrentInstance();
 ExceptionQueuedEventContext eventContext = new ExceptionQueuedEventContext(ctx, e);
 eventContext.getAttributes().put("key", "value");
 ctx.getApplication().publishEvent(ExceptionQueuedEvent.class, eventContext);

I am still using ADF documented way of custom error handler which works fine for me, will explore how this works with ADF 12c.

3. JSF new scope: @Dependent

Dependent (javax.enterprise.context.Dependent): Indicates that the bean depends on some other bean.

Documentation: You may want to use @Dependent when a managed bean references another managed bean. The second bean should not be in a scope (@Dependent) if it is supposed to be created only when it is referenced. If you define a bean as @Dependent, the bean is instantiated a new each time it is referenced, so it does not get saved in any scope.

Similar issue:

4. ADF 12c <af:codeEditor> does not support clob column type

varchar2 has smaller size limit, though workaround exists but it would be better for <af:codeEditor> to support clob column type as its value or accept <f:converter> as its child.

5. RowInconsistentException will not occur during the 2nd time commit

Surprisingly I didn’t notice this until recently and I found following:

So, this is expected behavior, not bug.

6. In ADF 12c (12.1.3), my old approach of using static list VO with single record as form attributes seems not working anymore

Before 12c, sometimes I create a static list VO with only one single record and then create necessary attributes, LoV(s) (either single or multi select), drag and drop to the page as form, it can then be used for many purposes. However, this is not working in 12c (v12.1.3) anymore since the attributes are “not update-able” at jsf page and page definition, although the attribute is marked as “update-able” at VO’s configuration wizard. The reason I use this technique is because static list VO with single record seems faster than using following 2 approaches:
1. “select… from dual” SQL VO, or
2. an entirely transient VO and createInsert one dummy row before rendering the page.
Moreover, static list VO allows me to use all (as far as I know) LoV features I want. I suspect maybe it’s removed due to this approach has some drawbacks that I don’t know. So in 12c (v12.1.3), I now fall back to the approach of using page definition variables as form attributes and define necessary list bindings, if it’s select one choice list, I could firstly, for example, create an page variable “abc”:

page variable

and then create a list binding in page definition:

list binding

and then choose the list data source and attribute to be set on the page variable.

list binding - model, attribute

This list binding can then be used for choice list component in the jsf page.

However, when one want multi-select choice list/lov, it seems we can’t use page variables. My current approach is, create a multi-select list binding:

mutli select list binding

then choose the attributes:

mutli select 2

This list binding could then be used for multiple-select component in jsf page. The selected value could be retrieved using following API:



(The JUCtrlListBinding could be retrieved via binding container)

7. ManagedBean Action/ActionListener is called twice

I also encountered this sometimes since long time ago.

Btw for 12c (12.1.3): in page binding definition file, tag “invokeAction” is deprecated. Before 12c, I believe we are allowed to define a method action binding and invoke it during certain adf life cycle stage with an EL expression as condition (if we want), the approach seems deprecated now.

8. <af:target> tag not working with <af:document stateSaving=”client”..>
The error is:
at java.util.ArrayList.writeObject(
at sun.reflect.GeneratedMethodAccessor291.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(

Env: JDev12c (12.1.3)

a different but related issue:

Update: Oracle has accepted this as a bug: Bug 22077672

I also found another issue in JDev12.1.3, which is if we modify web.xml and change JAVAX.FACES.PARTIAL_STATE_SAVING=TRUE then create a jsf page that contains <af:pannelCollection> with “secondaryToolbar” facet, the page will have issue after clicking the button inside the facet. Oracle has logged this as Bug 22061643.

9. Modify logger.xml to see ADF SQL executed:

Add a persistent logger: “oracle.jbo.common.ADFLoggerDiagnosticImpl” with “Finest” level, it will not slow down the server too much and debug info is adequate.


10. ADF 12.1.3 <af:dynamicComponent> component seems to have performance issue during page rendering

When we drag drop a table to the page, if we choose “Generate columns dynamically at runtime.”

drag drop table wizard

JDeveloper will generate the <af:table> code with column iterator and the cell value will be rendered using <af:dynamicComponent>. I’ve marked all fields as readOnly=true but it takes up to 8 to 10 seconds to render the <af:table>, the <af:table> has around 50 columns and it is paginated, each page shows 40 records. I understand I am not connecting to a fast DB, but 8 seconds is not acceptable. If I manually change the <af:dynamicComponent> tag to <af:outputText>, the time reduces to <= 3 seconds. This is why I suspect <af:dynamicComponent> has rendering performance issue, I am considering to raise this issue to Oracle support.

11. Adjust weblogic.xml -> max-save-post-size to increase browser max post size, this is new since v12.1.2:


Increase this value of fix following error:

weblogic.servlet.internal.MaxPostSizeExceededException: MaxSavePostSize [4096] exceeded !

12.  In VO object configuration, manually created category’s field order is not respected during rendering, it’s always rendered at the end of all other columns.

VO Category

If I go to source code view and adjust the “Field Order”, the category column position is still after all other columns. One workaround is to manually maintain all the “displayIndex” attribute in <af:column> tag in the jsf page.

display index