Lifecycle issue with table binding + read-only attributes: ADF BUG

Question

Hello all,
I have found what I believe to be an easily reproducible bug in ADF that reproduces in 10.1.3.x, but not in 11g (at least not in drop 6). The best way to describe the bug would be to walk through a simple set of steps to reproduce the bug:
1). Create a new application (ADF BC + ADF Faces).
2). In the model project, create a new Entity Object from the Employee table in the default HR schema. Allow JDev to create an updatable view object and an AM as well.
3). Put a validation rule on the first name attribute of the EO (can be anything, really - I made mine so that the first name cannot be "foo").
4). Test everything using the BC tester if you like.
5). In the UI project, create a new JSPX page.
6). Drag the updatable VO on to your page as an updatable af:table.
7). Put an af:commandButton on the page. Bind its Action or ActionListener to a method in a new backing bean. Put some simple code (I used System.out.println) in the backing bean method.
8). Run the jspx page.
9). Put some invalid data in (e.g. "foo" in the first name field) and click the af:commandButton. Verify that you get an error message and that the Action/ActionListener method DOES NOT fire. So far, so good.
10). Now, to demonstrate the problem. First, look at the page definition for the jspx file. Identify the first attribute that is mentioned (in my case, it was the employee id).
11). Go to the updatable view object and make the attribute from #10 read-only or updatable when new only.
12. Now, repeat step 9 - you should see the error message AND also see that the Action/ActionListener method was executed. You will also see in the messages window that ADF attempted to set the value of the read-only attribute, and thus got a ReadOnlyAttrException.
This issue only happens if the first attribute mentioned in the table binding is read-only. A workaround would simply be to re-order the attributes in the table binding of the pagedef so that the first attribute isn't read-only.
Don't ask how I figured this out ;)
Best,
John

Answer 1

Hi Frank,
Yes, I simply scripted it out this way to contrast the behaviour if the first attribute was read-only vs not read-only. I found the issue on a page in our app that was simply drag-and-drop the VO from the data control on the page.
It's quite annoying, because our particular use case that hit this error is a "save" button on the page. If the commit operation doesn't return any errors (and it doesn't in this use case!), we add a JSF message saying "save successful" - then the attribute errors are further added later in the page lifecycle, so we get 3 messages: "Save successful" and "Fix this error" and "Tried to set read-only attribute" - quite confusing to the end-user when the only message they should see is "fix this error."
At any rate, the fix is to simply re-order the attributes in the page definition - that doesn't affect the UI at all, other than to fix this issue.
John