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 faster for "full" log events – JsonTemplateLayout is almost garbage-free while rendering stack traces; whereas ThrowablePatternConverter, which is internally used by GelfLayout through PatternLayout, performs extra allocations each time. Yes, GelfLayout manually constructs JSON, but JsonTemplateLayout too. It generates functions for rendering after parsing the template. It doesn't interpret the template each time. But anyway... I can share a benchmark report either today or tomorrow for a more factual argument.
I see and share your concerns regarding backward compatibility. 3.0.0 release is a good opportunity to remove functionality either deprecated or superseded by alternatives without getting concerned too much about the backward compatibility. Yes, indeed people might end up touching their logging configuration files during migration, but that is not the end of the world. Log4j already has a stunning track record for backward compatibility and a major release is one of those rare chances we as developers get to lose some extra maintenance burden. It won't be the first time we have removed a functionality from Log4j without an alternative, e.g., SerializedLayout. Also how long do we expect to maintain this backward compatibility, if not we can opt out in a major release? In conclusion, I think we can remove these modules and provide a migration guide in the manual. I kindly ask you to reconsider your thoughts on this. I by no means want to ruin the rock solid image of Log4j built by you and others, which I highly respect. On Thu, Feb 18, 2021 at 4:29 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > 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 the > JsonTemplateLayout in a backwards compatible way as users should not have > to change their configurations. > > Ralph > > > On Feb 18, 2021, at 8:10 AM, Volkan Yazıcı <volkan.yaz...@gmail.com> > wrote: > > > > 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 GelfLayoutTest class. The only missing piece > > of the puzzle is compression support, which I am gonna address in > > LOG4J2-3023 <https://issues.apache.org/jira/browse/LOG4J2-3023>. Do I > have > > a go for this operation? What do you think? > > > > On the other hand, I wish we would be able to implement compression as > some > > sort of filter applicable to layouts. Is such a thing possible? > > >
