ViewParam + Ajax Call issue #4734
Comments
|
@soul2zimate can you have a look? I will try again to reduce the code to not use PrimeFaces. |
It would be very helpful to provide a reproducer that doesn't use PrimeFaces. If this is not possible, maybe the bug is in PF? |
|
It's not a PF bug, because with Mojarra 2.2 it works. And also MyFaces 2.2 or 2.3 |
That does provide a good hint, though it could still be something PF does that just happens to work there. Anyway, a reproducer without PF would be really cool to have ;) |
@arjantijms I was able to reduce to a pure mojarra code and updated the issue description. If you can, please look to this issue. |
|
@arjantijms @erickdeoliveiraleal I don't understand why the exception appears at the second time, but this @erickdeoliveiraleal Could you try the solution at https://www.thetopsites.net/article/58334699.shtml ? add the required changes for |
I used it now and I got the same result. |
|
@erickdeoliveiraleal This is definitely an interesting case which may be related to some extreamly intermittent issues I've been having with Mojarra and Wildfly going back to earlier wildfly released (at least 14 and may earlier). The issue always presents as a It is a situation where I would have expected a view expired exception but instead get a null on a bean that should exist. That said it has been impossible to reproduce on my end. The closest I have gotten is this Wildfly issue https://issues.redhat.com/projects/WFLY/issues/WFLY-13666 which I feel like could be related, but only started presenting in Wildfly 19 and higher. Though this feels more like an undertow issue. |
|
I updated the code
It's not intermitent, it's always present, if you copy and paste my code and run on WildFly 21 or any other server the error appears, I posted an example in Jetty using primefaces-test repository, just enter the page without any parameters filled, press the button more than one time and the error appears. I tested it against other servers and different versions of JSF 2.3, the bug is always there. |
|
project.zip |
|
It seems this fails due to the same broken change made in javaserverfaces/mojarra@4c74d1f since Mojarra 2.3. That change leads to a call on IMHO, getting a converted value for a null value doesn't make sense. However the idea of javaserverfaces/mojarra@4c74d1f is to ensure that validation logic gets a chance to be executed If the Below change in UIInput.java can avoid the exception described in this issue, but I can't explain why this eventually makes the Based on previous story around this class, in order to prevent any unexpected regression, I would really appreciate opinions from JSF experts who are familiar with this piece of code. |
|
@BalusC Can you take a look at it? I think you're most experienced with the |
|
javaserverfaces/mojarra@4c74d1f says this
My initial proposal was to modify ONLY the I cannot rollback the original change from issue 1329 anymore as it's basically already set in stone in JSF 2.3 API. So I'll have to focus on fixing the |
|
Hm. I cannot reproduce your problem but I have spotted a handful things being odd in your reproducer:
When I have corrected them as below: Then your use case of opening I'll nonetheless analyze your specific case further as this should IMO indeed not happen. |
|
Really? You tested against JSF 2.2 and couldn't verify a different behaviour? |
|
I tested against Mojarra 2.3.14. |
|
Yes, I tested against 2.3.14 and 2.2.20 and there's an exception that shows in JSF 2.3 and not in 2.2 |
|
until tomorrow I will test it again and report here. |
|
Have you actually read the entire comment? I have fixed at least three incorrect things in your code snippet. It could be in one of them. I'll analyze further. |
|
Sorry for misinterpret your answer @BalusC and thanks for the analysis |
|
Sorry, I still cannot reproduce it after changing the code logic to exactly match the code logic posted in this ticket. I even downloaded WildFly 21 and tried its bundled Mojarra 2.3.14.SP01 instead but it's also working fine over there. I'll try checking out your actual project. |
|
Nevermind, I have reproduced it with the provided code snippet when opening the page via It's indeed also happening after I correct the converter and the default selection. This all is caused by unexpected usage of the view parameter as in |
|
I have analyzed the logic and it appears to be a general problem with input components. This won't necessarily only happen in f:viewParam, but all other inputs are prone to this issue as well when the nested property is null. Indeed, generally the converter shouldn't need to be located when the supplied submitted value is null, but the spec doesn't forbid this condition. So an obscure custom converter might exist somewhere in the world which does a specific thing when a null value is passed as submitted value. I've opted to fix this issue in Mojarra by simply suppressing any PR: #4801, ran The 'correct' fix for your specific use case would be to just use in combination with a normal converter which really converts |
|
Please fix on 3.0 and master branch as well |
|
Done. |
|
FYI... just encountered something similar on a JSF composite component using a backing component. |
I still have a problem with JSF 2.3 related to ViewParam, I tested it with WildFly 21 (released october 2020) and the bug is still there. The code is in the following repositories: Jetty example: https://github.com/erickdeoliveiraleal/primefaces-test/tree/viewparam Wildfly example https://gitlab.com/erickdeoliveiraleal/simpleproject
Note that Wildfly already incorporated all the fixes recently done recently in Mojarra 2.3 repository.
When you click on button the second time a exception happens, this is not the case when using mojarra 2.2, myfaces 2.2 or myfaces 2.3
XHTML:
Bean
Entity Class
Converter
You also need to set INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL as true
the exception
The text was updated successfully, but these errors were encountered: