IQSS/12715 payara 7.2026.9 update

[qqmyers]

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 8531 refactor validators #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 Upgrade to Payara 7.2026.9 #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:

[qqmyers]

FWIW: AI says: Analysis of Validator Triggering in JSF 4.0 / Payara 7
The issue where validators in the contactFormFragment are triggered during unrelated actions (like saving a template) is caused by a
combination of two factors in the JSF/PrimeFaces environment:

1. Global Inclusion and DOM Presence: Since contactFormFragment.xhtml is included in the dataverse_template.xhtml, the p:dialog and
   all its inputs are part of the JSF component tree for almost every page in the application. By default, p:dialog renders its content
   into the DOM (hidden via CSS), meaning the inputs are active and visible to the JSF lifecycle.
2. Broad Execution Scope (process="@ALL"): Many PrimeFaces components (like p:commandButton) default to process="@ALL" if no process
   attribute is specified. This instructs JSF to run the "Execute" phases (Apply Request Values, Process Validations, Update Model) for
   the entire component tree, not just the form being submitted.

In Jakarta EE 11 (JSF 4.0), Mojarra has become stricter about processing the tree, and if jakarta.faces.VALIDATE_EMPTY_FIELDS is
enabled (or due to other lifecycle changes), it will trigger validators for any input it finds in the "execute" scope, even if those
inputs are empty and hidden.

Best Practices to Avoid Unnecessary Validation
To prevent hidden or unrelated dialogs from interfering with page actions, the following best practices are recommended:

1. Lazy Loading with dynamic="true" (Recommended)
   Add dynamic="true" to your p:dialog components, especially those included in global templates.

ΓÇó How it works: When dynamic="true", PrimeFaces does not render the dialog's content into the component tree until the dialog is
actually shown.
ΓÇó Benefit: The inputs and their validators simply do not exist in the JSF lifecycle during postbacks of other forms, completely
eliminating the possibility of them being triggered unnecessarily.
ΓÇó Implementation: I have updated contactFormFragment.xhtml to use this setting:
<p:dialog id="contactDialog" ... dynamic="true">

2. Narrowing the Execution Scope (process)
   Avoid using the default @ALL scope for buttons. Instead, explicitly define what should be processed.

ΓÇó Best Practice: Use process="@Form" for most save/submit actions. This ensures that only the inputs within the current form are
validated and updated.
ΓÇó Example:
<p:commandButton value="Save" action="#{bean.save}" process="@Form" update="@Form" />

3. Conditional Validation Logic
   Continue using the pattern of conditional required attributes and null-safe validators as a safeguard.

ΓÇó Safe Validators: Validators should check if the component is actually required in the current context (e.g., via ((UIInput)
component).isRequired()) before throwing exceptions for null values. This allows the validator to "stand down" when the field is empty
but not mandatory for the current request.