Jakarta EE 9+ migration

[bhagyashriSawkar]

Updated a few files with changes required for upgrade to Jakarta EE 9+. The jar is getting generated but test cases are not getting executed, will work on that.

@headius: Please let me know if there is something else that also needs to be checked. Also I did override a few required abstract method with empty/default value, would appreciate if you take a look at those.

Thanks.

[chadlwilson]

This would be a breaking change probably requiring a 1.3 or 2.0 release.

Right now 1.2.x off master is not very stable (needs #262 at the very least to get fixes that were already there on 1.1.x but never merged into master), and master still lacks validated testing with modern Rails versions for which we probably need help with to get stable.

If you know Rails and jruby-rack better than me (especially the session stuff) I could do with some help trying to get the tests working with modern Rails and JRuby versions. I'll probably create a separate draft PR for that shortly.

[chadlwilson]

The branch/PR at #262 does get the tests/specs all running/passing reliably however :-)

[kares]

👍 looks like a good start but the PR feels incomplete.

my idea about supporting jakarta/javax.servlet at the same time would have been converging towards moving all .rb bits that script the javax.servlet API into .java and than potentially use some kind of a weaving approach or the "migration" tool than Tomcat has to release 2 artifacts from the same build... 🤷

[headius]

Exciting! This will obviously need to be rebased on master due to recent updates there, but I'm glad you've attempted this work.

This would be a breaking change probably requiring a 1.3 or 2.0 release.

use some kind of a weaving approach or the "migration" tool than Tomcat has

I would tend to lean toward a hard version move as a 2.0 release myself.

The old javax.servlet users have to be dwindling pretty fast these days. If we continued to maintain a 1.x line for a while that supports javax.servlet and provided 2.x for jakarta, we'd avoid any complex build situation and everyone would still be able to keep working with what they have. We might start dropping some deprecation warnings into the 1.x line at some point.

@kares Are you opposed to this clean break, branching off 1.2.x and releasing a 2.x that uses only jakarta packages going forward?

[kares]

@kares Are you opposed to this clean break, branching off 1.2.x and releasing a 2.x that uses only jakarta packages going forward?

Not at all, just shared my personal opinions, think some folks might still be stuck with older versions here and there due "legacy" (enterprise) reasons. Thus was thinking about ways to support both wout having extra work (such as backports).

I am very happy to see any effort such as this one (a full API rewrite) to keep the jruby-rack project going.

Regarding this PR my only concern is that some methods feel like stubs and should be revisited implementation wise according to the servlet specification.

[chadlwilson]

FWIW for GoCD i'm one of those stuck on javax namespace at the moment due to needing breaking Jetty 12.x upgrades + multiple Spring FW version upgrades which in turn need major Hibernate and Spring Security upgrades - and really only having myself to do it. 😅 But accept that is probably not most people's situation and being on all this EOL stuff is bad for many other reasons.

My main concern about this if this makes it harder to get to a supported Rails version (i.e if jruby-rack code change is needed to fix Rails 7 compat and no backport is possible) as currently I believe an issue with jruby-rack is preventing me getting to Rails 7+ and 6.1 is also EOL now :(

[kares]

My main concern about this if this makes it harder to get to a supported Rails version

I believe your concern, despite having an "unusual" app, is one shared by many legacy users -> simply hard enough for them to upgrade to a recent JRuby/Rails version while on top of it having to worry about a server upgrade as well.

believe an issue with jruby-rack is preventing me getting to Rails 7+ and 6.2 is also EOL now :(

Maybe you can open a discussion about what is your specific use-case and why you can not upgrade.

[chadlwilson]

@kares about all I know is still at #244

I've subsequently seen similar looking session errors with the appraisals on Rails 6.x but yeah, separate to this issue so should discuss elsewhere.

[headius]

Another option would be a new named gem that is jakarta-rack or something, but there may be transitive dependency issues getting RubyGems/Bundler to pick that up.