layrry icon indicating copy to clipboard operation
layrry copied to clipboard

Add logging support

Open aalmiray opened this issue 5 years ago • 8 comments

It would be good to turn on verbose output when Layrry is assembling the layers for example.

aalmiray avatar Sep 17 '20 12:09 aalmiray

+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).

gunnarmorling avatar Sep 17 '20 13:09 gunnarmorling

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.

aalmiray avatar Sep 17 '20 13:09 aalmiray

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.

gunnarmorling avatar Sep 17 '20 14:09 gunnarmorling

How is that API supposed to work? So far I've found examples that claim you must implement your own System.LoggerFinder and Logger.

aalmiray avatar Sep 18 '20 20:09 aalmiray

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).

gunnarmorling avatar Sep 18 '20 23:09 gunnarmorling

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.Logger in Layrry APIs.
  • Provide an additional artifact (layrry-logging perhaps?) with a binding to j.u.l.Logger which can be used in case no LoggerFinder is available?

aalmiray avatar Oct 25 '20 17:10 aalmiray

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.

gunnarmorling avatar Oct 25 '20 20:10 gunnarmorling

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.

msgilligan avatar Nov 08 '20 21:11 msgilligan