You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Volkan Yazıcı <vo...@gmail.com> on 2020/06/15 18:36:31 UTC
Removal of log4j-layout-jackson-* modules
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.
Re: Removal of log4j-layout-jackson-* modules
Posted by Carter Kozak <ck...@ckozak.net>.
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ı <vo...@gmail.com> 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 <bo...@gmail.com>
>
Re: Removal of log4j-layout-jackson-* modules
Posted by Matt Sicker <bo...@gmail.com>.
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ı <vo...@gmail.com> 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 <bo...@gmail.com>
Re: Removal of log4j-layout-jackson-* modules
Posted by Matt Sicker <bo...@gmail.com>.
By the way, if you were suggesting to rename the branch to release-3.x for
symmetry or anything, that’d be fine. I mostly meant we don’t need a third
main branch.
On Wed, Jun 17, 2020 at 04:20 Volkan Yazıcı <vo...@gmail.com> wrote:
> Not really, since
>
> 1. I cannot do anything for YAML and XML layouts, obviously.
>
> 2. JsonLayout can leverage JsonTemplateLayout with the
> exception of stack traces, since Jackson serializes `Throwable`s
> "as is" with nested `StackTraceElement`s, which is, IMHO,
> pretty unconventional and I prefer not to implement this feature
> in JTL.
>
> On Mon, Jun 15, 2020 at 11:49 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> > Is it possible to modify those Layouts to use yours instead? I’d prefer
> not to break existing applications.
> >
> > Ralph
> >
> > > On Jun 15, 2020, at 11:36 AM, Volkan Yazıcı <vo...@gmail.com>
> 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 <bo...@gmail.com>
Re: Removal of log4j-layout-jackson-* modules
Posted by Volkan Yazıcı <vo...@gmail.com>.
Not really, since
1. I cannot do anything for YAML and XML layouts, obviously.
2. JsonLayout can leverage JsonTemplateLayout with the
exception of stack traces, since Jackson serializes `Throwable`s
"as is" with nested `StackTraceElement`s, which is, IMHO,
pretty unconventional and I prefer not to implement this feature
in JTL.
On Mon, Jun 15, 2020 at 11:49 PM Ralph Goers <ra...@dslextreme.com> wrote:
>
> Is it possible to modify those Layouts to use yours instead? I’d prefer not to break existing applications.
>
> Ralph
>
> > On Jun 15, 2020, at 11:36 AM, Volkan Yazıcı <vo...@gmail.com> 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.
> >
>
>
Re: Removal of log4j-layout-jackson-* modules
Posted by Ralph Goers <ra...@dslextreme.com>.
Is it possible to modify those Layouts to use yours instead? I’d prefer not to break existing applications.
Ralph
> On Jun 15, 2020, at 11:36 AM, Volkan Yazıcı <vo...@gmail.com> 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.
>