Configuration breaks have always been painful for consumers for a couple reasons. We don't have a great way to tell whether an appender is still being used, and it's not clear to consumers when they upgrade libraries that their configuration may no longer work. This becomes more confusing when a configuration is customized by a deployment of a product, it can be difficult to reasonably announce and remediate logging config changes. There are still tons of projects using log4j-1.2 because of the difficulties of upgrading to log4j2 requiring all deployments to rewrite their configurations. Ralph has made substantial progress through the log4j1.2 configuration parser, I'm curious if there's something similar we could do in this case as well. We should try to avoid building a reputation for configuration API breaks :-)
-ck On Mon, Jun 15, 2020, at 14:43, Matt Sicker wrote: > The master branch is still the release-3.x branch. I don't think we'll > need an explicit branch around that for a while (master would have to > be v4 or something). > > On Mon, 15 Jun 2020 at 13:36, Volkan Yazıcı <[email protected]> wrote: > > > > Hello, > > > > I want to go forward and delete log4j-layout-jackson-* modules from > > the master. This will effectively remove JsonLayout, XmlLayout, and > > YamlLayout. Given these changes break backward compatibility, shall I > > introduce these changes to a new release-3.x branch? Maybe this is a > > good moment to discuss how we think about maintaining these modules in > > the future. > > > > For the records, I think Jackson serialized LogEvent layouts are not > > really practical due to a severe behaviour: stack traces are > > serialized as nested documents. Eventually these layouts need to be > > persisted somewhere and none of the document stores that I know of > > support such deeply nested schemas. > > > > Kind regards. > > > > -- > Matt Sicker <[email protected]> >
