What this PR does / why we need it: This PR includes the basic update to Payara 7.2026.9 as well as fixes required due to changes in Payara and/or the libraries it uses. Issues identified/fixed so far include:

• The @Context annotation we used in the ApiBlockingFilter has been ~deprecated/removed. There are several potential fixes being explored in various PRs. This PR switches to using the JAX-RS DynamicFeature mechanism to avoid having to dynamically inject the ResourceInfo instance on every call and instead registers filters for api calls at app startup. The overall logic related to blocking doesn't change, but scanning for @Path annotations only happens at startup now.


• Changes to Mojarra appear to cause the ContactFormFragment validation to run when the form is not actually shown on a page. This PR changes to dynamically loading so the contact dialog should not be in the source at all unless/until it is shown. Related changes to other dialogs and buttons to not load when not used and to constrain processing to the form or @this rather than everything, as suggested by AI, have also been made and lightly tested.

The PR also fixes some minor issues discovered when testing:

• When signing up, having a null value for the required email field was not flagged as a validation error and instead triggered a silent bean constraint error only seen in the log (leaving the dialog open when you click save). This could be due to #8534 or may have existed before that refactoring - not a new issue regardless.


• Cancelling edits on the Account Info page did not clear validation errors in the messagePanel (if they occurred).

FWIW: I noticed a similar issue in the group creation page/dialog - a validation error, e.g. for null group name, pops up a warning in the messagePanel (grayed out behind the dialog in this case) and cancel doesn't clear it. As it seems odd to put a warning in the grayed-out background to begin with, I didn't just add code to update the messagePanel on cancel (also more work than with the account page since the cancel is not a p:commandButton here).

Which issue(s) this PR closes:

• Closes #12715

Special notes for your reviewer: FWIW: Azul mentions the DynamicFeature approach in a blog post (although the post is primarily about simpler, but less flexible approaches). It sounds like this is more of a pure JAX-RS approach that relying on @Inject, and it should be slightly more efficient that we had (since api endpoint paths are all calculated once at startup instead of happening repeatedly during the filtering (for whatever api call is made). I think a key benefit of this fix is that it retains the idea of getting the path from JAX-RS itself, rather than our code trying to infer what the path is from the URL as was the case < v6.7).

Suggestions on how to test this: As this changes the API Blocking filter, testing that the admin API etc. are still blocked by the settings is important (and not just by the proxy), though I don't think there will be any issues. The main change was to when the api paths are calculated (not how, which we had to update for 6.7, and the code to implement the policy moved to a new class but isn't really different). I haven't seen any issues in my testing.

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

Is there a release notes update needed for this change?:

Additional documentation: