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 <cko...@ckozak.net> wrote:

> On Wed, Dec 25, 2019, at 01:38, Ralph Goers wrote:
> >
> >
> > > On Dec 24, 2019, at 2:06 PM, Volkan Yazıcı <volkan.yaz...@gmail.com>
> 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 can borrow the idea and extend it a little bit to support the
> > > structured form of a JSON:
> > >
> > > timestamp.millis -> instant
> > > throwable -> error.message
> > >
> > > That said, I believe current JSON-based templating in LogstashLayout
> > > communicates the intent more concisely (the template is WYSIWYG) and
> > > allows extra (JSON-specific) flexibility, e.g.,
> > >
> > > "user": ["${json:mdc:user}", "${json:mdc:fallbackUser}”]
> > >
> >
> > Looking at
> https://github.com/vy/log4j2-logstash-layout/blob/master/layout/src/main/resources/LogstashJsonEventLayoutV1.json
> <
> https://github.com/vy/log4j2-logstash-layout/blob/master/layout/src/main/resources/LogstashJsonEventLayoutV1.json>
> makes me think that you could accomplish the same thing with a few
> enhancements to the PatternLayout. In fact, all the expressions with
> ${json:…} look like they could be a LogEvent Lookup where you want the
> output to be formatted as JSON. I am not sure why you didn’t implement it
> that way.
> >
> > I could also see creating a new pattern converter to cause formatting to
> be in JSON so when any pattern converter is called it knows to output JSON.
> So %d would result in “timestamp”: “2019-12-25 01:02:03,123” etc. So a
> pattern of “%json{%d, %p, %c, %C, %M, %L, %m}” would generate
> “{“timestamp”: “2019-12-25 01:02:03,123”, “level”: “debug”, “logger”:
> “com.mycorp.MyClass”, “class”: “com.mycorp.MyClass”, “method”:
> “doSomething”: “lineNumber”: 123, “message”: “Hello, world!”}
> >
> > 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, so calling it JsonLogstashLayout seems a bit misleading. I could just
> as easily imagine an XML template with xml resolvers.
> >
> > 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 its data and left calling the jsonGenerator to the class
> that calls all the resolvers. Then you could have reused the same resolvers
> to generate XML. At least, that is the path I would have tried to go down.
> Obviously I have only glanced at your code so it could be more challenging
> than it appears.
> >
> > Anyway, those are just my first random thoughts after looking at what
> the layout does.
> >
> > Ralph
> >
>
> I've had a lot of success using pattern layout with the
> EncodingPatternConverter to escape json strings. The layout definition can
> be difficult to read, but it's incredibly powerful. For example:
>
> {"timestamp":"%d", "level":"%p", "origin":"%encode{%c}{JSON}",
> "thread":"%encode{%t}{JSON}", "message":%encode{m}{JSON}}%n
>
> There are a few pattern converters that don't map particularly well to
> this method, for example the MdcPatternConverter with multiple keys doesn't
> currently have a JSON formatting option. It would be great if we could make
> this functionality easier for users, likely through some combination of
> documentation and features. I've found it helpful that we don't require
> jackson for this approach to work.
>
> -ck
>
-- 
Matt Sicker <boa...@gmail.com>

Reply via email to