Yeah, I have thought quite a bit about this and have never been able to come up with a solution that didn’t require modifications to Java. With the new withLocation method it should be possible to provide a null value that gets replaced with a constant that is generated by the annotation processor, but it seems many people like to disable annotation processing at compile time. It would also mean that users wouldn’t be debugging the “real” code but a modified copy.
Ralph > On Jun 23, 2019, at 1:50 AM, Matt Sicker <boa...@gmail.com> wrote: > > It certainly sounds interesting to me, though I say that about a lot of > things (which are all interesting though!). For Java, I’d imagine we’d need > to do something at the compiler level unless there’s enough information in > the bytecode to reconstruct the proper Java source location info. If only > Java had a macro for line numbers and other compile time info like C and > Python do. > >> On Sun, Jun 23, 2019 at 03:46, Remko Popma <remko.po...@gmail.com> wrote: >> >> 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 <boa...@gmail.com> 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 <ralph.go...@dslextreme.com> >>> wrote: >>> >>>> Yes. >>>> >>>> Ralph >>>> >>>>> On Jun 22, 2019, at 9:54 AM, Gary Gregory <garydgreg...@gmail.com> >>>> 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 <ralph.go...@dslextreme.com> >>>> 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 <boa...@gmail.com> >>> >> > -- > Matt Sicker <boa...@gmail.com>
