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 the json layout is relatively low, however I agree that we should deprecate it in favor of the much better json template layout and suggest users migrate if they report bugs on the json layout.
On Thu, Feb 18, 2021, at 11:49, Ralph Goers wrote: > 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 they > had hundreds of log4j.xml files to convert. Granted, this may be a somewhat > simpler task but it is a task I am hesitant to inflict on users for no > particularly good reason. After all, we could simply keep the old layouts > around to ease their burden. > > Ralph > > > On Feb 18, 2021, at 8:59 AM, Volkan Yazıcı <volkan.yaz...@gmail.com> wrote: > > > > 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? > >> > >> > >> > > >
