Are there no other backends ?
Gaibhne opened this issue · 8 comments
At first glance, this looked like an exciting new library. I really like the approaches to both API and performance concerns. But upon closer inspection, it looks like there are literally no backends supported other than to the ancient and long since totally abandoned Log4J project (not even Log4J 2). I am surprised that none of the current generation backends are supported, nor a general purpose framework like SLF4J. Is this library designed to only be used with legacy projects, or am I simply missing documentation on how to use other backends ?
ps.: I saw there is a logback backend project, but it's also been abandoned and is not available on Nexus, so I'm still very confused as to the status of this project in regards to projects with modern logging backends.
@Gaibhne Yeah, I'm a bit puzzled too that a backend for log4j was introduced so apparently quickly and easily, but I do understand that interest in backends for log4j 2 and logback have already been raised in issues #24 and #25.
I do also understand, though, that documentation on how to use Flogger is rather lacking. I vaguely recall that JUL (java.util.logging) is also implemented as a backend for Flogger, but I can't remember now why I think that, and neither do I actually know how to use JUL as a backend.
@ronshapiro Is there any documentation yet on how to use Flogger with JUL? Also, is there anything that we can do to help with getting Flogger to support log4j2 and Logback? :)
@Gaibhne - we almost exclusively use JUL internally, so we haven't built other backends yet. The backends you see are ones that others have implemented. We don't have plans to actively create backends, but we're happy to help review PRs and include them in the project if someone wants to write one.
Btw, when you contribute to a project, whether new or old, saying that you are "baffled" at the level of support is probably a good recipe for rubbing project maintainers the wrong way. I'll take it that it wasn't intentional, but it's worth using nicer language in the future.
@jbduncan JUL is the default. There's no configuration necessary.
@jbduncan JUL is the default. There's no configuration necessary.
Oh cool, thanks for the clarification @ronshapiro!
We don't have plans to actively create backends, but we're happy to help review PRs and include them in the project if someone wants to write one.
SGTM. :)
@ronshapiro I will see what I can do about cloning the Log4J backend and switching it to SLF4J, which might not be as clean as backends for the actual logging frameworks, but is what we need internally at the moment. If I end up with something serviceable, I'll happily open a PR.
As for the language, I believe there is a misunderstanding - I was baffled at the lack of backends the library supported, not at the support given by you contributors. I am sorry, I did not mean to offend.
In support of Gaibhne, he is not the only one confused by the promise of such a good api with such "obvious missing" backend. This is google's logging framework and it uses JUL? There must be something more to this picture. Unless you're already using the java 9 logging module, in which case I need to go study that immediately...:)
No, it really is as simple as "Google's logging uses JUL" so there's been no incentive internally to add more backends. The Gerrit team added the Log4J backend in about a week, they are very simple to write.
We looked at the Java 9 logging module but didn't think that was suitable for debug logging (it seems more a driver level thing by the looks of how it's configured).
We now also have an SLF4J backend.
I think we should close this in favor of having specific issues for individual requests backends. Those are much easier to search for and manage.