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

Reply via email to