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 overhead
is retrieving and formatting the data, especially the location information. I
wouldn’t think a “pattern” for JSON, XML or any other format would be much more
complicated, and could be very similar to, what we have implemented for the
pattern layout.
If I was implementing this I would just say users should specify the pattern
converters that they want (i.e. - the logger name, level, marker, etc) which
just return the data, and they use a specified format to generate the output. I
suspect this could even work for a binary format if that was desired.
Ralph
> On Dec 25, 2019, at 3:17 PM, Matt Sicker <boa...@gmail.com> wrote:
>
> 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ı <volkan.yaz...@gmail.com> wrote:
>
>> On Wed, Dec 25, 2019 at 7:38 AM Ralph Goers <ralph.go...@dslextreme.com>
>> 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 striking observation Ralph! (I think Carter Kozak is
>> pointing in the same direction in the thread.) Consider the following:
>> if we provide a fully-fledged template engine (e.g., Velocity,
>> FreeMarker, Thymeleaf, Pippo) with sufficient expressiveness (here
>> consider someone trying to emit epoch seconds in floating point format
>> from LogEvent#getInstant()) and escaping utilities (e.g.,
>> {Json,Sgml,Yaml}Helpers.escapeString()), users can render whatever
>> text-based output they want, be it XML, JSON, YAML, HTML, etc. If we
>> would look deep enough, all what LogstashLayout, PatternLayout, etc.
>> are trying to achieve is a short-sighted attempt to fill in this
>> template engine gap.
>>
>> Here is a thought experiment: Given a VelocityLayout with all its
>> whistles and bells (e.g., EscapeTool[1]), are there any text-based
>> layouts we know of that is not expressible by VelocityLayout? Further,
>> I expect VelocityLayout to outperform the existing individual
>> text-based layouts due to its template compilation. (You can repeat
>> the same experiment by replacing "Velocity" with your favorite Java
>> templating engine.)
>>
>> I am strongly in favor of moving towards this direction rather than
>> introducing ad-hoc layouts for each text-based format that Log4j needs
>> to emit.
>>
>> [Thanks for the rest of the comments Ralph. I skipped replying to them
>> on purpose to just focus on this significant observation.]
>>
>> [1]
>> http://velocity.apache.org/tools/devel/apidocs/org/apache/velocity/tools/generic/EscapeTool.html
>>
> --
> Matt Sicker <boa...@gmail.com>
