Replace deprecated glassfish files with payara-* files in WEB-INF

[qqmyers]

What this PR does / why we need it: Per (Payara)[https://docs.payara.fish/community/docs/Technical%20Documentation/Payara%20Server%20Documentation/Application%20Deployment/Deployment%20Descriptor%20Files.html], the glassfish-web.xml and glassfish-resources,xml file formats we use are deprecated "and support will be removed in a future release". This PR updates to the newer payara* formats - basically a matter of updating the DOCTYPE lines and changing names.

Which issue(s) this PR closes:

• Closes #

Special notes for your reviewer:

Suggestions on how to test this: Make sure Dataverse deploy and runs after the update.

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:

[rtreacy]

review via Claude -

Code Review: PR #12240 — Replace deprecated glassfish files with payara-* files in WEB-INF

Author: qqmyers (QDR)
Target: develop
State: Open
Milestone: 6.12

---

Overview

Renames glassfish-web.xml → payara-web.xml and glassfish-resources.xml → payara-resources.xml, updating DOCTYPE declarations to reference Payara DTDs. This addresses Payara's deprecation of the
glassfish-* filename variants.

---

Issues

1. Wrong DTD versions for Payara 7 — High Priority

The project uses Payara 7.2026.2, but the PR references Payara 6 DTDs:

• payara-web.xml uses: "-//Payara.fish//DTD Payara Server 6.36.0//EN" pointing to main-6/.../payara-web-app_4.dtd
• payara-resources.xml uses: DTD from main-6 branch

The correct references for Payara 7 should be:

Using main-6 DTDs will work today (Payara is backward-compatible), but it's misleading and may miss features/validation specific to Payara 7.

2. javax.enterprise.concurrent should be jakarta.enterprise.concurrent — Medium Priority

The glassfish-resources.xml (now payara-resources.xml) still declares:
<custom-resource res-type="javax.enterprise.concurrent.ManagedExecutorService" ...>

But the Java source code already uses jakarta.enterprise.concurrent.ManagedExecutorService (as confirmed in S3AccessIO.java, MakeDataCountApi.java, etc.). Payara 7 is Jakarta EE 11 — the javax
namespace is legacy. This resource definition may still work due to Payara's compatibility layer, but it should be updated to jakarta.enterprise.concurrent.ManagedExecutorService for
consistency.

3. org.glassfish.resources.custom.factory.ManagedExecutorServiceFactory — Low Priority

The factory class reference is still org.glassfish.resources.custom.factory.ManagedExecutorServiceFactory. This is a Payara-internal class that happens to still exist under the org.glassfish
package (Payara inherits GlassFish packages). It works, but it's worth verifying this class name hasn't been relocated in Payara 7.

4. Documentation references not updated — Low Priority

Two files reference glassfish-web.xml by name in comments:

• src/main/docker/Dockerfile (line 33): "defaults for glassfish-web.xml and other places"
• src/main/resources/META-INF/microprofile-config.properties (lines 13, 15): references to glassfish-web.xml

These should be updated to payara-web.xml for consistency.

---

Correctness

The rename itself is straightforward and well-supported by Payara documentation. The root element change ( → ) and corresponding closing tag is required and
correctly done. The root element in the resources file doesn't change (it was never ).

---

Risk Assessment

Low risk overall. Payara explicitly documents these as supported replacements. The main risk would be if some Payara deployment tooling hardcodes the glassfish-* filenames, but the Payara
documentation confirms both are scanned during deployment (with payara-* taking precedence if both exist).

---

Testing

The PR's testing guidance ("verify Dataverse deploys and runs") is appropriate. Specifically:

• Confirm the application deploys without descriptor-not-found warnings
• Verify the S3 upload executor and Citation Update executor are available at their JNDI names
• Check that alternate docroots and upload directory settings still work

---

Suggestions

1. Update DTDs to Payara 7 versions (use main-7 branch URLs and payara-web-app_6_1-0.dtd)
2. Update javax → jakarta in the resource type declarations
3. Update comment references in Dockerfile and microprofile-config.properties
4. Consider whether to also update the factory class to a Payara-branded equivalent (if one exists)

---

Verdict

Request changes. The rename is correct in principle but should target Payara 7 DTDs (matching the actual server version) rather than Payara 6 DTDs. The javax → jakarta namespace in resource
declarations should also be addressed while touching this file.