[
https://issues.apache.org/jira/browse/LOG4J2-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376124#comment-17376124
]
Ralph Goers commented on LOG4J2-3113:
-------------------------------------
Here is the text from the JEP. It makes it quite clear that the intended use of
System.Logger’s API is the JDK, not user apps. The JDK is not going to take
advantage of any features in Log4J since it’s default implementation is JUL.
For this reason I would be -1 for any attempt to try to make Log4J support this
UNLESS it can be handled at compile time. Adding any runtime checks would give
users a reason not to use it for JDK LOGGING.
{panel:title=My title}
*Summary*
Define a minimal logging API which platform classes can use to log messages,
together with a service interface for consumers of those messages. A library or
application can provide an implementation of this service in order to route
platform log messages to the logging framework of its choice. If no
implementation is provided then a default implementation based upon the
java.util.logging API is used.
Goals
Defined and used in the java.base module, hence it cannot depend upon the
java.util.logging API.
Be easily adoptable by applications which use external logging framework, such
as SLF4J or Log4J.
Reduce dependences on the java.logging module in order to simplify the JDK
module graph.
Deals with bootstrap issues, so that platform classes can log messages before
the log consumer is initialized.
By default, log messages via the java.util.logging API when the java.logging
module is present.
Non-Goals
It is not a goal to define a general-purpose interface for logging. The service
interface contains only the minimal set of methods that the JDK needs for its
own usage.
It is not a goal to support programmatic logging configuration (setting levels,
destination files, etc...) via the API.
It is not a goal to convert all classes in the JDK to log via this new API.
{panel}
> 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)
