Almost every logger in java operates this way. You set your library logging to debug and the end user and configure if they want debug logs from your library or not. They can even set context variables.
Python too. Honestly, any mature logger should allow embedding logs in library code that can be turned on or off by the end user. This was a solved problem 20 years ago. I honestly don't see what's so novel about this today. Or is this speaking to the sorry state of software engineering that plagues the JavaScript world?
Similar to this: OpenTelemetry has a golang library that allows you to instrument your library so that you can send traces, logs, etc. to an OTEL endpoint, but that instrumentation doesn't actually do anything unless the developer of the actual application uses a separate golang library to actually trigger, collect, and transmit those traces. Otherwise it's basically a no-op.
The JS impl of OpenTel is awfully glued together. Sorry for the maintainers, but its inefficient and prometheus+logging will outmatch OT any day of the week (at least for JS)
I really want something like this to be built into the language or runtime, I don't want to juggle configuration for 4 different libraries. Log4j and tracing seem to be well established without being built in, but it feels too late for js.
It's Strings. They go somewhere. The interface writes itself: Consumer<String>.
At my absolute fanciest, I use a Queue, some terminal colouring, separate stderr from stdout, and write some short-hand functions (warn, err, info, etc.).
In the .Net space log4net is horrifically outdated and there's zero reason to use it today. Logging for modern .Net apps and libraries should be built on the Microsoft.Extensions.Logging abstractions which provide the type of features covered in TFA. They also provide a clear separation between generating log events in code and determining where & how logs are stored. For basic needs you can use simple log writers that tie in directly with MEL, or for advanced needs link MEL with Serilog so that you can use its sinks and log processing pipeline.
So many knee jerk comments from people who have not read the article. The author describes how existing logging systems are geared towards applications, and sometimes libraries need a way of logging that provides more granularity and control - especially when the library spans multiple levels of abstraction.
17 comments
[ 5.0 ms ] story [ 48.2 ms ] threadSimilar to this: OpenTelemetry has a golang library that allows you to instrument your library so that you can send traces, logs, etc. to an OTEL endpoint, but that instrumentation doesn't actually do anything unless the developer of the actual application uses a separate golang library to actually trigger, collect, and transmit those traces. Otherwise it's basically a no-op.
I'm curious if this is enough https://nodejs.org/api/diagnostics_channel.html
I don't like the js hotel libraries, their docs feel deliberately obtuse
At my absolute fanciest, I use a Queue, some terminal colouring, separate stderr from stdout, and write some short-hand functions (warn, err, info, etc.).
These are the bugs I don't have: https://github.com/apache/logging-log4j2/issues