Conversation
|
Apparently Payara 7.x has a minor bug - any API call with a colon in it fails. payara/Payara#7777 - looks like we need to wait for 7.2025.3 or 7.2026.1 + |
There's been an unofficial report that this is fixed in 7.2026.1 - can now move forward and try that. |
cmbz
added
FY26 Sprint 15
@qqmyers Hit this when building the warfile, could you please refresh your branch when you get a chance? Thanks! |
|
Tests passed: |
| # JDK 17 builds disabled due to non-essential fails marking CI jobs as completely failed within | ||
| # Github Projects, PR lists etc. This was consensus on Slack #dv-tech. See issue #8094 | ||
| # (This is a limitation of how Github is currently handling these things.) | ||
| # | ||
| #include: | ||
| # - jdk: '17' | ||
| # experimental: true | ||
| # status: "Experimental" |
There was a problem hiding this comment.
@poikilotherm do you think we should make any changes here?
Related (as the comment says):
|
Passed with payara7 2026.2: |
|
Pass after develop merge: |
|
|
||
| `sudo -u dataverse vi /usr/local/payara6/glassfish/domains/domain1/config/jhove.conf` | ||
|
|
||
| 1. Copy logos from Payara 6 to Payara 7. |
There was a problem hiding this comment.
In addition to logos, we now have docroot/featuredItems/ as well. (I don't think this is an HDV-specific thing, is it?)
Sitemap usually lives in docroot, on most instances. Should probably transfer that as well, to be used until the new one is generated.
Should we just tell them to move the entire docroot?
sudo -u dataverse mv /usr/local/payara7/glassfish/domains/domain1/docroot /usr/local/payara7/glassfish/domains/domain1/docroot.orig
sudo -u dataverse mv /usr/local/payara6/glassfish/domains/domain1/docroot /usr/local/payara7/glassfish/domains/domain1/docroot
There was a problem hiding this comment.
(unless are aware of anything uniquely useful in the docroot shipped with Payara 7)
There was a problem hiding this comment.
Featured items are only visible from the SPA, which I think only we are running, so I think I'd prefer to leave it out.
For the sitemap, the cron job they set up at https://guides.dataverse.org/en/6.9/installation/config.html#creating-a-sitemap-and-submitting-it-to-search-engines should continue to work but I'll add a note. Update: added in 05c503e.
Of course, if you think we should transfer the entire docroot, we can. No strong option.
There was a problem hiding this comment.
I was wondering if it was SPA-specific (didn't see any references to it in our code), but wasn't sure.
As for the sitemap, I did say to be used until the new one is generated - i.e., yes, the next time the crontab run it'll fix itself.
Saw the commit where you mentioned the crontab - 👍; it may be worth adding a generic warning that they need to make sure any scripts outside of Dataverse proper, such as crontabs, that have the domain directory hard-coded may need to be updated (or they can create a symlink from payara6 domain to the new one, to be safe).
Unless you already have it spelled out - ?
|
|
||
| 1. Copy `jhove.conf` and `jhoveConfig.xsd` from Payara 6, edit and change `payara6` to `payara7`. | ||
|
|
||
| `sudo bash -c 'cp /usr/local/payara6/glassfish/domains/domain1/config/jhove* /usr/local/payara7/glassfish/domains/domain1/config'` |
There was a problem hiding this comment.
We should probably stick to suggesting sudo -u dataverse consistently.
Also, (just curious) why not just
sudo -u dataverse cp /usr/local/payara6/glassfish/domains/domain1/config/jhove* /usr/local/payara7/glassfish/domains/domain1/config?
... is something crazy going to happen if the current user can't read domain1/config, and the sudo account uses tcsh?
There was a problem hiding this comment.
Yeah, the craziness is due to the wildcard, the jhove*. This is what I got to work.
There was a problem hiding this comment.
FWIW, I would just go with 2 simple cp lines, 1 for each file. But, whatever works/don't fix what ain't broke, etc.
But Iet's add -u dataverse to that sudo.
| </servlet-mapping> | ||
| ``` | ||
|
|
||
| 1. Check the `Xmx` setting in `domain.xml`. |
There was a problem hiding this comment.
Small thing, but maybe all the domain.xml-related sections should be in one place. (i.e., move this up/swap it with the default-web.xml section above; plus the other sections below that deal with the config in domain.xml)
Co-authored-by: landreev <leonid@hmdc.harvard.edu>
Co-authored-by: landreev <leonid@hmdc.harvard.edu>
Co-authored-by: landreev <leonid@hmdc.harvard.edu>
Co-authored-by: landreev <leonid@hmdc.harvard.edu>
|
|
||
| Under `/usr/local/payara7/glassfish/domains/domain1/config/domain.xml`, check the `Xmx` setting under `<config name="server-config">`, where you put the Dataverse-related JVM options, not the one under `<config name="default-config">`. This sets the JVM heap size; a good rule of thumb is half of your system's total RAM. You may specify the value in MB (`8192m`) or GB (`8g`). | ||
|
|
||
| 1. **Please make sure** to check for any other custom configuration you may have in your current `domain.xml` that are not explicitly covered in the sections above. As an example, for Harvard Dataverse we have the thread pool size configured as follows for the main http listener: |
There was a problem hiding this comment.
| 1. **Please make sure** to check for any other custom configuration you may have in your current `domain.xml` that are not explicitly covered in the sections above. As an example, for Harvard Dataverse we have the thread pool size configured as follows for the main http listener: | |
| 1. **Please make sure** to check for any other custom configuration settings you may have in your current `domain.xml` that are not explicitly covered in the sections above. As an example, for Harvard Dataverse we have the thread pool size configured as follows for the main http listener: |
I must have missed the word in my suggested change
7 participants
What this PR does / why we need it: This PR updates Dataverse to be compatible with Payara
7.2025.27.2026.2 and Java 21. Aside from the doc changes (payara6 -> payara7 etc.) the changes were relatively minor - a couple deprecated annotations we use (NotEmpty, NotBlank) were removed and replaced with new ones, and some of the EE related classes we mock in tests now have a few more methods that have to be overridden.Which issue(s) this PR closes:
Special notes for your reviewer: Someone will need to check the Docker related compose files and documentation to make the relevant updates to Payara and Java. I tried to avoid updating things related to the Keycloak container since it shouldn't need to update to Java 21.
Suggestions on how to test this:
Does this PR introduce a user interface change? If mockups are available, please link/include them here: No
Is there a release notes update needed for this change?: included.
Additional documentation: A good starting point: https://dataverse-guide--12043.org.readthedocs.build/en/12043/installation/prerequisites.html#payara