You can use the %maxLength{…}{N} pattern converter with PatternLayout at least.
Unfortunately, I don’t think any other layouts support a similar option.
> On Jan 25, 2024, at 10:55, Gary D. Gregory <ggreg...@apache.org> wrote:
>
> Hi All,
>
> I'd like to ask how to if we can devise advice around an issue I ran into
> this week.
>
> One of our test suites processes about 40K files of test fixtures. These
> inputs are parsed, processed, and asserted. This randomly fails on a call to
> Logger#debug(), randomly in that it happens usually once per build, somewhere
> in a logging call. But it usually fails with a call that looks like this:
>
> logger.debug("This is fun" + myFunObject);
>
> To simplify things, let's say that it turns out that after an underlying
> third party jar file version upgrade the call to myFunObject#toString() no
> longer returns Object#toString() but rather (again to simplify) the contents
> of the file that was parsed to create myFunObject. This toString() can be
> megabytes. The solution is obvious:
>
> logger.debug("This is fun", myFunObject::toString)
>
> And our CI builds no longer randomly fail since our default logging does not
> log at the debug level.
>
> A better solution could be:
>
> logger.debug("This is fun", () -> myFunObject.toString().substring(0, 100))
>
> where I still want _some_ information better than making my own toString()
> with System#identityHashCode(Object) or somesuch. Sure, .toString() is still
> called but it does not make it down into logging. In my case the OOME
> happened in myFunObject::toString so the substring() example would not have
> worked.
>
> My question is: Should we document some general advice on this pattern and
> what should the advice be? Would it make sense to have some features where we
> truncate/reject Strings above a threshold. And yes, calling
> myFunObject.toString() can still still get me in trouble.
>
> Gary
>
