Dive into Oracle ADF

Send me a mail
 Dive into Oracle ADF   Click to see the XML version of this web page.   (Updated: 7/27/2009; 4:54:13 PM.)
Tips and tricks from Steve Muench on Oracle ADF Framework and JDeveloper IDE

Search blog with Google:

Search BC4J JavaDoc:

July 2009
Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Jun   Aug

Get Firefox!

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Monday, July 27, 2009

When you migrate your ADF 11.1.1 application to, if you happen to have attributes with names like Category, Reference, PropertyValue, Sequence, or several others, then you may notice that your application malfunctions where it references these attribute names in Groovy scripts/expressions. One situation where the problem occurred for me was in a bug tracking application with cascading LOVs. I had three fields with LOVs configured -- Product, Category, Subcategory -- and the view accessor used by the Subcategory LOV contained bind variable Groovy expressions of:

  • BindVarProduct => Product
  • BindVarCategory => Category

When I ran the application in ADF, the Subcategory LOV never returned any rows. In the debugger, I was able to set a breakpoint in the bindParametersForCollection() method of ViewObjectImpl to study the values of the bind variables for the view accessor's query, and I noticed that the BindVarCategory bind variable was being assigned a value of type java.lang.Class (the object representing groovy.lang.Category class) instead of a String with a value like "SOME_CATEGORY", so of course the query returned no rows.

Groovy issue# 3451 complains about a change in behavior between Groovy version 1.5.4 used by ADF and the Groovy 1.6.0 release used by ADF Groovy 1.6 changed the order of resolution for a symbol like Category to first resolve to the name of a class visible in the current classloader before giving a scripting client like ADF BC a chance to resolve the name to the value of a row attribute.

The workaround is to change the Groovy script to reference adf.object.Category instead of just Category (or whatever the offending attribute name is). The complete list of attribute names that can cause problems includes the name of every class in the java.lang and the groovy.lang packages (which are auto-imported by the Groovy runtime). You can consult the text of bug# 8732845 in Metalink (or the JavaDoc for these two packages) for a complete list of class names that can cause problems in Groovy scripts if used as attribute names and referenced in an unqualified way.

4:54:13 PM    

In releases prior to, if you used custom ADFBC domain classes to encapsulate common datatype validation into a reusable value class, you needed to create a custom JSF converter to handle data entry in your JSPX pages. Failure to do so would result in errors like:

Cannot convert of type class java.lang.String to  class  fusion.bugtracker.model.datatypes.common.OracleVersionNumber

Now in, ADF Faces registers a built-in converter you can use for this purpose. Just reference the converter with id "oracle.genericDomain" like this:

                    <af:inputText value="#{bindings.ProductVersion.inputValue}"
                      <f:converter converterId="oracle.genericDomain"/>
                      <f:validator binding="#{bindings.ProductVersion.validator}"/>

2:05:20 PM    

© Copyright 2009 Steve Muench.