Improve logging with a local diagnostic context.
Instead of writing logger.log(MESSAGE, localDiagnosticContext, args...) to log with a diagnostic context, we now
write logger.with(localDiagnosticContext).log(MESSAGE, args...). This is also the case when providing a throwable instance.
This approach simplifies the straightforward case, reduces the number of log method overloads, and cuts down dramatically on the future combinatorial growth of logger methods, especially if we ever add another similar feature like this. Test support for logging with nested contexts has also improved.
(Special thanks to @saqibsaleem-ee for helping figure out what the most balanced api design approach was.)
NOTE THAT THIS RELASE CONTAINS A BACKWARDS INCOMPATIBLE CHANGE FROM v0.3.0:
- Calls that log using a local diagnostic context have changed from
logger.log(MESSAGE, localDiagnosticContext, args...)tologger.with(localDiagnosticContext).log(MESSAGE, args...)as described above. This includes the versions of the log method that take a throwable as a parameter.
In addition to the one required backwards incompatible change, OpsLoggerTestDouble has changed as well. The old way of constructing and spying on one spy(new OpsLoggerTestDouble<>()) will still work when you aren't creating nested loggers by calling .with(localDiagnosticContext).
However, once you start using the "with" feature in your code, constructing OpsLoggerTestDouble instances like so: OpsLoggerTestDouble.withSpyFunction(Mockito::spy) (assuming you use Mockito) will be much easier, as nested loggers will automatically be wrapped in spies for you. As always, see the sample-usage project for more information.