OME (Open Microscopy Environment) develops open-source software and data format standards for the storage and manipulation of biological light microscopy data. A joint project between universities, research establishments and industry in Europe and the USA, OME has over 20 active researchers with strong links to the microscopy community. Funded by private and public research grants, OME has been a major force on the international microscopy stage since 2000.
Motivated primarily by the regression in #6405 and https://github.com/ome/openmicroscopy/issues/6405#issuecomment-2283339623, 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 - https://github.com/ome/openmicroscopy/pull/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
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.
Motivated primarily by the regression in #6405 and https://github.com/ome/openmicroscopy/issues/6405#issuecomment-2283339623, this bumps the version of
jul-to-slf4jandjcl-over-slf4jto the latest release of the 2.0.x series, currently 2.0.16. These should be compatible with the version ofslf4j-apiwhich is now shipped in OMERO.server.As an additional feature, the latest version of
jul-to-slf4jnow depends onreload4j(rather thanlog4j) for testing purposes. This does not resolve the dependency problems raised in #6405 but it further reduces the chances oflog4j.jarunexpectedly 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
slf4and ultimatelylogback.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
slf4jandlogbackover a decade ago - https://github.com/ome/openmicroscopy/pull/1006.Within OMERO, there are still a few classes making internal use of either JCL or JUL:
Blitz-0.logat the server startupome.util.Utilsuses JUL in its closeQuietly API,Utils.closeQuietlyis used in a few components to close input streams however the logging message will only appear ifclose()throws an exception so I can't think of a good scenario off-handomero.clientand the import code base primarily when calling keepAlive - https://github.com/search?q=org%3Aome+omero.util.Resources+language%3AJava&type=code&l=JavaAs a follow-up all the classes above could probably be updated to use the
slf4jAPI 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.