When you migrate your ADF 11.1.1 application to 11.1.1.1, 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 11.1.1.1.0, 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 11.1.1.0.x and the Groovy 1.6.0 release used by ADF 11.1.1.1. 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 
|
