I would refrain from using/forcing log4j by default - can always use and wire it up specifically if you really need it. log4j should just use log4j-jul and things should be aligned?

I think 90% of common third-party libs are using SLF4J for logging (as it can be easily bridged to anything). Including SLF4J in the kernel would've solved a lot of problems. But of course this is a slippery slope and we want to stay away from dependencies. I guess we can declare JUL to be the "logger of JJava", and provide simple recipes for bridging SLF4J and others. Need to experiment with that.

Ok, this turned out to be a non-issue once we fixed the underlying bugs and did proper dependency shading.

about stdout/stderr - then those are "lost". stdout goes to notebook anyways - and stderr is not visible afaik (haven't tested/verified).

Stderr goes into notebook as well (with red background). FWIW, we control both those streams and can send them anywhere.

I wouldn't include them in any log control.

Fair enough. Let me flip the question then - most Java loggers by default (with no explicit config) send logs to stdout. So following that logic, the output of java.util.logging.Logger.getLogger("").info("Hi!") should go into the notebook itself. Currently, it is sent to the Jupyter server console.

I hope this is not a big deal, and just some prior IJava decision inherited by JJava that we can easily deal with. Just outlining the scope of work 🙂

And this takes us to another Jupyter-specific thing: there two logical "consoles" - the notebook itself, and the Jupyter server console (logging in the latter is a hot mess now with a mix of python, 2-line JUL, and SLF4J warnings).

So should the %log magic differentiate between these log targets:

1. Log to notebook
2. Log to Jupyter console (I think this is the default now? Maybe the notebook should be the default instead)
3. Log to file