1.6.0-Jakarta

It's been many years, since I've been able to contribute to Stripes, but after looking at some recent PRs by community members and seeing several asks (including my own asks), I have taken on the upgrade of the Stripes stable 1.6.0 branch to Jakarta. I think it is production ready, but I still need to figure out how to get this pushed out to the Maven repositories, but after that, I think this is ready (as-is) for people to try out in their own test environments.

Just a few highlights of goodness in this branch:

• Completely built using Java 11 for maximum backwards compatibility.
• Completed removed the dependency on javax/jakarta.mail
• All unit tests pass (except for one small one that I had to remove due to reflection behavior changes in JDK 1.8+.
• TestNG has been completely removed and replaced with JUnit4. All tests have been converted.
• The Bugzooky examples application works now after making several legacy (pre-1.5) fixes.
• The Canoo webtests actually fully pass now (configured with Tomcat 10). Tomcat 11.x cannot be used because it requires Java 17.
• This uses Servlet 6.0 and the latest Jakarta JSTL/Servlet APIs.
• Spring has been updated to the latest 5.3.29. Spring 6.x cannot be used for now because it requires Java 17. That might be another future parallel branch.
• Commons-fileupload has been moved to commons-fileupload2.
• All other library dependencies have been updated to their latest possible versions.

Now, for some potentially breaking changes things that I took the liberty to do for security considerations:

1. The Log4JLogger has been completely removed. After the [log4shell](https://en.wikipedia.org/wiki/Log4Shell#:~:text=Log4Shell%20(CVE%2D2021%2D44228,framework%2C%20involving%20arbitrary%20code%20execution.) exploit, I decided to remove it and let Stripes consumers implement their own Log4j logger at their own risk. The default logger is now the SimpleJdk14Logger.
2. The O'Reilly COS library and CosMultipartWrapper has been completely removed as a dependency (and from the code). It is replaced with the Apache commons-fileupload2 implementation. In the future, I may contribute a pure-Java Servlet 3.1 multipart wrapper which I have implemented and I know works.

Why The 1.6.0 Branch And Not Master?

I know this question will be in people's minds. And the answer is because, right now, I do not have a good level of comfort for what is in the master branch. I am not saying that what is there is not good, but I need to take a complete inventory of all of those commits. While there are some good things/fixes in master, I also know that there are things in there which don't make sense (some that I even wrote/contributed) which people have commented on, some poorly chosen dependencies, among other things. I will probably go commit-by-commit in a new branch, pulling in fixes, and potentially some enhancements. But I'll probably have to do that in a new branch. The new 1.7.0 (or maybe even 2.0) branch.

How Can You Help?

Please feel free to pull/build the 1.6.0-Jakarta branch. Build and test it in your own environments. I have personally tested it on Payara 6 and Tomcat 10 (not to mention that the Canoo webtests also pass on Tomcat 10.x). If you see any issues, please report them and I will try to get them fixed. One area that I would like people to try out is the SpringHelper/Injection. The tests pass for it, but I personally did not test this on a running/working application.

Where Will It Go From Here?

Next on my list will be to probably create a new Stripes 2.0 branch which will feature a build on Java17 (GraalVM). Along with that will be an upgrade to Spring 6.x and webtests targeting Tomcat 11.x. After that, I will look at pulling stable well-tested/sensible fixes/enhancements from master into the Stripes 2.0 branch. But I am 100% sure that some of what is in the master branch will be removed because it is too old, irrelevant, or unstable.

Please Comment!

If you read this and are still around, please make yourself known. If you are doing testing and have some success, please put some feedback here. I'm not expecting Stripes to replace Jakarta MVC in JEE10. I certainly don't expect it to replace Spring Boot. But I know it is used in many legacy applications that are still running around the world. At the very least, I hope this Jakarta release of Stripes 1.6.0 can serve you well and will give your projects/software some peace of mind and allow you to migrate onto the latest JakartaEE stack.

Best Regards,

Rick

What's Changed

• • Initial Jakarta EE 10 Conversion on Java 11. by @rgrashel in #104
• • Removed jakarta/javax mail by @rgrashel in #111

Full Changelog: 1.6.0...1.6.0-Jakarta-beta

1.6.0

List of resolved/fixed items for this release:

https://stripesframework.atlassian.net/issues/?filter=10230