0.4.0

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:

1. Calls that log using a local diagnostic context have changed from logger.log(MESSAGE, localDiagnosticContext, args...) to logger.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.

0.3.0

• Added sample code for constructing and injecting OpsLogger instances with Dagger (Issue #11)
• Support multi-enum OpsLogger usage (Issue #6) : calling build() multiple times with different type tokens will return the same instance if the actual logging configuration hasn't changed.
• Add the concept of global and local diagnostic contexts. A global DiagnosticContextSupplier is registered with OpsLoggerFactory and will usually track context information via ThreadLocal variables or a similar mechanism. Local DiagnosticContextSupplier instances are passed directly into the OpsLogger instance by the logging class. Using the global supplier is usually more convenient, but local suppliers work in situations where the global ones might not. In particular, ForkJoinPool workers and Java 8 parallel stream processing workers run on many threads and can't rely on ThreadLocal variables.

0.2.0

• Active Rotation Support: a method (OpsLoggerFactory.refreshFileHandles()) that can be called during rotation (after the original log file is moved, but before it is modified). This method guarantees that all file handles will be refreshed before it returns, and is designed to be called (via a REST api, etc) during a log rotation operation.
• Bug fix for issue #5.
• Implementation code without backwards compatibility guarantees (which is most of it at this point) has been moved to an impl package. The contents of this package are subject to changes, including incompatible changes without notice.

0.1.1

A bugfix release for issue #2.

0.1.0

The first release.

0.1.0-rc1

The first ever release candidate.