You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Ralph Goers <ra...@dslextreme.com> on 2019/06/22 15:58:21 UTC
PR for LOG4J2-2639
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
Re: PR for LOG4J2-2639
Posted by Matt Sicker <bo...@gmail.com>.
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 <ck...@ckozak.net> 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 <bo...@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 <re...@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 <bo...@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.goers@dslextreme.com>
> > >>> wrote:
> > >>>
> > >>>> Yes.
> > >>>>
> > >>>> Ralph
> > >>>>
> > >>>>> On Jun 22, 2019, at 9:54 AM, Gary Gregory <ga...@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.goers@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 <bo...@gmail.com>
> > >>>
> > >>
> > > --
> > > Matt Sicker <bo...@gmail.com>
> >
> >
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: PR for LOG4J2-2639
Posted by Carter Kozak <ck...@ckozak.net>.
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 <bo...@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 <re...@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 <bo...@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 <ra...@dslextreme.com>
> >>> wrote:
> >>>
> >>>> Yes.
> >>>>
> >>>> Ralph
> >>>>
> >>>>> On Jun 22, 2019, at 9:54 AM, Gary Gregory <ga...@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 <ra...@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 <bo...@gmail.com>
> >>>
> >>
> > --
> > Matt Sicker <bo...@gmail.com>
>
>
>
Re: PR for LOG4J2-2639
Posted by Apache <ra...@dslextreme.com>.
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 <bo...@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 <re...@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 <bo...@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 <ra...@dslextreme.com>
>>> wrote:
>>>
>>>> Yes.
>>>>
>>>> Ralph
>>>>
>>>>> On Jun 22, 2019, at 9:54 AM, Gary Gregory <ga...@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 <ra...@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 <bo...@gmail.com>
>>>
>>
> --
> Matt Sicker <bo...@gmail.com>
Re: PR for LOG4J2-2639
Posted by Matt Sicker <bo...@gmail.com>.
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 <re...@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 <bo...@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 <ra...@dslextreme.com>
> > wrote:
> >
> > > Yes.
> > >
> > > Ralph
> > >
> > > > On Jun 22, 2019, at 9:54 AM, Gary Gregory <ga...@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 <ra...@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 <bo...@gmail.com>
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: PR for LOG4J2-2639
Posted by Remko Popma <re...@gmail.com>.
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 <bo...@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 <ra...@dslextreme.com>
> wrote:
>
> > Yes.
> >
> > Ralph
> >
> > > On Jun 22, 2019, at 9:54 AM, Gary Gregory <ga...@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 <ra...@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 <bo...@gmail.com>
>
Re: PR for LOG4J2-2639
Posted by Matt Sicker <bo...@gmail.com>.
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 <ra...@dslextreme.com>
wrote:
> Yes.
>
> Ralph
>
> > On Jun 22, 2019, at 9:54 AM, Gary Gregory <ga...@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 <ra...@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 <bo...@gmail.com>
Re: PR for LOG4J2-2639
Posted by Ralph Goers <ra...@dslextreme.com>.
Yes.
Ralph
> On Jun 22, 2019, at 9:54 AM, Gary Gregory <ga...@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 <ra...@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
Re: PR for LOG4J2-2639
Posted by Gary Gregory <ga...@gmail.com>.
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 <ra...@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