Thanks for your understanding. As I said, I am not against routing them all to
JsonTemplateLayout but I can understand that that might be difficult.
We do need to make sure that the Layout documentation on the web site makes it
clear that JsonTemplateLayout is the preferred solution.
Ralph
>
I am dropping the case due to objections from other committers.
I have closed the GitHub PR and JIRA ticket for the deprecation of
log4j-layout-jackson* modules.
On Thu, Feb 18, 2021 at 4:10 PM Volkan Yazıcı
wrote:
> As the title suggests, in accordance with the aim of reducing the
> maintenance
I believe we also have a backlog item about creating a sort of "fast
by default" or similar mode that allows users to opt-in to a sort of
"updated best practices" options for defaults. This would allow
configuration files to continue working while allowing new config
files to take advantage of simp
I agree with Ralph's comments here. As a developer shipping an application,
it's not clear how all my consumers have configured logging. I can upgrade
jars, but I wouldn't want to make a change that breaks some percentage of my
customers logging configurations. The cost of continuing to provide
FYI, at my day job, one major hurdle to updating one of our projects to
Log4j 2 are configuration files. This task is in progress. The less pain,
the better. In our case, our tooling is responsible for programmatically
updating these files. I do NOT want to have to sell this task AGAIN for
updating
Sorry, the one thing I have learned in the slow migration we have seen of
people moving from Log4j 1 to Log4j 2 is that changing logging configuration
files is difficult for many users while changing a jar version is not. We have
had many customers complain that upgrading was very hard because t
I don't have the benchmark report anymore in json-template-layout-adoc.vm,
but the benchmark is still there: JsonTemplateLayoutBenchmark. The last
time I have benchmarked it, JsonTemplateLayout was on par with GelfLayout
for "lite" (i.e., no stack trace, mdc, ndc) log events and significantly
faste
You would have to prove to me that GelfLayout is slower than JsonLayout. That
would be hard for me to believe since the GelfLayout is manually constructing
the JSON.
Also, You cannot remove any of the GelfLayout or any of the JsonLayouts. You
will need to replace them with logic that invokes t
As the title suggests, in accordance with the aim of reducing the
maintenance burden, I want to propose removal of the GelfLayout from
master, not release-2.x! Currently, JsonTemplateLayout already ships a
template producing exactly the same output as GelfLayout; see
GelfLayout.json template and Ge
