Yes, I am aware of Flogger. Both the Log4j and SLF4J APIs now also have fluent methods for those that prefer them. But the biggest problems with JUL include requiring everything being wrapped with isEnabled type methods to avoid logging overhead, an extremely limited set of Handlers, extremely limited filtering capabilities and finally, the terrible way it binds the logging implementation to the API. Although Log4j provides the documented way of bridging from JUL to it most people can’t use it because JUL typically initializes and binds to the JDK implementation before log4j can set the system property and they do not want to rely on having to manually set it. The alternative approach of having a handler that routes to another logging framework is a hack and almost inevitably results in some performance loss.
Ralph > On Nov 6, 2022, at 12:36 AM, Mark Derricutt <m...@talios.com> wrote: > > On 6/11/2022 at 8:31:45 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > >> I can absolutely guarantee you that if Google is actually using JUL that >> they >> have written plenty of their own code on top of it since JUL is woefully >> incomplete. > > > Google came up with Flogger - their fluent logging API that wraps JUL ( and > now has pluggable backends ) but doesn’t seem to have any any updates for > awhile: https://google.github.io/flogger/ > > The benefits page ( https://google.github.io/flogger/benefits ) is quite > compelling, tho I find the API a bit cumbersome. > > Mark > > -- > "Great artists are extremely selfish and arrogant things" — Steven Wilson, > Porcupine Tree --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
