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 from Log4j 2 to 3.
Gary On Thu, Feb 18, 2021, 11:49 Ralph Goers <ralph.go...@dslextreme.com> 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? > >> > >> > >> > > >
