| Re: [starter-dev] Return of the Dreaded View Expiration! |
OK, great. Let me test it and get it deployed. I'll monitor for any more issues and also try to ensure sticky sessions for good measure. Thanks!
On Fri, Mar 14, 2025 at 11:49 AM Reza Rahman <reza_rahman@xxxxxxxx> wrote:
Do you mind kindly making a PR with the approach you think is best overall? I'll test it out and monitor that it works. I appreciate it!
On 3/14/2025 11:45 AM, Bauke Scholtz wrote:
Yeah. The issue boils down to that the view scoped bean referenced in the p:selectOneRadio is created for the first time when the response is already committed. And view scoped beans need to be saved in the session. But when the response is already committed the cookie associated with the session cannot be set.
Another solution is to add a f:viewAction referencing some bean init method and use that instead of postconstruct. This is guaranteed invoked before render response.
Yet another solution is to create a servlet filter which does an explicit request.getSession() call.
You got it.
Cheers, B
On Fri, Mar 14, 2025 at 11:38 AM Reza Rahman <reza_rahman@xxxxxxxx> wrote:
To some extent, the symptoms at least appear simple. We are now getting copious amounts of views expired (example stack trace attached). I had seen this in prior releases with JBoss EAP 7.4 (and the corresponding WildFly version). What I did is to set STATE_SAVING_METHOD=client. It worked well and saw no more views expiring in the logs.
Then we upgraded to JBoss EAP 8 and the corresponding WildFly versions. Now with STATE_SAVING_METHOD=client, I get this strange session state saving issue (example stack trace also attached). So we are stuck with views expiring again.
Let me know if I can share anything else. Let me see if there is anything I can do to ensure sticky sessions. Because this is deployed to an Azure PaaS, I have a very limited amount of control.
On 3/14/2025 10:58 AM, Bauke Scholtz wrote:
Hi,I had to remove STATE_SAVING_METHOD=client because I could not get it to workWould be helpful if you elaborate this in detail. It might be a clue. One of pre-requirements for that in a cluster environment is that the jsf/ClientSideSecretKey env param is set (usually in web.xml). This has been renamed to faces/ClientSideSecretKey. So if the cluster doesn't use sticky sessions then ViewExpiredException will occur.
Cheers, B
On Fri, Mar 14, 2025 at 10:48 AM Kito D. Mann <kito.mann@xxxxxxxxxxx> wrote:
Hey Reza,Can you provide some more details (perhaps point me to logs or explain any scenarios)?We're still partners with PrimeTek and I still work with Bauke Scholtz (cc'd), so we can figure it out.
___
Kito D. Mann | @kito99@mastodon.social | LinkedIn
Java Champion | Google Developer Expert Alumni
Expert consulting and training: Cloud architecture and modernization, Java/Jakarta EE, Web Components, Angular, Mobile Web
Virtua, Inc. | virtua.tech
+1 203-998-0403
* Enterprise development, front and back. Listen to Stackd Podcast.
* Speak at conferences? Check out SpeakerTrax.On Mar 14, 2025 at 10:11 AM -0400, Reza Rahman <reza_rahman@xxxxxxxx>, wrote:
Hi Kito/others,
I have been monitoring the release for stability and unfortunately we
have a problem that needs to be solved. I had to remove
STATE_SAVING_METHOD=client because I could not get it to work with the
latest PrimeFaces/Jakarta EE 10/JBoss EAP 8. Now we have the infamous
JSF problem of views expiring left and right again of course. I will
keep trying this weekend, but can you possibly help me look at this and
solve it? You still have some contacts with the PrimeFaces folks, right?
Could they help? This appears to be mainly a PrimeFaces problem.
Thanks,
Reza