Big sweep: migrate codebase to Jakarta EE 10 and use Payara 6 now (third iteration) #9685
Conversation
1. The Jersey dependencies in use did not use the versions imported via the Payara BOM (which itself imports a Jersey BOM). 2. The coordinates for the server package changed, re-aligned.
…nly #8305 This avoids potential trouble were it's unclear from where the higher exceptions come from, javax or jakarta namespace.
Also add provided dependency of our persistence provider to POM to allow class resolution in IDEs.
Many projects have moved to Eclipse foundation, have been replaced or renamed with the move to Jakarta EE 10. With the import of the new EE 10 Payara BOM, we need to follow their changes (or provide the deps on our own).
As the SPI module used Java EE, we need to release a v2, as the move to Jakarta EE is a breaking change.
Removing some rogue usages of OcpSoft PrettyFaces internal utils for String care and replacing with either Apache Commons Lang3 or native JVM code.
…8305 Any users registered before 2021 release to oss.sonatype.org. As gdcc was installed after that, we only had s01.oss.sonatype.org. Also enabling both snapshot repos for Rewrite and SWORD2 See also https://central.sonatype.org/news/20210223_new-users-on-s01
…8305 This is due to the fact that Payara 6 Servlets are more strict in their parsing of HTTP headers.
In EditDDI I was seeing a NullPointerException on line 136 (createNewDraftVersion). Switch from `@Context HttpServletRequest` to our ordinary way of API auth fixed it. In DataversesIT I was seeing an OptimisticLockException so I added a sleep.
Involves Jakarta Faces 4.0 and Servlet 6.0
The backing bean actions were attached to normal "<a>" elements, which means they were executed on page load and not, as expected, via JavaScript onClick. Former versions of JSF were less strict, now we need to use the standard compliant "<h:commandLink>"
poikilotherm
added
Component: Containers
This comment has been minimized.
This comment has been minimized.
The Perl installer was removed in b829ca7
This comment has been minimized.
This comment has been minimized.
|
Issues found:
[X] 2. Click dataset page, file kebab, metadata, stack trace but ui ok [KC] Phil is looking into this [Update] fixed, no log error. Two proposed fixes:
[X] 3. Clicking on filename from tree view throws 500 error in ui, saw same context validation errs in log, same error just clicking on file in dataset file table. [KC] Fixed by Oliver.
[embargo_fail.txt](https://github.com/IQSS/dataverse/files/12305211/embargo_fail.txt)
Note: Embargo works from file page |
The backing bean actions were attached to normal "<a>" elements, which means they were executed on page load and not, as expected, via JavaScript onClick. Former versions of JSF were less strict, now we need to use the standard compliant "<h:commandLink>"
Should be fixed with 3716c5c. I scanned all XHTML code for other examples of some |
This comment has been minimized.
This comment has been minimized.
The widget for the dataset citation on the file page was forgotten to be converted to <h:commandLink> as well to avoid action execution on page load.
This comment has been minimized.
This comment has been minimized.
switch dev-env docs to Docker
This comment has been minimized.
This comment has been minimized.
|
Regarding item 1. above - those long "illegal State" and "validation failed" exception stack traces are very easy to reproduce: just try accessing a dataverse that does not exist in the database - http://localhost:8080/dataverse/blahblahblah |
I can verify this procedure and see error logs as well. As I wrote on internal Slack, this issue is triggered by how the rewrite filter works. From following the execution step by step via debugger, I can see that Jakarta Faces does the abort and the rewrite filter tries to forward us. The first log message is written by the filter detecting we want to abort. I see an old discussion about this in ocpsoft/rewrite#151. We should create a simpler reproducer and create an issue over there. For now, the bug does not seem to be fatal, just annoying - the 404 page still works. If I would have a say in this, I'd suggest creating a follow up issue to track this but not let it block merging this PR. I'm attaching the full output here as well: illegalstate-rewrite-404.txt (from accessing http://localhost:8080/dataverse/test) |
|
My vote for the kebab metadata issue above would be the 2nd fix: fedb103 |
As of Payara 6/JSF 4/Jakarta EE 10, this syntax doesn't work:
action="#{bean[editFileAction]()}"
(Or it logs errors in server.log at the very least.)
So we switch to this syntax:
action=#{bean.editFileMetadata()}"
This means we have to make sure the method exists on all the beans,
though, or we get errors. (It's unclear why we weren't seeing errors
before!) So we add the method to FilePage, which gets passed as bean.
We also remove the now unused "editFileAction".
|
📦 Pushed preview images as 🚢 See on GHCR. Use by referencing with full name as printed above, mind the registry name. |
|
Merging this after discussing on tech. @scolapasta Re: P6 I'm ok with merge now and resolve remaining issues as top priorities. |
THIS IS READY BUT SHOULD NOT BE MARKED NON-DRAFT UNTIL 5.14 HAS BEEN RELEASEDWhat this PR does / why we need it:
Payara 5 is going EOL for community usage (= without a payed support contract). Payara 6 is the successor, but allows to use Jakarta EE 10 only. Issue #8305 is the deliverable, where this PR is a part of.
At tech hour we agreed that we want to do a clean cut after the 5.14 release and migrate develop to Jakarta EE 10 and hack on it further. This PR prepares this step.
This PR is a successor to PR #9116
Which issue(s) this PR closes:
Special notes for your reviewer:
Note that as 5.14 is not yet released, this PR will need an update from
developonce done and will need to add some more migrations of the outstanding code parts that are due for 5.14. (These are minor, so we started the branch)Open Tasks this PR did not address (and maybe should be fed back to #8305):
Should we preserve backward compatibility of the SWORD API by insertingDONE, see Big sweep: migrate codebase to Jakarta EE 10 and use Payara 6 now (third iteration) #9685 (comment)attachment;for the user if it isn't supplied?The Perl installer has not been updated. Honestly, @pdurbin and I are ok with deleting it (and references to it, of course, if any).DONE, deleted. docker-aio and docker-dcm too.The release note snippet needs work. Upgrades have not been tested.DONE. Release note snippet added. There's a dedicated issue for upgrades: determine upgrade path from Payara 5 to 6 #9340Suggestions 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?:
Yes, a stub is included, but needs work. Maybe can be done as part of another issue for Dataverse 6 release notes.
Additional documentation:
None but references in the guides to Payara 5 have been switched to Payara 6.