| Re: [starter-dev] Archetype and UI Release |
I was able to get some time in the morning and the GlassFish Docker support is in the UI now too. In addition, thanks to a great observation from Ondro, I was able to finally begin simplifying and consolidating the UI validation logic. So we can now have a really nice release of the UI and Archetype.
Hi Jeyvison,
I've now stabilized the GlassFish Docker support in the Archetype too. So if you like, we can have both a UI and Archetype release.
I have a few family obligations tomorrow, but I will try to surface the GlassFish Docker support in UI too as soon as I am able. I suggest prioritizing getting rid of the view expirations as soon as possible though.
Thanks,
Reza
On 3/14/2025 12:36 PM, Reza Rahman wrote:
Sounds good.
Jeyvison, can we have a new release of just the UI please? I've tested the change and it appears fine. Bear in mind, I just merged a long-standing PR from Ondro into the Archetype part that isn't ready for prime time yet, so please don't do a corresponding release of the Archetype yet? Just the UI please?
I appreciate it!
On 3/14/2025 12:26 PM, Bauke Scholtz wrote:
On this specific public facing app, I suggest keeping client state saving. This will further reduce ViewExpiredException risks as well as headache risks and hence in long term better for well being on both sides.
Cheers, B
On Fri, Mar 14, 2025 at 12:23 PM Reza Rahman <reza_rahman@xxxxxxxx> wrote:
I found out that session affinity was indeed turned off and I have now turned it on.
Before deploying this change, is it worth it to observe if this simply solves the problem? Or should I switch to client state saving anyway?
WDYT?
From: Bauke Scholtz <balusc@xxxxxxxxx>
Sent: Friday, March 14, 2025 11:59 AM
To: Reza Rahman <reza_rahman@xxxxxxxx>
Cc: starter developer discussions <starter-dev@xxxxxxxxxxx>; Edward Burns <Edward.Burns@xxxxxxxxxxxxx>; Kito Mann <kito.mann@xxxxxxxxxxx>
Subject: Re: Return of the Dreaded View Expiration!try to ensure sticky sessions for good measure
Good. Check https://stackoverflow.com/a/35626681 for guidelines.
Cheers, B
On Fri, Mar 14, 2025 at 11:58 AM Reza Rahman <reza_rahman@xxxxxxxx> wrote: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 3/14/2025 11:53 AM, Bauke Scholtz wrote:
There you go https://github.com/eclipse-ee4j/starter/pull/354
Cheers, B
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 work
Would 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
_______________________________________________ starter-dev mailing list starter-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev