layrry
layrry copied to clipboard
Add logging support
It would be good to turn on verbose output when Layrry is assembling the layers for example.
+1
Might be a good occasion to look into loading all Layrry dependencies via their own layer instead of the boot layer, as is the case now. That way, they won't interfere with any user deps in application layers (which seems likely for popular logging libs).
True, but wouldn't using the java.logging module be enough? Most 3rd part logging frameworks can route j.u.l calls to their logging pipeline anyway.
Ah yes, good point. I wouldn't use JUL then, but rather System.Logger ( https://twitter.com/gunnarmorling/status/1276880104992509953), as then you get away with adding the java.base module.
How is that API supposed to work? So far I've found examples that claim you must implement your own System.LoggerFinder and Logger.
You could think of it as an slf4j-like API, coming with the JDK itself. Logger libraries should provide the required binding, e.g. here for log4j. JUL can be used if nothing else is available, I believe. And somewhat meta, slf4j also will provide a binding (enabling to use all the logger libraries it supports) at some point (pending PR courtesy to @nicolaiparlog).
What I can understand looking at https://github.com/qos-ch/slf4j/pull/232/commits/412867078d5af98899a8250d4c6f32eff5129e66, a System.Logger implementation delegates to "something" that performs thee actual logging. In the case of the previous link it's an SLF4J logger.
In our case we don't have a "logger" per-se. We could wrap a j.u.l.Logger but that would required java.logging in the impl.
Is the intention to break logging support into two places:
- use
System.Loggerin Layrry APIs. - Provide an additional artifact (
layrry-loggingperhaps?) with a binding toj.u.l.Loggerwhich can be used in case noLoggerFinderis available?
AFAIK, that default binding to JUL is already part of the JDK: if no other binding exists and JUL is present (i.e. not in jlink image without the java.logging module, System.Logger should delegate to JUL. In Layrry's APIs, we should only call System.Logger.
From JEP 264
Non-Goals
It is not a goal to define a general-purpose interface for logging. The service interface contains only the minimal set of methods that the JDK needs for its own usage.
It is not a goal to support programmatic logging configuration (setting levels, destination files, etc...) via the API.
I tried to convert a small library from slf4j to use System.logging and definitely found the System.logging API lacking.
It might be useful to have a small wrapper library that has a subset of the slf4j API that solves the above issues and makes conversion of libraries easier. At a bare minimum it would be nice to have log.info(), log.warn()`, etc. as well as support for '{}' placeholders.