Welcome! Please see the About page for a little more info on how this works.

+2 votes
in Java Interop by

Structured logging beats plain text.
Context logging + structured logging is a net win. At my workplace we could dump our ad-hoc logging solution which besides support for context logging is inferior to tools.logging, and will make a strong addition to the library's capabilities.
To add support for context logging, we'll probably need an additional protocol for the frameworks which implement such APIs (like SLF4J).
Not sure if it's required, but an additional logging function might also simplify the implementation.
Suggested usage:

(log/info-c {:foo "bar"} my-error "some message")
We use c.t.l with log4j2 at work and we've leveraged the MDC stuff via Java interop and wrapped it in a macro. I haven't looked at what it would take to make that generic tho' but it would be nice to have it standardized for all log impls.

We have (with-log-context context-map .. body ..) as a macro that adds the context-map data to log4j2's MDC directly.
Is there something more needed in tools.logging?
Yes, some code path to reach the methods which take slf4j's Markers. MDC is insufficient for structured logging.

But MDC is extremely useful for "slicing and dicing" as that answer says -- and for us the ability to tag an entire request's logging with a user ID or an IP address or other, similar, concern is far more important than being able to filter on different logging "types" (markers).

So, I think the takeaway here is that some people will want markers, some will want MDC, some will want both, and some won't care about either.

Markers affect the API directly, because they are passed into the error(), warn(), whatever calls. Given that c.t.l already provides variadic calls and special-cases Throwable as the first argument, I'm not sure what the API should look like for adding Markers (esp. when they are different classes for each logger implementation)?

Maybe errorm, warnm, infom, etc that treats the first argument as a Marker? How would you add that to the underlying write! without breaking any existing implementations (outside c.t.l.)?
There would likely be a need for a new API, like you said, with `{log}m`, which I'm happy with.
Regarding the write! method, I'd add another method or arity and call into it, that way implementations which don't support Markers or something equivalent need to make no change.

1 Answer

0 votes

We ported to strcutrued logging with Markers, as wrote here: https://stackoverflow.com/a/60101309/8162407

with a thin wrapper on clojure.tools.logging. really happy with it. Upvoting.

Is there still a request here for tools.logging, and if so, what?
I think there's a question of whether c.t.l could support contexts or markers generically across all (Java) logging libraries?

Personally, I'm not sure how often people _change_ logging implementations so I don't think it's worth it. If you've picked a logging implementation, you can do MDC or markers with it however you want with Java interop...
How can you use markers with it in conjunction with tools.logging? I know MDC can be done easily with macros, but how can I convey Markers dynamically?