I agree with Volkan, we should not accept a one-off. Instead, I would prefer we generically support whatever Apache Commons Compress supports. I can help beef up Compress if we need anything in there to make Log4j better.
Gary On Sun, Jun 18, 2023, 14:52 Volkan Yazıcı <vol...@yazi.ci> wrote: > Recently, somebody asked for zstd compression > <https://github.com/apache/logging-log4j2/issues/1508>. I indicated that > adding zstd would be nice, but ideally we should make the compression > extensible [by means of plugins]. As usual, even though I offered PR > assistance, the user has individually submitted a PR only solving their > problem: adding zstd to the rolling appender. I am not inclined to accept > these kinds of "add button X to dialer Y" contributions, where I think > Log4j suffers a lot from. > > AFAIC, there should be plugins implementing a certain compressor interface, > a registry of these, and the use-site (`RollingAppender`, `GelfLayout`, > etc.) accessing these compression schemes via registry. This will not only > enable users to add their custom compression scheme, but also other > components to take advantage of this. As a particular example, more or less > the only thing `JsonTemplateLayout` falls short compared to `GelfLayout` is > compression support; though this could have perfectly been solved via a > [wrapper] `CompressingLayout` I suggested in LOG4J2-3023. > > I would appreciate some feedback on my thinking process here. When it comes > to Log4j, I am really allergic to specialized solutions ignoring the rest > of the code base. >
