The tomcat maintainers want to update tomcat to 10.x as part of Fedora 42, this is an accepted Change: https://fedoraproject.org/wiki/Changes/Tomcat10ChangeProposal . They have submitted an update for Rawhide, however it fails gating because FreeIPA does not work. The error messages start with: Jan 10 09:34:08 ipa002.test.openqa.fedoraproject.org server[4272]: arguments used: start Jan 10 09:34:08 ipa002.test.openqa.fedoraproject.org server[4272]: WARNING: A command line option has enabled the Security Manager Jan 10 09:34:08 ipa002.test.openqa.fedoraproject.org server[4272]: WARNING: The Security Manager is deprecated and will be removed in a future release Jan 10 09:34:10 ipa002.test.openqa.fedoraproject.org server[4272]: WARNING: Tomcat interprets the [protocols] attribute in a manner consistent with the latest OpenSSL development branch. Some of the specified [protocols] are not supported by the configured SSL engine for this connector (which may use JSSE or an older OpenSSL version) and have been skipped: [[TLSv1, TLSv1.1]] Jan 10 09:34:10 ipa002.test.openqa.fedoraproject.org server[4272]: WARNING: Failed to scan [file:/usr/share/java/tomcat-jakartaee-migration/bcel-6.8.1.jar] from classloader hierarchy Jan 10 09:34:10 ipa002.test.openqa.fedoraproject.org server[4272]: java.nio.file.NoSuchFileException: /usr/share/java/tomcat-jakartaee-migration/bcel-6.8.1.jar There was a previous attempt to update to tomcat 10 in Fedora 40, which failed similarly, and some investigation was done - see https://bodhi.fedoraproject.org/updates/FEDORA-2024-32638409af . The last things there were two messages from csutherl: "I'll reach out to the FreeIPA folks and get this sorted." and then "This issue is because of javaee -> jakartaee migration that isn't done in the app." The update was then abandoned. I can't really tell from that whether this was ever communicated to FreeIPA team, or whether it's FreeIPA team or Tomcat team that is responsible for doing the "javaee -> jakartaee migration" in "the app" (or what "app" is "the app"). But anyway, this needs to be sorted in order for the Change to land for F42. I do note that the word "FreeIPA" does not appear in the Change doc anywhere, which is unfortunate since FreeIPA is probably the main user of tomcat in Fedora. In future I'd suggest major updates to Tomcat should plan to co-ordinate with FreeIPA from the start. The Change doc does say "feature owners need to perform the following tasks: ... Ensure that all necessary patches and custom modifications are applied to maintain compatibility and functionality within the Fedora ecosystem", so that puts at least some of the responsibilty on the Change owners.
note, we also need to make sure FreeIPA *upgrades* from F41 (hence tomcat 9) work. This is also a release-blocking requirement and the openQA tests test it, so updates will fail tests unless it works.
Yes, this is something totally should be done on dogtag-pki side. I started a PR half a year ago but it needs to be taken over by the Dogtag folks: https://github.com/dogtagpki/pki/pull/4796. My understanding is that they plan to work on it soon.
As the Tomcat maintainers and change owners for the Tomcat 10 update, we have taken the necessary steps outlined in the Change Proposal to ensure compatibility and functionality. However, as already noted, this update inherently affects applications relying on the deprecated Java EE namespace, requiring migration to the Jakarta EE namespace. This includes FreeIPA, as identified. We want to note that we’ve been in communication with the PKI team to address these migration challenges collaboratively. While we’ve made efforts to ensure Tomcat’s compatibility, certain application-specific updates fall outside the scope of the Tomcat maintainers' responsibilities. PKI team is currently completing the necessary migration to maintain compatibility with Tomcat 10. With the adoption of Tomcat 10 in RHEL 10, it is crucial to resolve these compatibility issues. As part of this effort, we are making a final coordinated push to address concerns and complete the migration tasks.
Progress to date on this issue: - Created local builds of pki and jss, against the latest api. - Installed ca - The legacy UI of the CA works fine, but discovered that rest easy calls don't work. This is important because these calls are uses all over the place and are needed to install additional subsystems such as kra. - Modified our current older version of resteasy to compile against the latest tomcat-servlet-api. The rest calls are still not working. - Now working on either attempting to get the older resteasy working or upgrade to the earliest version that is compiled against the tomat 10 based api. The main change being the imports of jakarta.servlet instead of the older javax.servlet. -Will update any progress this is top priority.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.