feat: Json layout modern implementation

[pankajagrawal16]

Issue #, if available:

Description of changes:

Json Template Layout is recommended way of doing and extending structured logging in log4j now.

JsonTemplateLayout is a customizable, efficient, and garbage-free JSON generating layout. It encodes LogEvents according to the structure described by the JSON template provided. In a nutshell, it shines with its

• Customizable JSON structure (see eventTemplate[Uri] and stackTraceElementTemplate[Uri] layout configuration parameters)

• Customizable timestamp formatting (see timestamp event template resolver)

• Feature rich exception formatting (see ] and xref:event-template-resolver-exceptionRootCause[ event template resolvers)

• Extensible plugin support

• Customizable object recycling strategy

Checklist

• Meet tenets criteria
• Update tests
• Update docs
• PR title follows conventional commit semantics

Breaking change checklist

RFC issue #:

• Migration process documented
• Implement warnings (if it can live side by side)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[pankajagrawal16]

@humanzz Have a look

[humanzz]

Is there a way to actually have that default to UTC unless overridden?

[pankajagrawal16]

Rite now the behaviour is consistent with existing implementation, meaning it will pick system default timezone. But with new approach, users have ability to customise timezone if need be, which was not possible before.

[heitorlessa]

We could have an env var, otherwise it’d be a breaking change (same happened in Python). For v2, we could consider it having as default, tho I was surprised by how many still stick with local time (default in Lambda and loggers too)

…

On Sun, 26 Dec 2021 at 14:40, Ahmed Kamel ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In docs/core/logging.md <#670 (comment)> : > @@ -123,6 +130,44 @@ to customise what is logged. } ``` +### Customising fields in logs + +- Utility by default emits `timestamp` field in the logs in format `yyyy-MM-dd'T'HH:mm:ss.SSSZz` and in system default timezone. +If you need to customize format and timezone, you can do so by configuring `log4j2.component.properties` and configuring properties as shown in example below: + +=== "log4j2.component.properties" + + ```properties hl_lines="1 2" + log4j.layout.jsonTemplate.timestampFormatPattern=yyyy-MM-dd'T'HH:mm:ss.SSSZz + log4j.layout.jsonTemplate.timeZone=Europe/Oslo Is there a way to actually have that default to UTC unless overridden? — Reply to this email directly, view it on GitHub <#670 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZPQBFKSDQVLE45GFSLUILUS4LMFANCNFSM5KX4K6EQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[pankajagrawal16]

We could have an env var, otherwise it’d be a breaking change (same
happened in Python).

For v2, we could consider it having as default, tho I was surprised by how
many still stick with local time (default in Lambda

It won't be a breaking change, because existing functionality og using deprecated implementation will work as is without any change.

With upgrade to new layout configuration, behaviour will still remain the same.

[heitorlessa]

Oh no Pankaj, what I meant about breaking change is in response to the question of - “why not making UTC the default?” For Python, customers can set utc=True as an opt-in, else we use local tz On Sun, 26 Dec 2021 at 17:34, Pankaj Agrawal ***@***.***> wrote:

…

We could have an env var, otherwise it’d be a breaking change (same happened in Python). For v2, we could consider it having as default, tho I was surprised by how many still stick with local time (default in Lambda and loggers too) On Sun, 26 Dec 2021 at 14:40, Ahmed Kamel *@*.***> wrote: *@*.**** commented on this pull request. In docs/core/logging.md #670 (comment) <#670 (comment)> : @@ -123,6 +130,44 @@ to customise what is logged. } ``` +### Customising fields in logs + +- Utility by default emits timestamp field in the logs in format yyyy-MM-dd'T'HH:mm:ss.SSSZz and in system default timezone. +If you need to customize format and timezone, you can do so by configuring log4j2.component.properties and configuring properties as shown in example below: + +=== "log4j2.component.properties" + - - log4j.layout.jsonTemplate.timestampFormatPattern=yyyy-MM-dd'T'HH:mm:ss.SSSZz - log4j.layout.jsonTemplate.timeZone=Europe/Oslo Is there a way to actually have that default to UTC unless overridden? — Reply to this email directly, view it on GitHub #670 (review) <#670 (review)> , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZPQBFKSDQVLE45GFSLUILUS4LMFANCNFSM5KX4K6EQ . You are receiving this because you are subscribed to this thread.Message ID: *@*.*** com> It won't be a breaking change, because existing functionality og using deprecated implementation will work as is without any change. With upgrade to new layout configuration, behaviour will still remain the same. — Reply to this email directly, view it on GitHub <#670 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZPQBFFZ2W2ZEWW7SGZTULUS47YPANCNFSM5KX4K6EQ> . You are receiving this because you commented.Message ID: ***@***.***>

[pankajagrawal16]

Oh no Pankaj, what I meant about breaking change is in response to the
question of - “why not making UTC the default?”

For Python, customers can set utc=True as an opt-in, else we use local tz

Oh yeah. Then i misunderstood. Definitely that is an option but then again with new approach users can do more natively using log4j config. But yeah we can spport that via environment variables config as well if need be.

[heitorlessa]

Keep what you’re doing - we have the same behaviour so we’re good ;-)

…

On Sun, 26 Dec 2021 at 20:40, Pankaj Agrawal ***@***.***> wrote: Oh no Pankaj, what I meant about breaking change is in response to the question of - “why not making UTC the default?” For Python, customers can set utc=True as an opt-in, else we use local tz Oh yeah. Then i misunderstood. Definitely that is an option but then again with new approach users can do more natively using log4j config. But yeah we can spport that via environment variables config as well if need be. — Reply to this email directly, view it on GitHub <#670 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZPQBC25FOIHOS7MLCWFZTUS5VTPANCNFSM5KX4K6EQ> . You are receiving this because you commented.Message ID: ***@***.***>