Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add logging support #32

Open
aalmiray opened this issue Sep 17, 2020 · 8 comments
Open

Add logging support #32

aalmiray opened this issue Sep 17, 2020 · 8 comments
Labels
enhancement New feature or request

Comments

@aalmiray
Copy link
Contributor

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

@aalmiray aalmiray added the enhancement New feature or request label Sep 17, 2020
@gunnarmorling
Copy link
Member

gunnarmorling commented Sep 17, 2020 via email

@aalmiray
Copy link
Contributor Author

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.

@gunnarmorling
Copy link
Member

gunnarmorling commented Sep 17, 2020 via email

@aalmiray
Copy link
Contributor Author

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

@gunnarmorling
Copy link
Member

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

@aalmiray
Copy link
Contributor Author

What I can understand looking at qos-ch/slf4j@4128670, 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?

@gunnarmorling
Copy link
Member

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.

@msgilligan
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants