-
Notifications
You must be signed in to change notification settings - Fork 501
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade to Payara 6 2025.2 #11128
Upgrade to Payara 6 2025.2 #11128
Conversation
261bba6
to
bf5728e
Compare
@poikilotherm - any thoughts on the MailSessionProducerIT test failure? I don't see how the code changes could affect this but perhaps something has changed in Payara/its config? (I looked at another PR where this passes and I think the hostname is |
FWIW: The current test failures in Jenkins are from this PR running against Payara 6.2023.8 - not sure if that is also an issue for the Maven Tests. |
@qqmyers I can set up a separate Jenkins job to test this pretty easily. I'll try to do that today. |
integration tests succeeded: |
bump to Payara-6.2025.1
…tativeDataRepository/dataverse.git into IQSS/11126-Payara6.2024.12
doc/release-notes/6.2025.1_update.md
Outdated
ii. Retrieve the domain.xml file for this version of Dataverse | ||
|
||
```shell | ||
cd /usr/local |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this option is kept, the cd should be to /usr/local/glassfish/domains/domain1/config
and curl should have the -L -O
options
I'm not sure why this is necessary. 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed in standup, there are known failing API tests right now:
@donsizemore offered to set up a special Ansible/Jenkins job to test this branch. It would probably prudent to take him up on that. There was a successful run back in January but the four runs after that failed.
Testing is definitely needed on dataverse-internal or similar to go through the upgrade scenario described in the release note snippet. I didn't test this at all.
I did build a Docker base image locally and it worked fine.
Note that xhtml files are changing. I assume or at least hope all the ones that need to be changed have been changed. The only testing I did was to create a collection but much more thorough testing would be good, I'd say.
Approved.
…tativeDataRepository/dataverse.git into IQSS/11126-Payara6.2024.12
Maven Tests/Integration Tests is failing on this PR - please advise. |
Were you looking at https://jenkins.dataverse.org/job/IQSS-Dataverse-Payara6/77/testReport/ ? |
https://github.com/IQSS/dataverse/actions/runs/13683007512/job/38326347458?pr=11128 |
branch conflicts need to be resolved - thanks! |
The error is a strange one: https://github.com/IQSS/dataverse/actions/runs/13683007512/job/38326347458?pr=11128#step:6:1209 Did we every figure out why it's trying to send e-mail? |
IQSS/11126-Payara6.2024.12
Co-authored-by: Omer Fahim <[email protected]>
Co-authored-by: Philip Durbin <[email protected]>
Co-authored-by: Omer Fahim <[email protected]>
@ofahimIQSS asked when we upgraded to 6.2024.6. It was in this PR: |
Followed all the upgrade instructions and was able to successfully upgrade Dataverse Internal. Performed quick regression test and things looked good. Merging PR |
What this PR does / why we need it: Updates to Payara 6.2025.2, fixing a few places where JSF now appears to send a null rather than an empty string, causing some new NPEs.
Which issue(s) this PR closes:
Special notes for your reviewer: FWIW: It looks like just copying the domain across to the new version works so we may only want to show 'Option 1' form the release notes. I originally did 'Option2' - just copying the parts of domain.xml and other files to the new domain which has some advantages (easier to diff against the latest payara domain.xml, gets new cacerts file, makes it possible to track payara domain.xml changes in github (against /conf/payara/domain.xml), etc.) but it's definitely more work/more confusing.
With further testing at QDR, I've noticed a steady/overwhelming stream of errors of the form
JSF1103: The metadata facet must be a direct child of the view in viewId /dataverse.xhtml]]
. I did not notice any change in UI behavior though. Digging in a bit, it appears that any page that uses<ui:composition template="/dataverse_template.xhtml">
was including the f:metadata farther down in the tree. I've made changes to move them to being a direct child of the view which appears to get rid of the log messages, again w/o any impact on functionality that I've seen. I haven't been able to confirm, but my guess is that while the error is now getting flagged, the f:metadata was still be interpreted correctly.Suggestions on how to test this: Check new installs, docker, upgrade instructions - basically regression testing and testing instructions, there shouldn't be any functional changes. Could confirm that the current v6.5 war does not work with Payara 6.2025.2, but I think that's well enough known.
Testing should also involve grepping for
JSF1103
in the logs to assure that there are no more instances (e.g. .xhtml files I missed.)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?: included
Additional documentation: references to 6.2024.6 changed to 6.2025.2 in docs
https://dataverse-guide--11128.org.readthedocs.build/en/11128/developers/tips.html#jsf1103-errors