Can one of the admins verify this patch?

ok to test.

Happy to finally see this PR, though still I'm not 100% convinced:

• Why are these "environment variables" being registered into the context; they're in the LogContext base class, but the two actual implementations don't include them into the format() output, so how they're supposed to be visible in the log file at the end?

@kiesel : you're right, according to YAGNI, the env variables should not be registered into the context.

I see 2 options here:

1. Clean-up the code to remove them from the LogContext base class
2. Add an EnvironmentLogContext implementation to make use of them in format()

What do you guys say?

I assume (and believe to remember from a discussion with @cconstandachi), that this is introduced because you'd need a place where all these variables are available to be collected. They're not available in any one arbitrary location in the code.

So, maybe we can trigger being handed these information at the places where it happens now, but only on demand. I propose to:

1. Add an EnvironmentLogContext interface with all these getters and setters
2. If a LogContext derived class implements this interface, the runners will pass in the information.
3. It is up to the respective implementation to decide how that information is then used in the format() or toString() method

I would refrain from providing an EnvironmentLogContext implementation, as that would prevent you from being either a NDC- or MDC-backed implementation...

I refactored this PR as follow:

1. Removed the environment variables from LogContext and transformed it to an interface. Moreover, using util.log.Layout as example, I renamed it to util.log.Context using @thekid's now famous dot notation :)
2. Added custom toString() implementations for NestedContextLog and MappedContextLog
3. Added util.log.context.EnvironmentAware interface and updated the runners to use it
4. Added test classes to logging.ini (ups :) so related unit tests are now run

Let me know what you guys think.

I can remove the environment variables injection (and the interface) and add it as a new pull request later if the case. I think it can be now regarded as a separate issue.

I'm OK with this, for both 5.8 and 5.9 series. @kiesel - what do you say?

No objections, I'd love to see this in 5.8 and 5.9. 👍