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
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
[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
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
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
Hi all,
What's the bets way to contribute to log4cxx? There's a comment from
a few months ago on LOG4CXX-486[1], and not much has been done since
then. I'm willing to do the work to maintain log4cxx and do the
release, so what is the best way to become a contributor/committer?
-Robert
On Mon, Dec 30, 2019 at 10:15 PM Carter Kozak wrote:
> Beyond StringBuilder instances, we attempt to clear references
> from all thread local references to avoid substantial overhead. In
> practice this works nicely because it reinforces java performance
> characteristics. Java threads are fairly
