It would be ideal if location information could be collected at compile time. It is constant and unchanging information after all and it seems silly to have to dynamically calculate this at runtime.
While Java doesn’t have compile time macros I was wondering if there’s anything else we can do. One potential option is using the annotation processing API to hook into the compiler AST tree (but requires annotations, so may not be the solution for us). Another option (perhaps a better one) is using a byte code manipulation library to inject location information. I haven’t looked into this in detail and I don’t know yet what (if any) API would be needed to support this. Would this be interesting to pursue? Remko. On Sun, Jun 23, 2019 at 6:15 Matt Sicker <[email protected]> wrote: > 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]> >
