Many places we use system properties I imagine we could use the constant value
as a default, and allow elements to individually toggle as needed for test
coverage. This provides a similar benefit without rearchitecting the codebase,
but does have the potential to miss things.
Unfortunately a lot
This sounds like a neat case for use of feature flags rather than
caching system properties.
On Tue, 31 Dec 2019 at 16:23, Volkan Yazıcı wrote:
>
> [Thanks so much for the prompt reply @Ralph.]
>
> In the plugin, I have certain behavior triggered by constants:
>
> if (Constants.ENABLE_THREADL
[Thanks so much for the prompt reply @Ralph.]
In the plugin, I have certain behavior triggered by constants:
if (Constants.ENABLE_THREADLOCALS) {
return toJsonViaTla(logEvent);
} else {
return toJsonViaObjectPool(logEvent);
}
To evaluate each case, I repeat my JUnit 4
Can you provide a PR that demonstrates what you would like to do? It is easier
for me to evaluate the pros and cons of that then guessing what the
implementation would look like.
Ralph
> On Dec 31, 2019, at 2:43 PM, Volkan Yazıcı wrote:
>
> A majority of the Log4j 2.0 constants are structure
A majority of the Log4j 2.0 constants are structured by means of
"public final" fields initialized via system properties. While this
serves great for accessibility, IMHO, becomes an obstacle for tests.
For instance, I have needed two maven-surefire-plugin executions for
log4j2-logstash-layout: one
