[
https://issues.apache.org/jira/browse/LOG4J2-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17374729#comment-17374729
]
Markus Spann commented on LOG4J2-3113:
--------------------------------------
{{System.Logger}} documentation (including the JEP) says nothing about how
Objects in the varargs signature should be treated.
It does not even say anything about the format of placeholders (whether curly
braces only, printf-style or curly braces with 1-based indices).
To illustrate further: say, we code against {{System.Logger}}, use curly braces
as required by {{log4j2}}, then {{log4j2}} is not present at run-time, the
logging implementation will default to {{JUL}} which does not understand that
wildcard style. Log entries won't have wildcards expanded.
{quote}What other API in the JDK allows you to pass a Supplier to a method that
accepts an Object and handles it as a Supplier?
{quote}
The class {{StringBuilderFormattable}} already gets special treatment in
{{log4j2}}:
{{log4j2}} calls {{formatTo}} not {{toString}} on objects of type
{{StringBuilderFormattable}}.
To support {{Supplier}} on a logging signature is a powerful and must-have
concept. The existing signature is suitable for simpler log statements:
{code:java}
java.lang.System.Logger.log(java.lang.System.Logger.Level,
java.util.function.Supplier<String>){code}
Expanding the concept to the varargs signature makes it so much more powerful.
Let's make it a feature of the log4j2 concrete logging implementation.
Obviously we must document that {{StringBuilderFormattable}} and {{Supplier}}
receive special treatment in the varargs signature and that {{log4j2}} calls
{{toString()}} on all other objects.
> Support Supplier<> in varargs log message parameters
> ----------------------------------------------------
>
> Key: LOG4J2-3113
> URL: https://issues.apache.org/jira/browse/LOG4J2-3113
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Affects Versions: 2.14.1
> Reporter: Markus Spann
> Priority: Minor
>
> It would be very useful, to give special treatment to message parameters of
> type {{java.util.function.Supplier<T>}} by calling {{get()}} rather than
> {{toString()}} on it while creating the log message.
> Message parameters (i.e. method calls that return the parameter) that are
> expensive to compute can thus be computed lazily.
> What's more, the logging call reads more naturally just like all other
> logging calls that use wildcards and parameters.
> {code:java}
> java.lang.System.Logger logger = System.getLogger("toto");
> // already supported style using a single Supplier
> logger.log(Level.DEBUG, () -> "Contents of array: " +
> Arrays.deepToString(array));{code}
> {code:java}
> // compiles but calls toString() rather than Supplier.get()
> logger.log(Level.DEBUG, "Contents of array: {}", (Supplier<String>) () ->
> Arrays.deepToString(array));{code}
> I've looked through the log4j2 Jira and found issue LOG4J2-599 in which a
> similar request was previously discussed without actually adding the feature
> to log4j2.
> (Note: Strangely Java requires the cast to (Supplier<String>).)
> My suggestion is to add Supplier support by enhancing method
> {{org.apache.logging.log4j.util.StringBuilders.appendSpecificTypes()}}.
> I will provide a Pull Request if you agree to the enhancement.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
