> 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
