1.2: Back-port JRuby 10 and Rails 8.0 compatibility

[chadlwilson]

Backports #273, #299, #314 to the 1.2.x branch by housing the JRuby-10-removed CompatVersion class (used by RackConfig API), and avoiding needing to change the jruby-rack API.

Generally 1.2.x was already working with JRuby 10 if the Config was not used in certain ways causing the CompatVersion class to be loaded; and if there were not failures during initialization that cause reflection on the RackConfig to be able to dump to logging.

This will make it easier for folks to move to JRuby 10 within Warbler without having to move to jruby-rack 1.3.

Since CompatVersion has been a no-op on JRuby itself for a very long time, removing the actual implementation does no harm. jruby.compat.version jruby-rack init properly will just be ignored, and the default values from earlier returned.

[chadlwilson]

Hiya @kares - what do you think of this? Seems to work fine to avoid issues on JRuby 10 with no change in API which seems to make things easier for folks.

If you are cool with this, would you be able to merge and help cut a release of 1.2.6? (diff)

[kares]

not sure this is a good idea, with proper modularization shouldn't even work (as the package is "owned" by a different .jar).

would personally just leave 1.2.x as is and not try to hack around to get it to work with latest JRuby...

[chadlwilson]

Yes, this did occur to me. However is jruby-rack even possible to use within a modularised environment? It has no metadata. So is this an an academic concern or still real?

I'm yet to actually see such modularisation used in the wild in real applications, so I may be naive here.

[chadlwilson]

Do you know an example of a Java web server that works in JPMS module mode? To my knowledge they all still use classpath mode (or OSGi which is a whole other can of worms jruby-rack doesn't support)

[kares]

I honestly do not know, just smells like a bad idea.
There has been embedded use-cases with different class-path layouts than a typical .war.

Understand where this is coming from given the enum is self contained.
We'll still have the org.jruby.CompatVersion (with <10) class around twice and can not guarantee which one will get loaded, shouldn't matter. 🤷

If you get someone else e.g. @headius to bless this approach. 🙏

Personally would rather not go down this path, esp. given 1.3.0 without hacks is good to go but if there's smarter folks saying will do just fine... then 👍

[chadlwilson]

Yeah, almost certainly a bad idea in the general case.

My thinking was just to make life easier for folks to upgrade and avoid issues like jruby/warbler#573 where someone uses JRuby 10 with Warbler and it sometimes works enough to confuse folks, except when there is a start-up error and that error is swallowed by this CompatVersion problem. Warbler doesn't define a maximum jruby version, but does define a < 1.3 jruby-rack version so there is a bit more friction there.

I was thinking that might allow us to keep the delta for 1.3 even smaller for folks - but I hear you..

Alternatively to this what we could possibly do on 1.2.x is disable the jruby-rack config capture (on init failure) for JRuby 10. The actual failure/issue right now only seems to come from the instance_methods call (JRuby MethodGatherer invocation) here:

jruby-rack/src/main/ruby/jruby/rack/capture.rb

Lines 85 to 99 in 2bdcb42

	module JRubyRackConfig
	def capture
	super
	servlet_context = JRuby::Rack.context
	methods = servlet_context.config.class.instance_methods(false) +
	org.jruby.rack.DefaultRackConfig.instance_methods(false)
	methods = methods.uniq.reject do |m|
	m =~ /^(get|is|set)/ || m =~ /[A-Z]|create|quiet|([!?=]$)/
	end
	output.puts("\n--- JRuby-Rack Config",
	*(methods.sort.map do |m|
	"#{m} = #{servlet_context.config.send(m)}" rescue "#{m} = <error: #{$?}>"
	end))
	end
	end

So if we removed that, and if the user does not retrieve the CompatVersion in custom config, I don't think jruby/jruby-rack will cause the CompatVersion class to be loaded, despite the imports below because the getCompatVersion() method is never invoked.

jruby-rack/src/main/java/org/jruby/rack/RackConfig.java

Line 13 in 212ba5f

import org.jruby.CompatVersion;

Would that be better to you - to just lose the rack config dump capability on JRuby 10 for 1.2.x? (unless you can think of an even smarter way to stop the .instance_methods(false) call from inspecting everything. :-)

[chadlwilson]

I am reasonably confident that JRuby 10 works fine without the config dump being needed because the Warbler integration tests validate startup and a basic call to a Rails API work fine and are passing in master.

[kares]

My thinking was just to make life easier for folks to upgrade and avoid issues like jruby/warbler#573 where someone uses JRuby 10 with Warbler and it sometimes works enough to confuse folks, except when there is a start-up error and that error is swallowed by this CompatVersion problem. Warbler doesn't define a maximum jruby version, but does define a < 1.3 jruby-rack version so there is a bit more friction there.

That still sounds like a work-around for smt that could be fixed pushing patch jruby-rack/warbler versions.
On the jruby-rack (1.2.x) gem side by requiring to have the required_ruby_version < 3.2 then at runtime Bundler/RubyGems should validate.
potentially same could be done on the Warbler side, althoughlikely less reasonable - what kind of version you're using to pack and at actual runtime might be different (as you mentioned on the Warbler ticket that jruby-jars requirement should get an upper limit).

Alternatively to this what we could possibly do on 1.2.x is disable the jruby-rack config capture (on init failure) for JRuby 10.

Not sure I fully follow but sounds like things are getting complicated... 😉

[chadlwilson]

True, but we can't change the requirements for already pushed versions, so in practice that still that kinda leaves people ending up accidentally using incompatible combinations (ignoring yanking gems).

But yeah, ok. I'll leave this and refocus on Rack 3 and 1.3.

Would you be able to help push a release of this branch as it currently stands in that case?

[chadlwilson]

Diff: jruby-rack-1.2.5...1.2-stable