You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Ralph Goers (Jira)" <ji...@apache.org> on 2021/07/02 03:03:00 UTC

[jira] [Commented] (LOG4J2-3113) Support Supplier<> in varargs log message parameters

    [ https://issues.apache.org/jira/browse/LOG4J2-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17373162#comment-17373162 ] 

Ralph Goers commented on LOG4J2-3113:
-------------------------------------

Now you have me totally confused. You are making a call using System.Logger's interface. That interface doesn't accept Suppliers for the parameters, only for the message itself. So there is no way you can possibly pass in two Suppliers and have them end up calling something in the Log4j API that accepts Suppliers as parameters unless Log4jSystemLogger is modified to check the parameters at runtime using instanceof. But I don't think I would want to do that as you are now making System.Loggers API do something it wasn't designed to handle.

For some reason this whole time I was thinking you were saying there was a problem in the Log4j API. I can see in your original description that you did mention System.Logger but then you mentioned LOG4J2-599 which had nothing to do with System.Logger as it hadn't been implemented yet, much less the log4j-jpl module.

> 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)