[
https://issues.apache.org/jira/browse/LOG4J2-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679377#comment-14679377
]
Bruce Brouwer commented on LOG4J2-599:
--------------------------------------
I wonder how well that would work using generics like that. What gotchas will I
run into?
I have to say that I'm not entirely thrilled with introducing the whole Logger2
interface. The main argument against just adding it to Logger is that anything
that implements the Logger interface (particularly something that is not part
of the log4j project) will break BC. From a technical standpoint, this is true,
but from a practical standpoint, I don't think it is important.
I just made a little example project to prove this out, and things don't
actually break. If you add a method to the Logger api, implementors of the 2.3
version will not blow up once the 2.4 log4j-api is on the classpath. The only
thing that will blow up is if I call the new method and the implementor has not
yet implemented it. To me, that seems like a completely reasonable outcome.
Consider why I am using the log4j-api 2.4 without a log4j implementation. The
only real case I can think of is if if there is a bridge APIs that Log4j
doesn't cover. Perhaps a custom logging implementation that some company has.
If they did come across a library that required the new methods from log4j-api
version 2.4, it doesn't seem that unreasonable to require them to update their
custom bridge. And if nothing actually used those new methods, nothing will
blow up, which I believe is by far the most likely situation.
Other API libraries deal with this exact same issue. For example, JPA when it
went from 2.0 to 2.1 added new API methods to the CriteriaBuilder. They weren't
forced to version 3.0 simply because they added a new method to an API.
And furthermore, I don't like where this will ultimately lead us to. So we know
today what we're talking about adding to Logger2, but what about for version
2.5 when there is more stuff we want to add. Do we make Logger3 so that we
don't break the BC for Logger2? and then Logger4? That seems ridiculous to me.
I would much rather see a few new methods added to the main Logger API.
> Support lambda functions (or similar) for log message parameters
> ----------------------------------------------------------------
>
> Key: LOG4J2-599
> URL: https://issues.apache.org/jira/browse/LOG4J2-599
> Project: Log4j 2
> Issue Type: Brainstorming
> Components: Core
> Reporter: Matt Sicker
> Assignee: Remko Popma
> Priority: Minor
> Labels: Java8
> Fix For: 2.4
>
>
> It would be nice if we could support 0-param lambda functions (or the
> equivalent: interfaces with a single empty-parameter message call), or more
> simply, allow Runnables (or something similar) to be passed which will be
> dynamically executed if the log message is enabled.
> The use case here is that although string construction of the log message is
> a performance issue that is already solved quite well, the problem of adding
> in information to the log message that makes other calculations still needs
> to be wrapped in an if check.
> I'm not sure if it'd be best to just use Runnable, or create a new interface,
> or try to emulate how Java 1.8 lambdas work via an interface with a single
> method defined. The details here would still need to be fleshed out, but I
> think this sort of feature could be rather handy (especially in a Java 1.8+
> environment, or in Groovy/Scala/etc.).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
