Bump jul-to-slf4j and jcl-over-slf4j to version 2.0.16

[sbesson]

Motivated primarily by the regression in #6405 and #6405 (comment), this bumps the version of jul-to-slf4j and jcl-over-slf4j to the latest release of the 2.0.x series, currently 2.0.16. These should be compatible with the version of slf4j-api which is now shipped in OMERO.server.

As an additional feature, the latest version of jul-to-slf4j now depends on reload4j (rather than log4j) for testing purposes. This does not resolve the dependency problems raised in #6405 but it further reduces the chances of log4j.jar unexpectedly creeping into the binaries.

Testing should confirm that logging statements using either JCL (Apache Commons Logging, formerly Jakarta Commons Logging) or JUL (java.util.logging) as still handled via slf4 and ultimately logback.

Unfortunately the biggest usage of these logging frameworks will be in third-party dependencies since the majority of the OMERO code base has been converted to using slf4j and logback over a decade ago - #1006.

Within OMERO, there are still a few classes making internal use of either JCL or JUL:

• the JVM checks in ome.service.util.JvmSettingsCheck are using JCL -L85. These should be easy to test as they are logged in Blitz-0.log at the server startup
• ome.util.Utils uses JUL in its closeQuietly API, Utils.closeQuietly is used in a few components to close input streams however the logging message will only appear if close() throws an exception so I can't think of a good scenario off-hand
• omero.util.Resources uses JUL internally when adding/removing/cleaning managed entries. Here again most logging statement are at the FINEST (aka TRACE) level and only unexpected behaviors are logged at a WARNING level. This class is used in omero.client and the import code base primarily when calling keepAlive - https://github.com/search?q=org%3Aome+omero.util.Resources+language%3AJava&type=code&l=Java

As a follow-up all the classes above could probably be updated to use the slf4j API and get rid of JCL and JUL at least in the OME codebase. I'll hold on opening these until this has been tested as it could make the testing more complicated.

[jburel]

@sbesson Do you need/have a ticket to capture the work to follow-up?

[sbesson]

@sbesson Do you need/have a ticket to capture the work to follow-up?

I have not done anything as I was waiting for feedback on the proposed changes first. Happy to capture as issues if this work would be up for consideration. In that case, would it be preferable to have a single issue in this repository or three issues in omero-model, omero-server and omero-blitz?

[jburel]

A single issue will make sense.

[sbesson]

A single issue will make sense.

Opened as #6416