[
https://issues.apache.org/jira/browse/LOG4J2-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376389#comment-17376389
]
Markus Spann commented on LOG4J2-3113:
--------------------------------------
You read too much into the JEP, [~rgoers].
{quote}It makes it quite clear that the intended use of System.Logger’s API is
the JDK, not user apps.
{quote}
I don't really agree. {{System.Logger}} is public API. With the service
interface it offers, one can configure a 3rd party framework such as log4j2.
Neither the JEP nor Javadoc says its intention is firstly for JDK-usage. On the
contrary if you consider:
{quote}"Be easily adoptable by applications which use external logging
framework, such as SLF4J or Log4J."
{quote}
{{System.Logger}} is a true alternative to {{slf4j}}. The two APIs have
identical feature sets. Both can plug in concrete logging implementation,
although with different techniques.
The intention behind {{System.Logger}} might even be to offer an slf4j
replacement, although the JEP does not spell it out.
{{slf4j}} has been badly maintained (version 2 is in alpha state since 2
years). I am migrating all my applications away from it, and I am not the only
one doing so. I am happy to do without the additional dependency and make use
of new JDK features.
If we followed your argument, [~rgoers], log4j2 should not support
{{System.Logger}} at all, as it will always be incompatible to {{JUL}}.
Given that {{log4j2}} is my current choice of concrete logging implementation
(leaving {{logback}} behind which, too, has been completely stale), I take an
interest in improving the framework and make contributions.
Let's take a step back, I am suggesting that we call get() on Supplier not
toString(). Who in their right mind would be interested in logging
{{Supplier.toString()}} anyways?
This is all I have suggested, and I find this discussion is turning
increasingly hypothetical.
What do others think? [~ggregory], [~rpopma], [~mattsicker]?
It would be good to reach a conclusion how to proceed.
> 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)
