That is a valid concern. Googl'ing bumped me into Rocker[1]. Its garbage generation appears to be tractable. For the rest (Velocity, FreeMarker, etc.), I am curious if we can create a memory pool to reuse contextual objects.
[1] https://github.com/fizzed/rocker On Wed, Dec 25, 2019 at 11: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>
