While the first syntax is shorter, I actually like the second syntax better. It is clearer than all the stuff being tacked on after “json:” and it provides more room to be extended.
Ralph > On May 25, 2020, at 6:00 AM, Volkan Yazıcı <[email protected]> wrote: > > Hello, > > In JTL, we employ two templating languages within each other. Consider > the following GelfLayout.json: > > { > "version": "1.1", > "host": "${hostName}", > "short_message": "${json:message}", > "full_message": "${json:exception:stackTrace:text}", > "timestamp": "${json:timestamp:epoch:secs}", > "level": "${json:level:severity:code}", > "_logger": "${json:logger:name}", > "_thread": "${json:thread:name}", > "_mdc": "${json:mdc:flatten=_,stringify}" > } > > First, a JSON template denoting the will be emitted JSON structure. > Second, a key-value pair configuration language. See the > "${json:mdc:flatten=_,stringify}" directive? How one would parse > "flatten" parameter here? What if it contains double-quotes, commas, > etc. I have already implemented an ad-hoc StringParameterParser to > read such parameters. Though I am really hesitant to employ this > further for two main reasons: > > 1. Every custom parser is a fertile ground to injection attacks. > > 2. Its capabilities are limited: no types, no structural nesting, etc. > > For this purpose, I have been considering re-using the JSON also to > pass parameters to the resolvers and render the 2nd DSL redundant: > > { > "version": "1.1", > "host": "${hostName}", > "short_message": { > "$resolver": "message" > }, > "full_message": { > "$resolver": "exception", > "type": "stackTrace", > "output": "text" > }, > "timestamp": { > "$resolver": "timestamp", > "type": "epoch", > "unit": "secs" > }, > "level": { > "$resolver": "level", > "type": "severity", > "field": "code" > }, > "_logger": { > "$resolver": "logger", > "field": "name" > }, > "_thread": { > "$resolver": "thread", > "field": "name" > }, > "_mdc": { > "$resolver": "mdc", > "flatten": { > "prefix": "_" > }, > "stringify": true > } > } > > Due to existing users, I kept on postponing this idea in > LogstashLayout. Though I feel like this is a good time to bring it up > again. What do you think? > > Kind regards. >
