check please 3.3.3 I checked under rf-demo sample. added inputs with double range validators in table and subtable - after submit see messages and "a" letters in both cases.
I tried the latest jar files (3.3.3-beta) as per your suggestion, but the problem still appears. I entered in invalid amounts into all rows in the datatable, but the invalid values were not retained on the first row. Any other suggestions?
I know this worked in the 3.1.x branch (because we succesfully implemented a project with the 3.1.x branch), but I can't get it to work with the 3.3.x branch or the last release from the 3.2.x branch.
could you please attach simple war sample ?
I would like to follow up with you on this bug. I am taking over for Brian Kates (we work together).
I was able to reproduce the bug in a small test app. I made a war file and I would appreciate it if you could take a look.
I can see why you were not able to recreate the bug earlier. It was quite difficult for me too, and it turned out to be connected to the Tomahawk messages tag! Basically, if there is a <t:messages .../> tag present on the page, the RichFaces datatable will lose the values in the first row, as Brian described. Removing <t:messages .../> fixes the problem...
Could you please take a look at what's going on there? Is this a RichFaces bug, or a Tomahawk bug?
I can't attach my WAR file here, b/c it is over the 15MB limit due to all of the libraries that came in with Tomahawk. So, I am hosting the file on my server here: http://vace.homelinux.com/unprotected/datatable-first-row.war
The test page is at /pages/index.jsf. In order to see the bug in action, type some garbage into "Sub Row 1" and "Sub Row 2". Press "Save". Note that the value was retained in the 2nd subrrow, but erased from the first.
Please let me know what you find, or if there are any issues with the WAR file.
At first thanks for your patience and efforts. Unfortunatelly I still can't seems see the issues in action. Look to the screenshot attached. It's occured on clicking save. I've deployed your application without any modifications.
B.t.w. you have two JSF implementations in web-inf lib. It's definitelly not allowed and could rise classloading issues.
a.png 24.9 K
Oops - sorry about that, Ilya. I forgot to clean my maven target dir after switching to MyFaces. I wasn't running the app from the war, so i didn't notice. This is likely why you couldn't reproduce - the bug only appears with MyFaces and it was probably using the classes from the reference implementation when you deployed it.
I am attaching the fixed war file now. I just deployed this war into a Jetty 6 server and was able to reproduce the bug. I am also attaching a screenshot. Please try it again.
some bad luck with the samples :/ this one reported as broken archive by tomcat and just zip unpacker :/
Hmm, I think something went wrong during your download.
I have just downloaded the file I posted from the forum and ran it in Jetty w/o any trouble. I can also unpack it with either the 'jar' or 'unzip' utility.
Could you please check the MD5 sum of the WAR you downloaded? It should be de638eb1903fba756eb9b29f98baf941. If it's not, then it got corrupted when you were downloading it.
Just in case, I am putting it on my server again for an alternative way to download: http://vace.homelinux.com/unprotected/datatable-first-row.war
Let me know how it goes.
now downloaded fine. And yes.. could see the issue. And it's really not reproduces if add rich:messages instead of t: ones.. or just remove last ones.. need to check more.
looks like the problem is wider than expected.. some close issues
Maybe it would be easier to use rich: or h: messages as a workaround.. To be honest I still can't find reason of connection this to t:messages usage for now.
Thanks - I tried both the h and rich messages and they both worked. This is an acceptable workaround for us.
Thanks for taking a look, Ilya.
If you ever figure this out, I would appreciate it if you post your finding here. I am really puzzled by this connection between <t:messages /> and the data table as well, so I am very curious.
I believe I found the connection between <t:messages /> and the <rich:dataTable />.
When the Tomahawk messages tag is getting rendered, it first constructs a map of all labels on the page. Then it tries to lookup the appropriate label for the error it is rendering. If it couldn't find the label associated with the clientId of the input with the error, it will attempt to check if the input field is inside a data table, so it can use the column header as the label. And that's when we run into trouble.
In order to find the input field, it uses this code:
UIComponent comp = facesContext.getViewRoot().findComponent(inputClientId);
The above line causes a recursive traversal of the tree, which will cause the UIData components to restore the row states in order to match on the clientId of the input fields inside. This is what appears to trigger the bug. Commenting out that line makes the bug go away.
For my project I've modified the Tomahawk renderer to avoid doing the column header lookups, but that's just a hack. Since there is nothing wrong with doing the traversal Tomahawk is trying to do, I believe that we are looking at a RichFaces bug that needs to be investigated.
I hope this information will be useful for your troubleshooting.
P.S. The code I was referring to is in org.apache.myfaces.renderkit.html.ext.HtmlMessageRenderer.findInputLabel(), line 166