This pattern might be useful for the Scala and Kotlin adapters since those languages have some form of compile time macros (or at least Scala does, as does Groovy). Though that could even fill in the location info directly rather than walking the call stack at runtime.
On Sat, Jun 22, 2019 at 12:24, Ralph Goers <[email protected]> wrote: > Yes. > > Ralph > > > On Jun 22, 2019, at 9:54 AM, Gary Gregory <[email protected]> > wrote: > > > > I would drop prefixes like "at" and "with". > > > > In you example, if debug logging is disabled, are the follow up calls > noops? > > > > Gary (AFK) > > > > On Sat, Jun 22, 2019, 11:58 Ralph Goers <[email protected]> > wrote: > > > >> Please review the PR for LOG4J2-2639 at > >> https://github.com/apache/logging-log4j2/pull/284 < > >> https://github.com/apache/logging-log4j2/pull/284>. This adds new > Logger > >> methods to allow a builder pattern to be used to accumulate the > parameters > >> to a logging call before logging the event. I got this idea from > messages > >> on the SLF4J list but I haven’t looked at that code at all so I have no > >> idea how Ceki implemented that. To be honest, the only reason I > implemented > >> this was because it allows the location information to be exposed and > >> calculated in a hopefully more efficient way. I haven’t run tests to > verify > >> that but the default way of calculating a location only requires > looking up > >> 2 levels in the call stack instead of dynamically searching for the > >> matching FQCN. > >> > >> I haven’t written the doc for this yet but a typical logging call might > >> look like: > >> > >> logger.atDebug().withLocation().withMessage(*Hello > >> {}”).withParameters(“Sam”).withMarker(myMarker).log(); > >> > >> This feature is only implemented on master as it takes advantage of > Java 8 > >> default methods to maintain backward compatibility. > >> > >> Ralph > > > -- Matt Sicker <[email protected]>
