Garret Wilson

Thanks for attempting to address this. On the face of it, it doesn't feel right that we're creating sort of a duplicate of the logging framework itself—a sort of shadow...

To look at this another way: if you're going all out and having an internal, out-of-band logger with a system of log levels and everything, aren't you essentially re-implementing `slf4j-simple`?...

I think the `slf4j.verbosity` approach could also be confusing to users, who might be thinking that they are setting the logging level for whatever provider they have chosen. (Setting the...

> IMO, 120 lines of code do not qualify as a "framework" I was referring mainly to duplicated functionality, not to size. I want to stress that I'm trying to...

> "slf4j.internalVerbosity" I think that does bring up the point that we might want to think about what we're _calling_ this new thing. Is it "the internal logging ~framework~ system?"....

Please see related #1180 for updating the outdated Log4J SLF4J implementation which the library brings in automatically.

Here's another reason to switch from Log4j to Logback, or at least switch to pure SLF4J and allow the developer to choose the logging implementation. Log4j has some complicated under-the-hood...

I've found an ugly-but-it-works way to get the latest Log4j 9+ classes included in a shaded JAR and avoid the `sun.reflect.Reflection.getCallerClass` warning. First _remove_ any `true` configuration you've had for...

> there's still an issue with that approach. It's opinionated. You're pretty much telling everyone that they would be forced to use Logback @driverpt , I'm a little confused. With...

> we actually need an implementation in our code What specifically do you need an implementation for? Wouldn't you just be collecting special AWS-related information, but and then sending that...