This looks a lot like Google Flogger[1], we may want to read through their design (if you haven't done so already) to see if there's anything clever they've done that we should take advantage of.
I'll take a look at the PR today. 1. https://github.com/google/flogger On Sun, Jun 23, 2019, at 05:49, Apache wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[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]> > >>> > >> > > -- > > Matt Sicker <[email protected]> > > >
