Another bug(?) that I have hit with ADF (220.127.116.11). This, again, has to do with lovs and list binding. This issue surfaced in a BPM Human Task form. One of the payload fields on the form was implemented as a selectOneChoice and the data source for the list came from a Web Service data control. On submission, the payload was filled with what looks like a .toString of an oracle.jbo.Key object – oracle.jbo.Key [0, 0]. I have now isolated this to a simple test case – using Web Service data controls for both the base data and the list data. The workspace is here: . To test, simply run the testpage, fill in the values on the form, click Submit and view the console output.
The form is implemented based on Shay’s example here. So, the base web service includes two operations – findWSRequest to fetch the object and updateWSRequest to post back the updated data. The updateWSRequest operation simply prints out the value of the lovItem that has been posted back to the web service.
Update: Oracle’s explanation
“Key” is a reserved word for an attribute on an ADF entity object or ADF view object because the RowImpl class from which both EntityImpl and ViewRowImpl extends, contains a method named getKey(). Since ADFBC supports the optional generation of a custom Java class and along with that option, the optional generation of Java Beans no-argument getter methods for typsesafe programmatic access to the object’s attributes, having an attribute named “Key” or “key” would require that its Java Beans no-argument getter method would be getKey() and this method would conflict with the existing getKey() method.
So, looking at the list of no-argument public getter methods on the ViewRowImpl class, we can produce a list of attribute names that will cause similar clashes.