[#1585] Migrate to Jakarta EE 10 (3.x)

[rgcv]

Following this checklist to help us incorporate your contribution quickly and easily:

• Make sure there is a GitHub issue filed
  for the change (usually before you start working on it). Trivial changes like typos do not
  require a GitHub issue. Your pull request should address just this issue, without pulling in other changes.
• Each commit in the pull request should have a meaningful subject line and body.
• Format the pull request title like [#XXX] - Fixes bug in SessionManager,
  where you replace #XXX with the appropriate GitHub issue. Best practice
  is to use the GitHub issue title in the pull request title and in the first line of the commit message.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• add fixes #XXX if merging the PR should close a related issue.
• Run mvn verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
• If you have a group of commits related to the same change, please squash your commits into one and force push your branch using git rebase -i.
• Committers: Make sure a milestone is set on the PR

Trivial changes like typos do not require a GitHub issue (javadoc, comments...).
In this case, just format the pull request title like [DOC] - Add javadoc in SessionManager.

If this is your first contribution, you have to read the Contribution Guidelines

If your pull request is about ~20 lines of code you don't need to sign an Individual Contributor License Agreement
if you are unsure please ask on the developers list.

To make clear that you license your contribution under the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
• In any other case, please file an Apache Individual Contributor License Agreement.

---

Hello everyone 👋

First off, I'd like to thank everyone at Apache and the many contributors that make Shiro work.

Secondly, I hope you'll excuse the intrusion (which I deeply apologize for, surely one could've read up more on issue tracking, mailing lists -- anywhere but here -- to speak with someone about this,) but I felt like exploring what complications could arise from a "big bang" update to Shiro on virtually all fronts: Jakarta EE, support modules, and the like. This PR consists of my findings.

In no way, shape, or form, am I hoping for this contribution to be assimilated. I wished, if anything, to at least start some discourse, and perhaps look into chopping this big bulk of.. "something" (I won't dare call it work) down, understand what's missing (either here or elsewhere) and go from there.

I'm aware that I've trumped contribution guidelines with this "patch," for which I once again apologize. But if you'll indulge me, here are a few details about the changeset being "proposed":

List of version changes, concerns, and known issues

Includes version bumps:

• Java: 11 -> 17
• Ehcache: 2.6 -> 3.10
• Guice: 6 -> 7
• Jetty: 9.4.56.v2024.. -> 12.0
  • org.eclipse.jetty -> org.eclipse.jetty.ee10
• Jakarta EE: 8 -> 10
  • Activation: 1.2 -> 2.1
  • Annotation: 1.3 -> 2.1
  • Enterprise CDI API: 2.0 -> 4.0
  • JSON API: 1.1 -> 2.1
  • JSON Bind: 1.0 -> 3.0
  • Servlet: 4.0 -> 6.0
  • Servlet JSP API: 2.2 -> 3.1
  • Validation API: 2.0 -> 3.0
  • WS RS API: 2.1 -> 3.1
  • XML Bind: 2.3 -> 4.0
• Omnifaces: 4.6.1
• CXF RT Client: 3.6 -> 4.0
• Glassfish JAXB RT: 2.3 -> 4.0
• Spring: 5.3 -> 6.2
• Spring Boot: 2.7 -> 3.4
• Hibernate: 5.6 -> 6.6 (sample project)

Concerns:

• Ehcache migration most certainly needs revision
  • Seemingly missing cache memory computation interfaces
  • Cache generation requires key/value typification, not sure if Serializable is the best alternative. Ehcache provides a Serializer interface one could implement
  • Missing cache name method in Cache instances
• CI untested (specially Jenkins CD)
  • Perhaps JDK 11 should be dropped, not sure if there's a decent way of managing differing versions of the JDK and shiro in the pipeline
  • GitHub actions pipeline needs revision
• flowlogix, omnifaces, and a few other libs I have no knowledge of, certainly need attention
• Spring remoting seems to have been dropped from Spring Context, not sure if replaceable

Known issues:

• No immediate suitable replacement for org.eclipse.jetty:apache-jstl
• Ehcache 3.10 is pulling earlier version of jaxb runtime -> conflicting
  • Added exclusion to circumvent woes (valid?)
• Some web integration tests aren't up to speed
  • Embedded jetty-based ITs fail, server reports 503
  • Arquillian IT fails
  • Meecrowave support missing (solved in unreleased 2.0.0?)

The bulk of the transformation was aided by an OpenRewrite recipe designed for Spring Boot. The choice for employing such a recipe is it is terribly comprehensive, and already includes migrations for things such as Java EE -> Jakarta EE, Java 11 -> 17, and, of course, spring-related dependencies.

Certainly there are ways to slice up the work required into pieces, or at least segment this changeset into a more amicable set of commits that makes understanding and reviewing the changes easier. I'm afraid, however, that a lot of things hang on to the Jakarta EE migration, which makes it somewhat difficult to clearly segment units of work.

One could potentially work up, module by module, bumping their respective versions and build on top of that. Perhaps that could help, unfortunately I'm only now considering that.

---

In short, with a need to upgrade Shiro into the modern (or semi-modern) world of Java came an exploratory venture that led to quite a large changeset. I thought of breaking it down further, but when I realized that, I was in far too deep. Ultimately, decided to share with the community and gather some thoughts, ideas, discuss, and hopefully learn how to then seriously contribute something befitting of a proper release.

Thanks in advance!

[lprimak]

Hi, thank you for your contribution.

This looks like the same work as in #2017
Can this be a coincidence? See commends on that PR as well. What automated tool process did you use to make these changes?

The Shiro team would like the actual recipe so we can compare the automated changes with the PR for an easier review.

Thank you

[rgcv]

Hi, thank you for your contribution.

This looks like the same work as in #2017 Can this be a coincidence? See commends on that PR as well. What automated tool process did you use to make these changes?

The timing couldn't be more perfect. I'll check that PR out as well. This is pure coincidence! What are the odds..

The Shiro team would like the actual recipe so we can compare the automated changes with the PR for an easier review.

The only recipe I used was the one I mentioned above, the one for migrating a spring boot application: https://docs.openrewrite.org/recipes/java/spring/boot3/upgradespringboot_3_3. It aggregates a series of useful recipes that facilitate some effort. Perhaps there are other recipes available for migrating other JEE-related feature sets, but this seemed like the one that did a substantial sum of the work. Whatever the OpenRewrite recipe didn't cover was manual (some JEE dependencies, schema locations, the entirety of ehcache.)

Thank you

My pleasure!