On Sun, Jul 4, 2021 at 2:59 PM Volkan Yazıcı <volkan.yaz...@gmail.com> wrote:
> *[My answers are inline.]* > > On Thu, Jul 1, 2021 at 11:48 PM Raman Gupta <rocketra...@gmail.com> wrote: > > > > > https://issues.apache.org/jira/browse/LOG4J2-3116 > > https://github.com/apache/logging-log4j2/pull/543 > > > > Thanks! I will check these out momentarily. > > I'm having one issue with the tests, and replied to your comment in the pull. > > > One administrative note -- as I am a committer (although thus far I have > > only committed to the log4j2 kotlin repo) should I do dev="rgupta" > instead > > of adding myself in due-to? > > > > Of course! Apologies that I have totally missed it. > > Some technical notes -- some of the functionality could be more efficient > > with some changes to the resolvers, to avoid delegating so many of the > > fields to the pattern resolver. Specifically: > > > > 1) the level resolver could be enhanced with a label mapping function, > > > > PatternLayout enhances individual resolvers. For instance, %level directive > accepts a boolean lowerCase argument. In JsonTemplateLayout, I want to > follow a different approach and rather than enhancing individual resolvers, > I want to introduce reusable components. For instance, I have recently > introduced the CaseConverter resolver. One can combine this with > LevelResolver to have the same effect with %level{lowerCase} in > PatternLayout. Coming back to your remark about LevelResolver, similarly, > rather than enhancing LevelResolver, I want to introduce a > SubstitutionResolver, if you know what I mean. Nevertheless, please go > ahead and create a ticket addressing your "problem". I can comment further > there on how to approach it. > > I was wondering if I could combine resolvers, but I didn't see any documentation or examples showing that. Thanks for confirming that is your preferred approach to the problem. Issue for SubstitutionResolver: https://issues.apache.org/jira/browse/LOG4J2-3119 > > > 2) the message resolver could optionally output stack trace as well, and > > > > Again, similar to the aforementioned "reusable components" strategy, I was > thinking of creating a ConcatenationResolver. Would you mind creating a > ticket for this as well, please? > > https://issues.apache.org/jira/browse/LOG4J2-3120 > > > 3) a serial number resolver could be added. > > > > Do you mean as the one mentioned in LOG4J2-3067 > <https://issues.apache.org/jira/browse/LOG4J2-3067>? > > Yes > > > However, in my opinion we should commit the basic functionality first, > and > > deal with those sorts of optimizations later. > > > > Agreed! This said, let's create tickets for these feature requests so as > not to forget them. > Done, see above.
