[feat] (re-invent) log4j as a logging backend

[kares]

No description provided.

[chadlwilson]

(unrelated) the JRuby 9.4 on Java 11 JVM combination is reliably flaky (sic). It's interesting, something indeterminate going on there that leads to something being the wrong type at times. Probably something implicit to JRuby rather than something this library is doing, I think. (I re-ran the action)

[chadlwilson]

Just curious, what's your theory of the case with logging libraries these days, rather than supporting slf4j and leaving it at that?

[kares]

Regarding old (logging) libraries IMHO we should have them around to ease migration for legacy users...

In terms of only supporting slf4j, that is reasonable but native log4j (2.x) is useful since it's a major logging library out there these days and also supports debug(java.lang.CharSequence) API which allows (since #306) to pass down native Ruby string objects without conversion just to satisfy the (debug(java.lang.String)) method signature.

From what jruby-rack currently support we could remove commons-logging eventually but I do not think it's a big deal.
Just like adding native support for log4j 2.x here is fairly minimal. 🤷

Does that make any sense?
I do not have numbers on log4j being the major library, hopefully I am not wrong.
Java libraries in general probably just use slf4j API but actual Java applications likely have a logging backend such as log4j.

[kares]

JRuby 9.4 on Java 11 JVM combination is reliably flaky (sic). It's interesting, something indeterminate going on there that leads to something being the wrong type at times.

Yeah, seen the failure several times, it's a JRuby bug I've bumped into elsewhere as well.

[chadlwilson]

Yup, just curious to be honest, since the saga of Java logging seems to be an endless one :-)

I thought perhaps the motivation might be specific to the needs/defaults of particular servlet containers of particular relevance to, or most commonly used with jruby-rack in your experience.