I would integrate it as is. Once it is here you can continue the work on
converting it to use templates or create an entirely new Layout.
Ralph
> On Jan 9, 2020, at 6:28 AM, Volkan Yazıcı wrote:
>
> Yes. I had the intention that you first wanted to see if a generic
> text-based templating sol
On Wed, Dec 25, 2019 at 7:38 AM Ralph Goers wrote:
> Also, I must admit I probably would have implemented the
> resolvers differently. It seems to me that each “entity" is going
> to return either a String, a number, a Map, or an array. So I
> would have just had the resolver return its key and i
Yes. I had the intention that you first wanted to see if a generic
text-based templating solution would work, since you were the one
proposing this idea in the first place. Would you rather first see the
current LogstashLayout replacing JsonLayout in log4j-core? If so, I
can first focus on integrat
Are you still considering contributing this?
Ralph
> On Jan 8, 2020, at 2:42 PM, Volkan Yazıcı wrote:
>
> On Tue, Dec 24, 2019 at 10:48 PM Volkan Yazıcı
> wrote:
>> In its current form, LogstashLayout can (almost) very well render the
>> GELF layout[1]. There are only two shortcomings: 1) epo
On Tue, Dec 24, 2019 at 10:48 PM Volkan Yazıcı wrote:
> In its current form, LogstashLayout can (almost) very well render the
> GELF layout[1]. There are only two shortcomings: 1) epoch seconds with
> fraction and 2) using PatternLayout while rendering messages. But no
> worries, I will address th
It would be an interesting experiment to find out how they perform. That said
it feels like it might be overkill to use a template engine for such a simple
thing, but if it performs well then I guess it may not matter.
What most users want to log is pretty simple. The vast majority of the over
That is a valid concern. Googl'ing bumped me into Rocker[1]. Its
garbage generation appears to be tractable. For the rest (Velocity,
FreeMarker, etc.), I am curious if we can create a memory pool to
reuse contextual objects.
[1] https://github.com/fizzed/rocker
On Wed, Dec 25, 2019 at 11:17 PM Ma
I’m not sure if any existing template libraries are garbage free, though I
like the idea in general at least.
On Wed, Dec 25, 2019 at 14:42 Volkan Yazıcı wrote:
> On Wed, Dec 25, 2019 at 7:38 AM Ralph Goers
> wrote:
> > FWIW, I am not necessarily proposing we implement that. I am
> > trying to
On Wed, Dec 25, 2019 at 7:38 AM Ralph Goers wrote:
> FWIW, I am not necessarily proposing we implement that. I am
> trying to point out that your templating approach doesn’t really
> seem to be tied to JSON, [...] I could just as easily imagine an
> XML template with xml resolvers.
This is a stri
The JSON pattern escape was added originally to form generic JSON layouts
if desired. I think I originally used that in a similar scenario, tho the
layout definition is huge.
On Wed, Dec 25, 2019 at 08:47 Carter Kozak wrote:
> On Wed, Dec 25, 2019, at 01:38, Ralph Goers wrote:
> >
> >
> > > On D
On Wed, Dec 25, 2019, at 01:38, Ralph Goers wrote:
>
>
> > On Dec 24, 2019, at 2:06 PM, Volkan Yazıcı wrote:
> >
> > Indeed ColumnMapping is an alternative approach. I believe due to its
> > origin, i.e., RDBMSes, it facilitates a 1-to-1 mapping particularly
> > targeted at table column names,
> On Dec 24, 2019, at 2:06 PM, Volkan Yazıcı wrote:
>
> Indeed ColumnMapping is an alternative approach. I believe due to its
> origin, i.e., RDBMSes, it facilitates a 1-to-1 mapping particularly
> targeted at table column names, e.g.,
>
> timestamp -> instant
> message -> summary
>
> One c
On Tue, Dec 24, 2019 at 4:38 PM Ralph Goers wrote:
> Personally, I would have no problem accepting a contribution that is
> backwards compatible and meets ASF requirements; it has to use the
> Apache License and the contribution needs to be signed off by anyone
> who has copyright claims. That can
Indeed ColumnMapping is an alternative approach. I believe due to its
origin, i.e., RDBMSes, it facilitates a 1-to-1 mapping particularly
targeted at table column names, e.g.,
timestamp -> instant
message -> summary
One can borrow the idea and extend it a little bit to support the
structured
Comments inline
> On Dec 24, 2019, at 2:09 AM, Volkan Yazıcı wrote:
>
> This is easier said than done. Customizing the schema and injected
> content is the raison d'être of LogstashLayout. Would you people
> accept a PR re-branding LogstashLayout as the new JsonLayout where the
> default JSON sc
Perhaps the ColumnMapping plugin from the database appenders could be
useful here?
On Tue, Dec 24, 2019 at 03:09 Volkan Yazıcı wrote:
> This is easier said than done. Customizing the schema and injected
> content is the raison d'être of LogstashLayout. Would you people
> accept a PR re-branding
This is easier said than done. Customizing the schema and injected
content is the raison d'être of LogstashLayout. Would you people
accept a PR re-branding LogstashLayout as the new JsonLayout where the
default JSON schema conforms with the JsonLayout of Log4j 2.0? This
would provide 100% backward-
> On Dec 23, 2019, at 7:50 PM, Gary Gregory wrote:
>
> On Mon, Dec 23, 2019 at 6:25 PM Ralph Goers
> wrote:
>
>> Thanks,
>>
>> What I was thinking was that I would just like a more flexible way to
>> specify what should be included in the JSON. In its current form the JSON
>> Layout just cre
On Mon, Dec 23, 2019 at 6:25 PM Ralph Goers
wrote:
> Thanks,
>
> What I was thinking was that I would just like a more flexible way to
> specify what should be included in the JSON. In its current form the JSON
> Layout just creates a serialized version of a LogEvent. I would prefer it
> if users
Thanks,
What I was thinking was that I would just like a more flexible way to specify
what should be included in the JSON. In its current form the JSON Layout just
creates a serialized version of a LogEvent. I would prefer it if users could
define the individual fields they want and what they
Hello,
As the author of log4j2-logstash-layout[1], I would like to share some
thoughts on the plugin and its implications on Log4j 3.0 roadmap.
- LogstashLayout is pretty stable in its feature set for the
last year. That is, the advantages (customization, etc.)
it offers over JsonLayout could
I have created the issue:
https://issues.apache.org/jira/browse/LOG4J2-2742
Feel free to offer comments on how I can improve it, however, I am quite
happy with the library Volkan Yazici surfaced as it fits perfectly with my
current needs.
Thank you,
David
On Sun, Dec 22, 2019 at 3:24 PM Ralph G
David,
Can you please create a Jira issue with this feature request in it? I am not
particularly happy with the JsonLayout at the moment as I think what it does is
too limited. I’d like there to be a lot more flexibility as to what the
resulting JSON should look like, not just dumping the log
Hello David,
Truncating JSON field values (incl. the stack trace) longer than a
certain threshold is supported by log4j2-logstash-layout[1] via
maxStringLength configuration.
Best.
[1] https://github.com/vy/log4j2-logstash-layout
On Sun, Dec 22, 2019 at 10:37 PM J. David Requejo wrote:
>
> Hel
Hello,
I'm a big fan of log4j2 and always recommend it in all my professional
projects.
Lately I have run into an issue while using the log4j2 Json Layout and I
would like to request/contribute a feature.
The gist is to allow the use of the exception pattern for the throwable by
adding it as a p
25 matches
Mail list logo
