Some weeks ago I was hardly affected by an old issue about Java Server Faces (JSF) in the Sun/Oracle mojarra implementation which Wildfly/JBoss incorporates. The bug indeed is quite obvious, when you mix JSF and the JavaServer pages Standard Tag Library (JSTL) some components can be duplicated at refreshing time. The issue has an easy test-case and it was explained in detail in this mojarra bug. The JSF framework maintains a tree of components that represents the page/view (the tree can be stored at the server side or the client side). The components are refreshed constantly when the user interacts with the page. A composite is a reusable facelet component that is composed by more components (the composite is defined and then reused in different pages). On the other side JSTL is the old tag library already used in the JSP technology (common tags like <c:if>, <c:forEach>, <c:set>,...) and, obviously, both technologies act a different level. The JSTL runs when the view is build (for example if there is a <c:if> that resolves to false, that part of the view is not created), then JSF/facelets runs over the generated view to create the tree. Simplifying it, JSTL runs first from top to bottom and then hands over the result to JSF which in turn runs from top to bottom again.
So, when you mix both technologies you have to be specially cautious because of this special interaction. The bug was caused by using the same composite several times in the tree with a JSTL component modifying the number of its inclusions (for example a <c:if> which makes a second instance of a composite to be rendered or a <c:forEach> that adds the same composite different number of times). The special interaction between the two technologies complicated the resolution for a long time. Because of the fact that developers have to be cautious mixing both, the issue was always considered by mojarra maintainers like a developer error and never like a bug. During several years the problem remained there with bugs filed and rejected, questions in several threads and blog entries about it. Besides JSF is now an old and disappearing technology, fact that complicates even more the resolution (remember that now the presentation layer has moved entirely to the browser side, using javascript frameworks).
In my new job I discovered that several JBoss cases were very similar, same problem reported and always answered by the same mantra: try not to mix JSTL and JSF cos it gives problems. At first I just repeated the mantra but, seeing two or three of them with a similar description and not having a real reason to not use JSTL and JSF together, I decided to investigate further. Checking the test-case in previous mojarra bug I got fully convinced that this was a real bug and not an improper use of IDs by the developer. And I finally deep dived into the code to try to understand the real problem. I have to say that JSF is a really complicated framework and I spent several days hacking the code (getting tired, desperate sometimes, going in circles, trying a lot of things that did not work, doing another things to make me relax and think different, trying again,...) but finally I understood the bottom problem. As always, the final reason was not very complicated and it could be fixed with a few lines of code. I gave a detailed explanation in the same bug if you are interested in the details.
Nevertheless, mojarra is very convoluted, and my little patch could affect somewhere else, I needed to test it a bit better. The mojarra implementation has some good automated test suite, so I decided to pass the suite and, if no new error was reported, comment in the bug and present my patch. Following this guide I installed again a glassfish server to run the tests. Things now are a bit different and some tricks were needed to make the automatic tests run properly but, after setting everything in place, all the tests passed without any problem, and there are a lot, so finally I was confident that my patch went in the correct direction. Using the same bug report I added two comments in it, the first one explaining the issue just as I understood it, and the second one with the patch. After some days of silence the patch moved on (my team internally pressed a lot to try to reach Oracle) and now the patch is applied in all the 2.2 and 2.3 branches (even an automated test has been added to the suite for this issue). I hope they also move the test to master because it would be a real pity that future versions were released with this insidious bug still present.
Yesterday I realized that new mojarra versions 2.3.1 and 2.2.8-22 had been released, and the patch is incorporated in both. So I suppose that silently all depending projects will be updating to them (JBoss included). That is the reason for this entry. It was a nice challenge to make it work, I am a newbie in my company, and I was in the middle of a problem in a library that was implemented by a another company (a company I worked for before). So it was a nice experience, learning how things work at this level. But you know how I think...
Never compromise, not even in the face of Armageddon. (Rorschach - Watchmen)
Comments