I think this dates back to when Flogger was on a media blitz recently. I remember being contacted about it, and I’d assume several of you received a similar email. I imagine SLF4J added this API in response even though I thought we had considered a similar API in the past.
On Sun, Jun 23, 2019 at 10:43, Carter Kozak <[email protected]> wrote: > 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]> > > > > > > > -- Matt Sicker <[email protected]>
