Ship a logging implementation

[ctrueden]

PyImageJ does not currently ship a log4j implementation, which results in an obnoxious warning at startup:

log4j:WARN No appenders could be found for logger (org.bushe.swing.event.EventService).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.

We can fix it by making imagej.init() include a log4j implementation on the classpath.

[ctrueden]

I tried with log4j-over-slf4j, and with logback-classic, but neither one on the runtime classpath clears up the warning. So further investigation is needed to understand more deeply what's going on here.

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/pyimagej-error-when-initializing/48765/3

[ctrueden]

Don't want to use log4j anymore, due to all the community hysteria—ahem security concerns. But still need to figure out this warning.

[ctrueden]

I didn't fix this bug yet. But I did fix the adjacent illegal reflection access warnings, as of 135bbf9, supported by scyjava's new jvm_version function present as of scijava/scyjava@73d758e.

[ctrueden]

The key to fixing this bug will be to use version 2.4.0 or later of ImageJ2, which is not yet released. We have already purged the log4j dependencies from the dependency tree—we just need to validate the current pom-scijava BOM using the melting pot, fix any problems, release pom-scijava 32.0.0, with net.imagej:imagej and sc.fiji:fiji preemptively bumped, and then cut those releases as well. At that point, log4j will no longer be in the mix, so these messages should disappear. See also scijava/pom-scijava#179.

[ctrueden]

As soon as we have an ImageJ2 v2.4.0, we should update this repository across the board to recommend using it. Then this issue can be closed, assuming the log4j warnings are indeed gone.

[ctrueden]

As soon as we have an ImageJ2 v2.4.0, we should update this repository across the board to recommend using it. Then this issue can be closed, assuming the log4j warnings are indeed gone.

This log4j warnings were indeed fixed by ImageJ2 2.4.0. But then there are different but related warnings:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

We can fix it by making imagej.init() include a log4jSLF4J implementation on the classpath.

Earlier this month, I thoroughly researched how to deal with this annoying issue once and for all. I made a spreadsheet with details. We decided the correct solution for PyImageJ is ensure that scijava-config is always on PyImageJ's classpath: 1261e31.

Relatedly:

• With scijava/pom-scijava@a20be31, pom-scijava now excludes logback-classic from Bio-Formats-related dependencies. This would make imagej.init('sc.fiji:fiji') and similar behave better even without the above 1261e31 fix, by avoiding SLF4J's default log level of DEBUG (!) from coming into effect and spamming the console when Bio-Formats is on the classpath. See also Make logback dependencies optional ome/bioformats#3886 and Make logback dependencies optional ome/ome-common-java#68, which aim to address this issue on the Bio-Formats side.
• I also added scijava-config to net.imagej:imagej as an optional dependency with imagej/imagej2@7fb181d. If in the future jgo gains support for automatically adding optional dependencies to the environment, this will relieve PyImageJ from need to do it itself here.