You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Jeffrey Shaw <sh...@gmail.com> on 2018/02/24 02:02:07 UTC
Re: [log4j] providing sourcewith Message
Hi All,
I spent some more time on this tonight. I've brought my code up to date for
log4j versions 2 and 3. version 2
<https://github.com/shawjef3/logging-log4j2/tree/message-location-release-2.x>
version
3 <https://github.com/shawjef3/logging-log4j2/tree/message-location>
Per Ralph Goers and some others I removed SourceLocation and reverted back
to StackTraceElement.
In case this thread is lost in your email, the changes I worked on expose
the location part of the Message to loggers, so that if the source location
is known at compile time, it can be added to the log with no runtime cost.
An example use is the scala loggers
<https://github.com/shawjef3/logging-log4j-scala> which are implemented
with macros, and therefore have that information available at no cost to
the developer, either.
On Sat, Dec 23, 2017 at 2:14 PM, Mikael Ståldal <mi...@apache.org> wrote:
> Yes, StackTraceElement does not allow null methodName.
>
> But what about using the empty string, or a string like "<unknown>" if it
> is not possible to get?
>
>
> On 2017-12-22 20:26, Jeffrey Shaw wrote:
>
>> I didn't know about clirr, but I can try running that. I tried to not
>> break
>> any existing public methods.
>>
>> I created SourceLocation because I think for Scala macros, the method name
>> can not exist, but StackTraceElement requires a method name. I'll double
>> check this.
>>
>> On Thu, Dec 21, 2017 at 12:40 AM, Ralph Goers <ralph.goers@dslextreme.com
>> >
>> wrote:
>>
>> I’m not sure I would be comfortable applying the patch this way. Have you
>>> run a clirr report on your changes? I am concerned that this could break
>>> customizations that users might have made. What is the reason
>>> SourceLocation had to be used instead of StackTraceElement?
>>>
>>> Ralph
>>>
>>> On Dec 20, 2017, at 9:58 PM, Jeffrey Shaw <sh...@gmail.com> wrote:
>>>>
>>>> It looks like the location only ever gets the file name, because that's
>>>> what StackTraceElement gives. So that's fine.
>>>>
>>>> I think I'm ready for a formal review. Should I create pull requests on
>>>> github for https://github.com/shawjef3/logging-log4j2/tree/message-
>>>>
>>> location
>>>
>>>> and https://github.com/shawjef3/logging-log4j-scala/tree/
>>>>
>>> message-location,
>>>
>>>> or is there another process?
>>>>
>>>>
>>>> On Wed, Dec 20, 2017 at 2:11 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> I think that should be configurable in the layout options.
>>>>>
>>>>> On 20 December 2017 at 13:04, Dominik Psenner <dp...@gmail.com>
>>>>>
>>>> wrote:
>>>
>>>>
>>>>> Could a compile time environment variable like SrcRootDirectory do the
>>>>>>
>>>>> job?
>>>>>
>>>>>>
>>>>>> On 20 Dec 2017 7:49 p.m., "Jeffrey Shaw" <sh...@gmail.com> wrote:
>>>>>>
>>>>>> I got it working using a custom ExtendedLogger instead of mocking.
>>>>>>>
>>>>>>> It looks like for file name, there are only two options. We can have
>>>>>>>
>>>>>> the
>>>>>
>>>>>> file name, or the full path to the file. The path relative to the
>>>>>>>
>>>>>> project
>>>>>
>>>>>> root looks impossible to get, unless we look for magic names like
>>>>>>>
>>>>>> "src".
>>>>>
>>>>>> Any opinion as to which to use? I'm tempted to use just the file name,
>>>>>>> since the full path to the file seems intrusive, and is dependent on
>>>>>>>
>>>>>> the
>>>>>
>>>>>> build machine.
>>>>>>>
>>>>>>> On Wed, Dec 20, 2017 at 11:35 AM, Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>> wrote:
>>>>>
>>>>>>
>>>>>>> It's possible that macros and mocks don't work well together, though
>>>>>>>>
>>>>>>> that's
>>>>>>>
>>>>>>>> just a guess.
>>>>>>>>
>>>>>>>> On 20 December 2017 at 00:00, Jeff Shaw <sh...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> I should add that manually testing it works.
>>>>>>>>>
>>>>>>>>> Sent from my phone
>>>>>>>>>
>>>>>>>>> On Dec 20, 2017, at 12:45 AM, Jeffrey Shaw <sh...@gmail.com>
>>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>>> I added some tests for traced, but they don't pass. The mocks
>>>>>>>>>>
>>>>>>>>> say,
>>>>>
>>>>>> "Actually, there were zero interactions with this mock." I could
>>>>>>>>>
>>>>>>>> use
>>>>>
>>>>>> some
>>>>>>>
>>>>>>>> help getting these two tests to work.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://github.com/shawjef3/logging-log4j-scala/blob/
>>>>>>>>>>
>>>>>>>>> message-location/log4j-api-scala_2.12/src/test/scala/org/
>>>>>>>>> apache/logging/log4j/scala/LoggerTest.scala#L574
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sun, Dec 17, 2017 at 8:50 PM, Jeffrey Shaw <
>>>>>>>>>>>
>>>>>>>>>> shawjef3@gmail.com
>>>>>
>>>>>>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Thanks for the encouragement everyone! I never worked on an
>>>>>>>>>>>
>>>>>>>>>> Apache
>>>>>
>>>>>> project before and had no idea what to expect from the community.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> I've made some progress. One cool thing I added was a `traced`
>>>>>>>>>>>
>>>>>>>>>> method
>>>>>>>
>>>>>>>> (source), which does the work you'd want for traceEntry, traceExit,
>>>>>>>>>
>>>>>>>> and
>>>>>>
>>>>>>> throwing. It would be cool to add catching as well, but that would
>>>>>>>>>
>>>>>>>> require
>>>>>>>>
>>>>>>>>> tree traversal, which is beyond me at the moment. I also haven't
>>>>>>>>>
>>>>>>>> figured
>>>>>>>
>>>>>>>> out how to add the parameter lists. Anyway, an example:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> before:
>>>>>>>>>>> def f() = {...}
>>>>>>>>>>>
>>>>>>>>>>> after:
>>>>>>>>>>> def f() = logger.traced(Level.INFO) {...}
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Dec 11, 2017 at 9:55 PM, Matt Sicker <boards@gmail.com
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>> From the little I've worked with macros (worked more with
>>>>>>>>>>>>
>>>>>>>>>>> scalameta
>>>>>>
>>>>>>> and
>>>>>>>>
>>>>>>>>> shapeless), that looks good so far. If you can add some unit
>>>>>>>>>>>>
>>>>>>>>>>> tests,
>>>>>>
>>>>>>> then
>>>>>>>>>
>>>>>>>>>> we'd be happy to merge!
>>>>>>>>>>>>
>>>>>>>>>>>> On 11 December 2017 at 20:41, Jeffrey Shaw <shawjef3@gmail.com
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> Great news! I'm able to run LoggingApp in the scala api repo
>>>>>>>>>>>>>
>>>>>>>>>>>> without
>>>>>>>>
>>>>>>>>> it
>>>>>>>>>
>>>>>>>>>> calling StackLocatorUtil.calcLocation, but it prints the same
>>>>>>>>>>>>>
>>>>>>>>>>>> messages as
>>>>>>>>>
>>>>>>>>>> before. I have to use my patch to log4j of course.
>>>>>>>>>>>>>
>>>>>>>>>>>>> See https://github.com/shawjef3/logging-log4j-scala/commits/
>>>>>>>>>>>>> message-location
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Dec 10, 2017 at 3:56 PM, Matt Sicker <
>>>>>>>>>>>>>
>>>>>>>>>>>> boards@gmail.com
>>>>>
>>>>>>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> This sounds like it'd make a great addition to the Scala
>>>>>>>>>>>>>>
>>>>>>>>>>>>> API!
>>>>>
>>>>>>
>>>>>>>>>>>>>> On 9 December 2017 at 15:36, Jeffrey Shaw <
>>>>>>>>>>>>>>
>>>>>>>>>>>>> shawjef3@gmail.com>
>>>>>>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> Ralph, I agree with you entirely. My intent for these new
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> log
>>>>>>
>>>>>>> methods
>>>>>>>>>
>>>>>>>>>> is
>>>>>>>>>>>>>
>>>>>>>>>>>>>> that they only be called from compile-time generated
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> code.
>>>>>
>>>>>>
>>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 4:30 PM, Ralph Goers <
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ralph.goers@dslextreme.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don’t understand how this is a good idea. To use this
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> you
>>>>>>
>>>>>>> would
>>>>>>>>>
>>>>>>>>>> need
>>>>>>>>>>>>>
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> do something like:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Message msg = new StringMessage(getCaller(), “My
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Message”);
>>>>>>
>>>>>>> logger.debug(msg);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Unfortunately the line number would point to the line
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> where
>>>>>>
>>>>>>> getCaller()
>>>>>>>>>>>>>
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> called not to the logger statement.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I had thought about modifying AbstractLogger to do
>>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> message)
>>>>>>>
>>>>>>>> {
>>>>>>>>
>>>>>>>>> logIfEnabled(getCaller(), Level.DEBUG, marker,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> message,
>>>>>>
>>>>>>> (Throwable)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> null);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>> instead of the current
>>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> message)
>>>>>>>
>>>>>>>> {
>>>>>>>>
>>>>>>>>> logIfEnabled(FQCN, Level.DEBUG, marker, message,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (Throwable)
>>>>>>>>>
>>>>>>>>>> null);
>>>>>>>>>>>>>
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>> But the amount of changes required to get it into the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> LogEvent
>>>>>>>>
>>>>>>>>> was
>>>>>>>>>
>>>>>>>>>> large.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> OTOH, if we create a CallerLocationMessage that
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> contains
>>>>>
>>>>>> the
>>>>>>>
>>>>>>>> StackTraceElement and then have existing Messages
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> extend
>>>>>
>>>>>> that
>>>>>>>
>>>>>>>> then we
>>>>>>>>>
>>>>>>>>>> could
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> store the location in the Message if it is a
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> CallerLocationMessage.
>>>>>>>>>
>>>>>>>>>> Calling
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> getCaller() in this way would be much better since it
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is
>>>>>
>>>>>> at a
>>>>>>>
>>>>>>>> fixed
>>>>>>>>>
>>>>>>>>>> depth
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> from the caller.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> With Java 9 this could become:
>>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> message)
>>>>>>>
>>>>>>>> {
>>>>>>>>
>>>>>>>>> logIfEnabled(stackWalker.walk(
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> s->s.skip(1).findFirst(),
>>>>>>>
>>>>>>>> Level.DEBUG,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> marker, message, (Throwable) null);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>> although that would pass a StackFrame instead of a
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> StackTraceElement.
>>>>>>>>>
>>>>>>>>>> The
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> only problems with this is that there is still some
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> overhead
>>>>>>>
>>>>>>>> in
>>>>>>>>
>>>>>>>>> calling
>>>>>>>>>>>>>
>>>>>>>>>>>>>> StackWalker like this. Also, if this is called from a
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> facade,
>>>>>>>
>>>>>>>> such as
>>>>>>>>>
>>>>>>>>>> log4j-slf4j-impl then the number of levels that have to
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> be
>>>>>>
>>>>>>> skipped
>>>>>>>>>
>>>>>>>>>> would
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> different.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I would really prefer if there was some way to capture
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> the
>>>>>>
>>>>>>> line
>>>>>>>>
>>>>>>>>> number
>>>>>>>>>>>>>
>>>>>>>>>>>>>> information for the various loggers when the annotation
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> processor
>>>>>>>>>
>>>>>>>>>> runs
>>>>>>>>>>>>>
>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> compile time.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Dec 9, 2017, at 1:22 PM, Jeffrey Shaw <
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> shawjef3@gmail.com
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks for the link, Mikael. I'll take a look at it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I added some plumbing to core to allow clients to
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> pass
>>>>>
>>>>>> a
>>>>>>
>>>>>>> StackTraceElement
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> to loggers. I'd like a code review. I'm happy to try
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> other
>>>>>>>
>>>>>>>> methods.
>>>>>>>>>
>>>>>>>>>> See
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> following commit.
>>>>>>>>>>>>>>>>> https://github.com/shawjef3/logging-log4j2/commit/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 9c42073e9ca4f25a2f4075b1791eee2893534c54
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 10:09 AM, Mikael Ståldal <
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> mikes@apache.org>
>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Have you tried the Log4j Scala API?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://logging.apache.org/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> log4j/2.x/manual/scala-api.
>>>>>
>>>>>> html
>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>>>> It does currently not support this, but it uses
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Scala
>>>>>
>>>>>> macros, and
>>>>>>>>>
>>>>>>>>>> this
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> could be added there. But log4j-api and/or
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> log4j-core
>>>>>
>>>>>> probably
>>>>>>>>>
>>>>>>>>>> needs
>>>>>>>>>>>>>
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> adapted as well.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 2017-12-09 07:30, Jeffrey Shaw wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>> I've found that I am able to use Scala macros to
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> provide
>>>>>>>
>>>>>>>> compile-time
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> source information for log messages. However, I
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> don't
>>>>>
>>>>>> see
>>>>>>>
>>>>>>>> a way
>>>>>>>>>
>>>>>>>>>> to
>>>>>>>>>>>>>
>>>>>>>>>>>>>> inject
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> this into log4j's logging mechanism.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'm wondering if there is something I'm missing, or
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> if
>>>>>>
>>>>>>> LogEvent's
>>>>>>>>>
>>>>>>>>>> getSource
>>>>>>>>>>>>>>>>>>> method could be duplicated in Message.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> We could then have zero-overhead location
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> information
>>>>>
>>>>>> in
>>>>>>>
>>>>>>>> logs.
>>>>>>>>>
>>>>>>>>>> I'm
>>>>>>>>>>>>>
>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>>>>>>> that tools other than Scala could also take
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> advantage
>>>>>
>>>>>> of
>>>>>>>
>>>>>>>> this.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>
Re: [log4j] providing sourcewith Message
Posted by Jeffrey Shaw <sh...@gmail.com>.
Looking to get some eyes on
https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-2360
On Wed, Jun 27, 2018 at 11:02 PM, Jeffrey Shaw <sh...@gmail.com> wrote:
> I created a JIRA ticket for this. https://issues.apache.org/
> jira/browse/LOG4J2-2360
>
> On Thu, Mar 15, 2018 at 11:37 PM, Jeff Shaw <sh...@gmail.com> wrote:
>
>> Thanks, Remko. There is no ticket that I know of. This is something I was
>> inspired to work on before I gave any thought to a formal process.
>>
>> Sent from my phone
>>
>> > On Mar 15, 2018, at 11:26 PM, Remko Popma <re...@gmail.com>
>> wrote:
>> >
>> > I am interested and planning to take a look if others don’t beat me to
>> it. Is there a corresponding JIRA ticket?
>> >
>> > (Shameless plug) Every java main() method deserves http://picocli.info
>> >
>> >> On Mar 16, 2018, at 5:33, Jeffrey Shaw <sh...@gmail.com> wrote:
>> >>
>> >> Hi, just hoping to get some eyes on this again.
>> >>
>> >>> On Fri, Feb 23, 2018 at 10:43 PM, Jeffrey Shaw <sh...@gmail.com>
>> wrote:
>> >>>
>> >>> closed that one and opened a new one with the commits squashed
>> >>> https://github.com/apache/logging-log4j2/pull/152
>> >>>
>> >>>> On Fri, Feb 23, 2018 at 10:11 PM, Jeffrey Shaw <sh...@gmail.com>
>> wrote:
>> >>>>
>> >>>> done! https://github.com/apache/logging-log4j2/pull/151
>> >>>>
>> >>>> On Fri, Feb 23, 2018 at 9:22 PM, Gary Gregory <
>> garydgregory@gmail.com>
>> >>>> wrote:
>> >>>>
>> >>>>> On Fri, Feb 23, 2018 at 7:02 PM, Jeffrey Shaw <sh...@gmail.com>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Hi All,
>> >>>>>> I spent some more time on this tonight. I've brought my code up to
>> >>>>> date for
>> >>>>>> log4j versions 2 and 3. version 2
>> >>>>>> <https://github.com/shawjef3/logging-log4j2/tree/message-
>> >>>>>> location-release-2.x>
>> >>>>>> version
>> >>>>>> 3 <https://github.com/shawjef3/logging-log4j2/tree/message-loc
>> ation>
>> >>>>>> Per Ralph Goers and some others I removed SourceLocation and
>> reverted
>> >>>>> back
>> >>>>>> to StackTraceElement.
>> >>>>>>
>> >>>>>
>> >>>>> Hello,
>> >>>>>
>> >>>>> Can you create pull requests so we can see better what you are
>> proposing?
>> >>>>>
>> >>>>> Thank you!
>> >>>>> Gary
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>>
>> >>>>>> In case this thread is lost in your email, the changes I worked on
>> >>>>> expose
>> >>>>>> the location part of the Message to loggers, so that if the source
>> >>>>> location
>> >>>>>> is known at compile time, it can be added to the log with no
>> runtime
>> >>>>> cost.
>> >>>>>> An example use is the scala loggers
>> >>>>>> <https://github.com/shawjef3/logging-log4j-scala> which are
>> >>>>> implemented
>> >>>>>> with macros, and therefore have that information available at no
>> cost
>> >>>>> to
>> >>>>>> the developer, either.
>> >>>>>>
>> >>>>>> On Sat, Dec 23, 2017 at 2:14 PM, Mikael Ståldal <mi...@apache.org>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>>> Yes, StackTraceElement does not allow null methodName.
>> >>>>>>>
>> >>>>>>> But what about using the empty string, or a string like
>> "<unknown>"
>> >>>>> if it
>> >>>>>>> is not possible to get?
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> On 2017-12-22 20:26, Jeffrey Shaw wrote:
>> >>>>>>>>
>> >>>>>>>> I didn't know about clirr, but I can try running that. I tried to
>> >>>>> not
>> >>>>>>>> break
>> >>>>>>>> any existing public methods.
>> >>>>>>>>
>> >>>>>>>> I created SourceLocation because I think for Scala macros, the
>> >>>>> method
>> >>>>>> name
>> >>>>>>>> can not exist, but StackTraceElement requires a method name. I'll
>> >>>>> double
>> >>>>>>>> check this.
>> >>>>>>>>
>> >>>>>>>> On Thu, Dec 21, 2017 at 12:40 AM, Ralph Goers <
>> >>>>>> ralph.goers@dslextreme.com
>> >>>>>>>>>
>> >>>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>> I’m not sure I would be comfortable applying the patch this way.
>> >>>>> Have
>> >>>>>> you
>> >>>>>>>>> run a clirr report on your changes? I am concerned that this
>> could
>> >>>>>> break
>> >>>>>>>>> customizations that users might have made. What is the reason
>> >>>>>>>>> SourceLocation had to be used instead of StackTraceElement?
>> >>>>>>>>>
>> >>>>>>>>> Ralph
>> >>>>>>>>>
>> >>>>>>>>> On Dec 20, 2017, at 9:58 PM, Jeffrey Shaw <sh...@gmail.com>
>> >>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> It looks like the location only ever gets the file name,
>> because
>> >>>>>> that's
>> >>>>>>>>>> what StackTraceElement gives. So that's fine.
>> >>>>>>>>>>
>> >>>>>>>>>> I think I'm ready for a formal review. Should I create pull
>> >>>>> requests
>> >>>>>> on
>> >>>>>>>>>> github for https://github.com/shawjef3/lo
>> >>>>> gging-log4j2/tree/message-
>> >>>>>>>>>>
>> >>>>>>>>> location
>> >>>>>>>>>
>> >>>>>>>>>> and https://github.com/shawjef3/logging-log4j-scala/tree/
>> >>>>>>>>>>
>> >>>>>>>>> message-location,
>> >>>>>>>>>
>> >>>>>>>>>> or is there another process?
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> On Wed, Dec 20, 2017 at 2:11 PM, Matt Sicker <boards@gmail.com
>> >
>> >>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> I think that should be configurable in the layout options.
>> >>>>>>>>>>>
>> >>>>>>>>>>> On 20 December 2017 at 13:04, Dominik Psenner <
>> >>>>> dpsenner@gmail.com>
>> >>>>>>>>>>>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>> Could a compile time environment variable like
>> SrcRootDirectory
>> >>>>> do
>> >>>>>> the
>> >>>>>>>>>>>>
>> >>>>>>>>>>> job?
>> >>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> On 20 Dec 2017 7:49 p.m., "Jeffrey Shaw" <shawjef3@gmail.com
>> >
>> >>>>>> wrote:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I got it working using a custom ExtendedLogger instead of
>> >>>>> mocking.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> It looks like for file name, there are only two options. We
>> can
>> >>>>>> have
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>> the
>> >>>>>>>>>>>
>> >>>>>>>>>>>> file name, or the full path to the file. The path relative to
>> >>>>> the
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>> project
>> >>>>>>>>>>>
>> >>>>>>>>>>>> root looks impossible to get, unless we look for magic names
>> >>>>> like
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>> "src".
>> >>>>>>>>>>>
>> >>>>>>>>>>>> Any opinion as to which to use? I'm tempted to use just the
>> file
>> >>>>>> name,
>> >>>>>>>>>>>>> since the full path to the file seems intrusive, and is
>> >>>>> dependent
>> >>>>>> on
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>> the
>> >>>>>>>>>>>
>> >>>>>>>>>>>> build machine.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> On Wed, Dec 20, 2017 at 11:35 AM, Matt Sicker <
>> >>>>> boards@gmail.com>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> It's possible that macros and mocks don't work well
>> together,
>> >>>>>> though
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>> that's
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> just a guess.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> On 20 December 2017 at 00:00, Jeff Shaw <
>> shawjef3@gmail.com>
>> >>>>>> wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> I should add that manually testing it works.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Sent from my phone
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> On Dec 20, 2017, at 12:45 AM, Jeffrey Shaw <
>> >>>>> shawjef3@gmail.com>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> I added some tests for traced, but they don't pass. The
>> >>>>> mocks
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> say,
>> >>>>>>>>>>>
>> >>>>>>>>>>>> "Actually, there were zero interactions with this mock." I
>> could
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> use
>> >>>>>>>>>>>
>> >>>>>>>>>>>> some
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> help getting these two tests to work.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> https://github.com/shawjef3/logging-log4j-scala/blob/
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> message-location/log4j-api-scala_2.12/src/test/scala/org/
>> >>>>>>>>>>>>>>> apache/logging/log4j/scala/LoggerTest.scala#L574
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> On Sun, Dec 17, 2017 at 8:50 PM, Jeffrey Shaw <
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> shawjef3@gmail.com
>> >>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Thanks for the encouragement everyone! I never worked on
>> an
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Apache
>> >>>>>>>>>>>
>> >>>>>>>>>>>> project before and had no idea what to expect from the
>> >>>>> community.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> I've made some progress. One cool thing I added was a
>> >>>>> `traced`
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> method
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> (source), which does the work you'd want for traceEntry,
>> >>>>>> traceExit,
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> and
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> throwing. It would be cool to add catching as well, but that
>> >>>>> would
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> require
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> tree traversal, which is beyond me at the moment. I also
>> >>>>> haven't
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> figured
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> out how to add the parameter lists. Anyway, an example:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> before:
>> >>>>>>>>>>>>>>>>> def f() = {...}
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> after:
>> >>>>>>>>>>>>>>>>> def f() = logger.traced(Level.INFO) {...}
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> On Mon, Dec 11, 2017 at 9:55 PM, Matt Sicker <
>> >>>>> boards@gmail.com
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> From the little I've worked with macros (worked more with
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> scalameta
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> shapeless), that looks good so far. If you can add some
>> unit
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> tests,
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> then
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> we'd be happy to merge!
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> On 11 December 2017 at 20:41, Jeffrey Shaw <
>> >>>>>> shawjef3@gmail.com
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> Great news! I'm able to run LoggingApp in the scala api
>> >>>>> repo
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> without
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> it
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> calling StackLocatorUtil.calcLocation, but it prints the
>> >>>>> same
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> messages as
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> before. I have to use my patch to log4j of course.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> See https://github.com/shawjef3/lo
>> >>>>> gging-log4j-scala/commits/
>> >>>>>>>>>>>>>>>>>>> message-location
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> On Sun, Dec 10, 2017 at 3:56 PM, Matt Sicker <
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> boards@gmail.com
>> >>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> This sounds like it'd make a great addition to the
>> Scala
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> API!
>> >>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> On 9 December 2017 at 15:36, Jeffrey Shaw <
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> shawjef3@gmail.com>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> Ralph, I agree with you entirely. My intent for these
>> >>>>> new
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> log
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> methods
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> is
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> that they only be called from compile-time generated
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> code.
>> >>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 4:30 PM, Ralph Goers <
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> ralph.goers@dslextreme.com>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> I don’t understand how this is a good idea. To use
>> this
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> you
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> would
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> need
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> do something like:
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> Message msg = new StringMessage(getCaller(), “My
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> Message”);
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> logger.debug(msg);
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> Unfortunately the line number would point to the
>> line
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> where
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> getCaller()
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> is
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> called not to the logger statement.
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> I had thought about modifying AbstractLogger to do
>> >>>>>>>>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> message)
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> {
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> logIfEnabled(getCaller(), Level.DEBUG, marker,
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> message,
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> (Throwable)
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> null);
>> >>>>>>>>>>>>>>>>>>>>>> }
>> >>>>>>>>>>>>>>>>>>>>>> instead of the current
>> >>>>>>>>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> message)
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> {
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> logIfEnabled(FQCN, Level.DEBUG, marker, message,
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> (Throwable)
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> null);
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> }
>> >>>>>>>>>>>>>>>>>>>>>> But the amount of changes required to get it into
>> the
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> LogEvent
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> was
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> large.
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> OTOH, if we create a CallerLocationMessage that
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> contains
>> >>>>>>>>>>>
>> >>>>>>>>>>>> the
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> StackTraceElement and then have existing Messages
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> extend
>> >>>>>>>>>>>
>> >>>>>>>>>>>> that
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> then we
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> could
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> store the location in the Message if it is a
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> CallerLocationMessage.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Calling
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> getCaller() in this way would be much better since
>> it
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> is
>> >>>>>>>>>>>
>> >>>>>>>>>>>> at a
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> fixed
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> depth
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> from the caller.
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> With Java 9 this could become:
>> >>>>>>>>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> message)
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> {
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> logIfEnabled(stackWalker.walk(
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> s->s.skip(1).findFirst(),
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Level.DEBUG,
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> marker, message, (Throwable) null);
>> >>>>>>>>>>>>>>>>>>>>>> }
>> >>>>>>>>>>>>>>>>>>>>>> although that would pass a StackFrame instead of a
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> StackTraceElement.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> The
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> only problems with this is that there is still some
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> overhead
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> in
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> calling
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> StackWalker like this. Also, if this is called from a
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> facade,
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> such as
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> log4j-slf4j-impl then the number of levels that have to
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> be
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> skipped
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> would
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> be
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> different.
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> I would really prefer if there was some way to
>> capture
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> line
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> number
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> information for the various loggers when the
>> annotation
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> processor
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> runs
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> at
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> compile time.
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> Ralph
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> On Dec 9, 2017, at 1:22 PM, Jeffrey Shaw <
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> shawjef3@gmail.com
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Thanks for the link, Mikael. I'll take a look at
>> it.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> I added some plumbing to core to allow clients to
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> pass
>> >>>>>>>>>>>
>> >>>>>>>>>>>> a
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> StackTraceElement
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> to loggers. I'd like a code review. I'm happy to
>> try
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> other
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> methods.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> See
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> following commit.
>> >>>>>>>>>>>>>>>>>>>>>>> https://github.com/shawjef3/lo
>> gging-log4j2/commit/
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> 9c42073e9ca4f25a2f4075b1791eee2893534c54
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 10:09 AM, Mikael Ståldal <
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> mikes@apache.org>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Have you tried the Log4j Scala API?
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> http://logging.apache.org/
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> log4j/2.x/manual/scala-api.
>> >>>>>>>>>>>
>> >>>>>>>>>>>> html
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> It does currently not support this, but it uses
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Scala
>> >>>>>>>>>>>
>> >>>>>>>>>>>> macros, and
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> this
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> could be added there. But log4j-api and/or
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> log4j-core
>> >>>>>>>>>>>
>> >>>>>>>>>>>> probably
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> needs
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> adapted as well.
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> On 2017-12-09 07:30, Jeffrey Shaw wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> Hello,
>> >>>>>>>>>>>>>>>>>>>>>>>>> I've found that I am able to use Scala macros to
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> provide
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> compile-time
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> source information for log messages. However, I
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> don't
>> >>>>>>>>>>>
>> >>>>>>>>>>>> see
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> a way
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> inject
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> this into log4j's logging mechanism.
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> I'm wondering if there is something I'm
>> missing, or
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> if
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> LogEvent's
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> getSource
>> >>>>>>>>>>>>>>>>>>>>>>>>> method could be duplicated in Message.
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> We could then have zero-overhead location
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> information
>> >>>>>>>>>>>
>> >>>>>>>>>>>> in
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> logs.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> I'm
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> thinking
>> >>>>>>>>>>>>>>>>>>>>>>>>> that tools other than Scala could also take
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> advantage
>> >>>>>>>>>>>
>> >>>>>>>>>>>> of
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> this.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> --
>> >>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> --
>> >>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> --
>> >>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> --
>> >>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>>
>
>
Re: [log4j] providing sourcewith Message
Posted by Jeffrey Shaw <sh...@gmail.com>.
I created a JIRA ticket for this.
https://issues.apache.org/jira/browse/LOG4J2-2360
On Thu, Mar 15, 2018 at 11:37 PM, Jeff Shaw <sh...@gmail.com> wrote:
> Thanks, Remko. There is no ticket that I know of. This is something I was
> inspired to work on before I gave any thought to a formal process.
>
> Sent from my phone
>
> > On Mar 15, 2018, at 11:26 PM, Remko Popma <re...@gmail.com> wrote:
> >
> > I am interested and planning to take a look if others don’t beat me to
> it. Is there a corresponding JIRA ticket?
> >
> > (Shameless plug) Every java main() method deserves http://picocli.info
> >
> >> On Mar 16, 2018, at 5:33, Jeffrey Shaw <sh...@gmail.com> wrote:
> >>
> >> Hi, just hoping to get some eyes on this again.
> >>
> >>> On Fri, Feb 23, 2018 at 10:43 PM, Jeffrey Shaw <sh...@gmail.com>
> wrote:
> >>>
> >>> closed that one and opened a new one with the commits squashed
> >>> https://github.com/apache/logging-log4j2/pull/152
> >>>
> >>>> On Fri, Feb 23, 2018 at 10:11 PM, Jeffrey Shaw <sh...@gmail.com>
> wrote:
> >>>>
> >>>> done! https://github.com/apache/logging-log4j2/pull/151
> >>>>
> >>>> On Fri, Feb 23, 2018 at 9:22 PM, Gary Gregory <garydgregory@gmail.com
> >
> >>>> wrote:
> >>>>
> >>>>> On Fri, Feb 23, 2018 at 7:02 PM, Jeffrey Shaw <sh...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi All,
> >>>>>> I spent some more time on this tonight. I've brought my code up to
> >>>>> date for
> >>>>>> log4j versions 2 and 3. version 2
> >>>>>> <https://github.com/shawjef3/logging-log4j2/tree/message-
> >>>>>> location-release-2.x>
> >>>>>> version
> >>>>>> 3 <https://github.com/shawjef3/logging-log4j2/tree/message-location
> >
> >>>>>> Per Ralph Goers and some others I removed SourceLocation and
> reverted
> >>>>> back
> >>>>>> to StackTraceElement.
> >>>>>>
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> Can you create pull requests so we can see better what you are
> proposing?
> >>>>>
> >>>>> Thank you!
> >>>>> Gary
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> In case this thread is lost in your email, the changes I worked on
> >>>>> expose
> >>>>>> the location part of the Message to loggers, so that if the source
> >>>>> location
> >>>>>> is known at compile time, it can be added to the log with no runtime
> >>>>> cost.
> >>>>>> An example use is the scala loggers
> >>>>>> <https://github.com/shawjef3/logging-log4j-scala> which are
> >>>>> implemented
> >>>>>> with macros, and therefore have that information available at no
> cost
> >>>>> to
> >>>>>> the developer, either.
> >>>>>>
> >>>>>> On Sat, Dec 23, 2017 at 2:14 PM, Mikael Ståldal <mi...@apache.org>
> >>>>> wrote:
> >>>>>>
> >>>>>>> Yes, StackTraceElement does not allow null methodName.
> >>>>>>>
> >>>>>>> But what about using the empty string, or a string like "<unknown>"
> >>>>> if it
> >>>>>>> is not possible to get?
> >>>>>>>
> >>>>>>>
> >>>>>>>> On 2017-12-22 20:26, Jeffrey Shaw wrote:
> >>>>>>>>
> >>>>>>>> I didn't know about clirr, but I can try running that. I tried to
> >>>>> not
> >>>>>>>> break
> >>>>>>>> any existing public methods.
> >>>>>>>>
> >>>>>>>> I created SourceLocation because I think for Scala macros, the
> >>>>> method
> >>>>>> name
> >>>>>>>> can not exist, but StackTraceElement requires a method name. I'll
> >>>>> double
> >>>>>>>> check this.
> >>>>>>>>
> >>>>>>>> On Thu, Dec 21, 2017 at 12:40 AM, Ralph Goers <
> >>>>>> ralph.goers@dslextreme.com
> >>>>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> I’m not sure I would be comfortable applying the patch this way.
> >>>>> Have
> >>>>>> you
> >>>>>>>>> run a clirr report on your changes? I am concerned that this
> could
> >>>>>> break
> >>>>>>>>> customizations that users might have made. What is the reason
> >>>>>>>>> SourceLocation had to be used instead of StackTraceElement?
> >>>>>>>>>
> >>>>>>>>> Ralph
> >>>>>>>>>
> >>>>>>>>> On Dec 20, 2017, at 9:58 PM, Jeffrey Shaw <sh...@gmail.com>
> >>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> It looks like the location only ever gets the file name, because
> >>>>>> that's
> >>>>>>>>>> what StackTraceElement gives. So that's fine.
> >>>>>>>>>>
> >>>>>>>>>> I think I'm ready for a formal review. Should I create pull
> >>>>> requests
> >>>>>> on
> >>>>>>>>>> github for https://github.com/shawjef3/lo
> >>>>> gging-log4j2/tree/message-
> >>>>>>>>>>
> >>>>>>>>> location
> >>>>>>>>>
> >>>>>>>>>> and https://github.com/shawjef3/logging-log4j-scala/tree/
> >>>>>>>>>>
> >>>>>>>>> message-location,
> >>>>>>>>>
> >>>>>>>>>> or is there another process?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Dec 20, 2017 at 2:11 PM, Matt Sicker <bo...@gmail.com>
> >>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> I think that should be configurable in the layout options.
> >>>>>>>>>>>
> >>>>>>>>>>> On 20 December 2017 at 13:04, Dominik Psenner <
> >>>>> dpsenner@gmail.com>
> >>>>>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Could a compile time environment variable like SrcRootDirectory
> >>>>> do
> >>>>>> the
> >>>>>>>>>>>>
> >>>>>>>>>>> job?
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 20 Dec 2017 7:49 p.m., "Jeffrey Shaw" <sh...@gmail.com>
> >>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> I got it working using a custom ExtendedLogger instead of
> >>>>> mocking.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It looks like for file name, there are only two options. We
> can
> >>>>>> have
> >>>>>>>>>>>>>
> >>>>>>>>>>>> the
> >>>>>>>>>>>
> >>>>>>>>>>>> file name, or the full path to the file. The path relative to
> >>>>> the
> >>>>>>>>>>>>>
> >>>>>>>>>>>> project
> >>>>>>>>>>>
> >>>>>>>>>>>> root looks impossible to get, unless we look for magic names
> >>>>> like
> >>>>>>>>>>>>>
> >>>>>>>>>>>> "src".
> >>>>>>>>>>>
> >>>>>>>>>>>> Any opinion as to which to use? I'm tempted to use just the
> file
> >>>>>> name,
> >>>>>>>>>>>>> since the full path to the file seems intrusive, and is
> >>>>> dependent
> >>>>>> on
> >>>>>>>>>>>>>
> >>>>>>>>>>>> the
> >>>>>>>>>>>
> >>>>>>>>>>>> build machine.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Wed, Dec 20, 2017 at 11:35 AM, Matt Sicker <
> >>>>> boards@gmail.com>
> >>>>>>>>>>>>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> It's possible that macros and mocks don't work well together,
> >>>>>> though
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> that's
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> just a guess.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 20 December 2017 at 00:00, Jeff Shaw <shawjef3@gmail.com
> >
> >>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I should add that manually testing it works.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Sent from my phone
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Dec 20, 2017, at 12:45 AM, Jeffrey Shaw <
> >>>>> shawjef3@gmail.com>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I added some tests for traced, but they don't pass. The
> >>>>> mocks
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> say,
> >>>>>>>>>>>
> >>>>>>>>>>>> "Actually, there were zero interactions with this mock." I
> could
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> use
> >>>>>>>>>>>
> >>>>>>>>>>>> some
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> help getting these two tests to work.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> https://github.com/shawjef3/logging-log4j-scala/blob/
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> message-location/log4j-api-scala_2.12/src/test/scala/org/
> >>>>>>>>>>>>>>> apache/logging/log4j/scala/LoggerTest.scala#L574
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Sun, Dec 17, 2017 at 8:50 PM, Jeffrey Shaw <
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> shawjef3@gmail.com
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thanks for the encouragement everyone! I never worked on
> an
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Apache
> >>>>>>>>>>>
> >>>>>>>>>>>> project before and had no idea what to expect from the
> >>>>> community.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I've made some progress. One cool thing I added was a
> >>>>> `traced`
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> method
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> (source), which does the work you'd want for traceEntry,
> >>>>>> traceExit,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> and
> >>>>>>>>>>>>
> >>>>>>>>>>>>> throwing. It would be cool to add catching as well, but that
> >>>>> would
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> require
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> tree traversal, which is beyond me at the moment. I also
> >>>>> haven't
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> figured
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> out how to add the parameter lists. Anyway, an example:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> before:
> >>>>>>>>>>>>>>>>> def f() = {...}
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> after:
> >>>>>>>>>>>>>>>>> def f() = logger.traced(Level.INFO) {...}
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Mon, Dec 11, 2017 at 9:55 PM, Matt Sicker <
> >>>>> boards@gmail.com
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> From the little I've worked with macros (worked more with
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> scalameta
> >>>>>>>>>>>>
> >>>>>>>>>>>>> and
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> shapeless), that looks good so far. If you can add some
> unit
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> tests,
> >>>>>>>>>>>>
> >>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> we'd be happy to merge!
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 11 December 2017 at 20:41, Jeffrey Shaw <
> >>>>>> shawjef3@gmail.com
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Great news! I'm able to run LoggingApp in the scala api
> >>>>> repo
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> without
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> calling StackLocatorUtil.calcLocation, but it prints the
> >>>>> same
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> messages as
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> before. I have to use my patch to log4j of course.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> See https://github.com/shawjef3/lo
> >>>>> gging-log4j-scala/commits/
> >>>>>>>>>>>>>>>>>>> message-location
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Sun, Dec 10, 2017 at 3:56 PM, Matt Sicker <
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> boards@gmail.com
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> This sounds like it'd make a great addition to the
> Scala
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> API!
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On 9 December 2017 at 15:36, Jeffrey Shaw <
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> shawjef3@gmail.com>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Ralph, I agree with you entirely. My intent for these
> >>>>> new
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> log
> >>>>>>>>>>>>
> >>>>>>>>>>>>> methods
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> that they only be called from compile-time generated
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> code.
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 4:30 PM, Ralph Goers <
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> ralph.goers@dslextreme.com>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I don’t understand how this is a good idea. To use
> this
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> you
> >>>>>>>>>>>>
> >>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> need
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> do something like:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Message msg = new StringMessage(getCaller(), “My
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Message”);
> >>>>>>>>>>>>
> >>>>>>>>>>>>> logger.debug(msg);
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Unfortunately the line number would point to the
> line
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> where
> >>>>>>>>>>>>
> >>>>>>>>>>>>> getCaller()
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> called not to the logger statement.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I had thought about modifying AbstractLogger to do
> >>>>>>>>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> message)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> logIfEnabled(getCaller(), Level.DEBUG, marker,
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> message,
> >>>>>>>>>>>>
> >>>>>>>>>>>>> (Throwable)
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> null);
> >>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>> instead of the current
> >>>>>>>>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> message)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> logIfEnabled(FQCN, Level.DEBUG, marker, message,
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> (Throwable)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> null);
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>> But the amount of changes required to get it into
> the
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> LogEvent
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> was
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> large.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> OTOH, if we create a CallerLocationMessage that
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> contains
> >>>>>>>>>>>
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> StackTraceElement and then have existing Messages
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> extend
> >>>>>>>>>>>
> >>>>>>>>>>>> that
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> then we
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> could
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> store the location in the Message if it is a
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> CallerLocationMessage.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Calling
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> getCaller() in this way would be much better since
> it
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>
> >>>>>>>>>>>> at a
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> fixed
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> depth
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> from the caller.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> With Java 9 this could become:
> >>>>>>>>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> message)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> logIfEnabled(stackWalker.walk(
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> s->s.skip(1).findFirst(),
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Level.DEBUG,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> marker, message, (Throwable) null);
> >>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>> although that would pass a StackFrame instead of a
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> StackTraceElement.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> only problems with this is that there is still some
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> overhead
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> calling
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> StackWalker like this. Also, if this is called from a
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> facade,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> such as
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> log4j-slf4j-impl then the number of levels that have to
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>
> >>>>>>>>>>>>> skipped
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> different.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I would really prefer if there was some way to
> capture
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>
> >>>>>>>>>>>>> line
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> number
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> information for the various loggers when the
> annotation
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> processor
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> runs
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> at
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> compile time.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Ralph
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On Dec 9, 2017, at 1:22 PM, Jeffrey Shaw <
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> shawjef3@gmail.com
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Thanks for the link, Mikael. I'll take a look at
> it.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I added some plumbing to core to allow clients to
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> pass
> >>>>>>>>>>>
> >>>>>>>>>>>> a
> >>>>>>>>>>>>
> >>>>>>>>>>>>> StackTraceElement
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> to loggers. I'd like a code review. I'm happy to
> try
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> other
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> methods.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> See
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> following commit.
> >>>>>>>>>>>>>>>>>>>>>>> https://github.com/shawjef3/logging-log4j2/commit/
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 9c42073e9ca4f25a2f4075b1791eee2893534c54
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 10:09 AM, Mikael Ståldal <
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> mikes@apache.org>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Have you tried the Log4j Scala API?
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> http://logging.apache.org/
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> log4j/2.x/manual/scala-api.
> >>>>>>>>>>>
> >>>>>>>>>>>> html
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> It does currently not support this, but it uses
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Scala
> >>>>>>>>>>>
> >>>>>>>>>>>> macros, and
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> could be added there. But log4j-api and/or
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> log4j-core
> >>>>>>>>>>>
> >>>>>>>>>>>> probably
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> needs
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> adapted as well.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> On 2017-12-09 07:30, Jeffrey Shaw wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Hello,
> >>>>>>>>>>>>>>>>>>>>>>>>> I've found that I am able to use Scala macros to
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> provide
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> compile-time
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> source information for log messages. However, I
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> don't
> >>>>>>>>>>>
> >>>>>>>>>>>> see
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> a way
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> inject
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> this into log4j's logging mechanism.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> I'm wondering if there is something I'm missing,
> or
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> if
> >>>>>>>>>>>>
> >>>>>>>>>>>>> LogEvent's
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> getSource
> >>>>>>>>>>>>>>>>>>>>>>>>> method could be duplicated in Message.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> We could then have zero-overhead location
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> information
> >>>>>>>>>>>
> >>>>>>>>>>>> in
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> logs.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I'm
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> thinking
> >>>>>>>>>>>>>>>>>>>>>>>>> that tools other than Scala could also take
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> advantage
> >>>>>>>>>>>
> >>>>>>>>>>>> of
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> this.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Matt Sicker <bo...@gmail.com>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
>
Re: [log4j] providing sourcewith Message
Posted by Jeff Shaw <sh...@gmail.com>.
Thanks, Remko. There is no ticket that I know of. This is something I was inspired to work on before I gave any thought to a formal process.
Sent from my phone
> On Mar 15, 2018, at 11:26 PM, Remko Popma <re...@gmail.com> wrote:
>
> I am interested and planning to take a look if others don’t beat me to it. Is there a corresponding JIRA ticket?
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
>> On Mar 16, 2018, at 5:33, Jeffrey Shaw <sh...@gmail.com> wrote:
>>
>> Hi, just hoping to get some eyes on this again.
>>
>>> On Fri, Feb 23, 2018 at 10:43 PM, Jeffrey Shaw <sh...@gmail.com> wrote:
>>>
>>> closed that one and opened a new one with the commits squashed
>>> https://github.com/apache/logging-log4j2/pull/152
>>>
>>>> On Fri, Feb 23, 2018 at 10:11 PM, Jeffrey Shaw <sh...@gmail.com> wrote:
>>>>
>>>> done! https://github.com/apache/logging-log4j2/pull/151
>>>>
>>>> On Fri, Feb 23, 2018 at 9:22 PM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>>> On Fri, Feb 23, 2018 at 7:02 PM, Jeffrey Shaw <sh...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>> I spent some more time on this tonight. I've brought my code up to
>>>>> date for
>>>>>> log4j versions 2 and 3. version 2
>>>>>> <https://github.com/shawjef3/logging-log4j2/tree/message-
>>>>>> location-release-2.x>
>>>>>> version
>>>>>> 3 <https://github.com/shawjef3/logging-log4j2/tree/message-location>
>>>>>> Per Ralph Goers and some others I removed SourceLocation and reverted
>>>>> back
>>>>>> to StackTraceElement.
>>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> Can you create pull requests so we can see better what you are proposing?
>>>>>
>>>>> Thank you!
>>>>> Gary
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> In case this thread is lost in your email, the changes I worked on
>>>>> expose
>>>>>> the location part of the Message to loggers, so that if the source
>>>>> location
>>>>>> is known at compile time, it can be added to the log with no runtime
>>>>> cost.
>>>>>> An example use is the scala loggers
>>>>>> <https://github.com/shawjef3/logging-log4j-scala> which are
>>>>> implemented
>>>>>> with macros, and therefore have that information available at no cost
>>>>> to
>>>>>> the developer, either.
>>>>>>
>>>>>> On Sat, Dec 23, 2017 at 2:14 PM, Mikael Ståldal <mi...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>>> Yes, StackTraceElement does not allow null methodName.
>>>>>>>
>>>>>>> But what about using the empty string, or a string like "<unknown>"
>>>>> if it
>>>>>>> is not possible to get?
>>>>>>>
>>>>>>>
>>>>>>>> On 2017-12-22 20:26, Jeffrey Shaw wrote:
>>>>>>>>
>>>>>>>> I didn't know about clirr, but I can try running that. I tried to
>>>>> not
>>>>>>>> break
>>>>>>>> any existing public methods.
>>>>>>>>
>>>>>>>> I created SourceLocation because I think for Scala macros, the
>>>>> method
>>>>>> name
>>>>>>>> can not exist, but StackTraceElement requires a method name. I'll
>>>>> double
>>>>>>>> check this.
>>>>>>>>
>>>>>>>> On Thu, Dec 21, 2017 at 12:40 AM, Ralph Goers <
>>>>>> ralph.goers@dslextreme.com
>>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I’m not sure I would be comfortable applying the patch this way.
>>>>> Have
>>>>>> you
>>>>>>>>> run a clirr report on your changes? I am concerned that this could
>>>>>> break
>>>>>>>>> customizations that users might have made. What is the reason
>>>>>>>>> SourceLocation had to be used instead of StackTraceElement?
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> On Dec 20, 2017, at 9:58 PM, Jeffrey Shaw <sh...@gmail.com>
>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> It looks like the location only ever gets the file name, because
>>>>>> that's
>>>>>>>>>> what StackTraceElement gives. So that's fine.
>>>>>>>>>>
>>>>>>>>>> I think I'm ready for a formal review. Should I create pull
>>>>> requests
>>>>>> on
>>>>>>>>>> github for https://github.com/shawjef3/lo
>>>>> gging-log4j2/tree/message-
>>>>>>>>>>
>>>>>>>>> location
>>>>>>>>>
>>>>>>>>>> and https://github.com/shawjef3/logging-log4j-scala/tree/
>>>>>>>>>>
>>>>>>>>> message-location,
>>>>>>>>>
>>>>>>>>>> or is there another process?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Dec 20, 2017 at 2:11 PM, Matt Sicker <bo...@gmail.com>
>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> I think that should be configurable in the layout options.
>>>>>>>>>>>
>>>>>>>>>>> On 20 December 2017 at 13:04, Dominik Psenner <
>>>>> dpsenner@gmail.com>
>>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Could a compile time environment variable like SrcRootDirectory
>>>>> do
>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>> job?
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 20 Dec 2017 7:49 p.m., "Jeffrey Shaw" <sh...@gmail.com>
>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I got it working using a custom ExtendedLogger instead of
>>>>> mocking.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It looks like for file name, there are only two options. We can
>>>>>> have
>>>>>>>>>>>>>
>>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>> file name, or the full path to the file. The path relative to
>>>>> the
>>>>>>>>>>>>>
>>>>>>>>>>>> project
>>>>>>>>>>>
>>>>>>>>>>>> root looks impossible to get, unless we look for magic names
>>>>> like
>>>>>>>>>>>>>
>>>>>>>>>>>> "src".
>>>>>>>>>>>
>>>>>>>>>>>> Any opinion as to which to use? I'm tempted to use just the file
>>>>>> name,
>>>>>>>>>>>>> since the full path to the file seems intrusive, and is
>>>>> dependent
>>>>>> on
>>>>>>>>>>>>>
>>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>> build machine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Dec 20, 2017 at 11:35 AM, Matt Sicker <
>>>>> boards@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> It's possible that macros and mocks don't work well together,
>>>>>> though
>>>>>>>>>>>>>>
>>>>>>>>>>>>> that's
>>>>>>>>>>>>>
>>>>>>>>>>>>>> just a guess.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 20 December 2017 at 00:00, Jeff Shaw <sh...@gmail.com>
>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I should add that manually testing it works.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sent from my phone
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Dec 20, 2017, at 12:45 AM, Jeffrey Shaw <
>>>>> shawjef3@gmail.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I added some tests for traced, but they don't pass. The
>>>>> mocks
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> say,
>>>>>>>>>>>
>>>>>>>>>>>> "Actually, there were zero interactions with this mock." I could
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> use
>>>>>>>>>>>
>>>>>>>>>>>> some
>>>>>>>>>>>>>
>>>>>>>>>>>>>> help getting these two tests to work.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://github.com/shawjef3/logging-log4j-scala/blob/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> message-location/log4j-api-scala_2.12/src/test/scala/org/
>>>>>>>>>>>>>>> apache/logging/log4j/scala/LoggerTest.scala#L574
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Sun, Dec 17, 2017 at 8:50 PM, Jeffrey Shaw <
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> shawjef3@gmail.com
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks for the encouragement everyone! I never worked on an
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Apache
>>>>>>>>>>>
>>>>>>>>>>>> project before and had no idea what to expect from the
>>>>> community.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I've made some progress. One cool thing I added was a
>>>>> `traced`
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> method
>>>>>>>>>>>>>
>>>>>>>>>>>>>> (source), which does the work you'd want for traceEntry,
>>>>>> traceExit,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> and
>>>>>>>>>>>>
>>>>>>>>>>>>> throwing. It would be cool to add catching as well, but that
>>>>> would
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> require
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> tree traversal, which is beyond me at the moment. I also
>>>>> haven't
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> figured
>>>>>>>>>>>>>
>>>>>>>>>>>>>> out how to add the parameter lists. Anyway, an example:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> before:
>>>>>>>>>>>>>>>>> def f() = {...}
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> after:
>>>>>>>>>>>>>>>>> def f() = logger.traced(Level.INFO) {...}
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Dec 11, 2017 at 9:55 PM, Matt Sicker <
>>>>> boards@gmail.com
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> From the little I've worked with macros (worked more with
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> scalameta
>>>>>>>>>>>>
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> shapeless), that looks good so far. If you can add some unit
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> tests,
>>>>>>>>>>>>
>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> we'd be happy to merge!
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 11 December 2017 at 20:41, Jeffrey Shaw <
>>>>>> shawjef3@gmail.com
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Great news! I'm able to run LoggingApp in the scala api
>>>>> repo
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> without
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> calling StackLocatorUtil.calcLocation, but it prints the
>>>>> same
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> messages as
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> before. I have to use my patch to log4j of course.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> See https://github.com/shawjef3/lo
>>>>> gging-log4j-scala/commits/
>>>>>>>>>>>>>>>>>>> message-location
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Sun, Dec 10, 2017 at 3:56 PM, Matt Sicker <
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> boards@gmail.com
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This sounds like it'd make a great addition to the Scala
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> API!
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 9 December 2017 at 15:36, Jeffrey Shaw <
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> shawjef3@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Ralph, I agree with you entirely. My intent for these
>>>>> new
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> log
>>>>>>>>>>>>
>>>>>>>>>>>>> methods
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> that they only be called from compile-time generated
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> code.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 4:30 PM, Ralph Goers <
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ralph.goers@dslextreme.com>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I don’t understand how this is a good idea. To use this
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>
>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> do something like:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Message msg = new StringMessage(getCaller(), “My
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Message”);
>>>>>>>>>>>>
>>>>>>>>>>>>> logger.debug(msg);
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Unfortunately the line number would point to the line
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> where
>>>>>>>>>>>>
>>>>>>>>>>>>> getCaller()
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> called not to the logger statement.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I had thought about modifying AbstractLogger to do
>>>>>>>>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> message)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> logIfEnabled(getCaller(), Level.DEBUG, marker,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> message,
>>>>>>>>>>>>
>>>>>>>>>>>>> (Throwable)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> null);
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>> instead of the current
>>>>>>>>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> message)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> logIfEnabled(FQCN, Level.DEBUG, marker, message,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> (Throwable)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> null);
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>> But the amount of changes required to get it into the
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> LogEvent
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> was
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> large.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> OTOH, if we create a CallerLocationMessage that
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> contains
>>>>>>>>>>>
>>>>>>>>>>>> the
>>>>>>>>>>>>>
>>>>>>>>>>>>>> StackTraceElement and then have existing Messages
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> extend
>>>>>>>>>>>
>>>>>>>>>>>> that
>>>>>>>>>>>>>
>>>>>>>>>>>>>> then we
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> store the location in the Message if it is a
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> CallerLocationMessage.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Calling
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> getCaller() in this way would be much better since it
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>
>>>>>>>>>>>> at a
>>>>>>>>>>>>>
>>>>>>>>>>>>>> fixed
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> depth
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> from the caller.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> With Java 9 this could become:
>>>>>>>>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> message)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> logIfEnabled(stackWalker.walk(
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> s->s.skip(1).findFirst(),
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Level.DEBUG,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> marker, message, (Throwable) null);
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>> although that would pass a StackFrame instead of a
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> StackTraceElement.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> only problems with this is that there is still some
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> overhead
>>>>>>>>>>>>>
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> StackWalker like this. Also, if this is called from a
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> facade,
>>>>>>>>>>>>>
>>>>>>>>>>>>>> such as
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> log4j-slf4j-impl then the number of levels that have to
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>
>>>>>>>>>>>>> skipped
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> different.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I would really prefer if there was some way to capture
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>>> line
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> number
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> information for the various loggers when the annotation
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> processor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> runs
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> compile time.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Dec 9, 2017, at 1:22 PM, Jeffrey Shaw <
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> shawjef3@gmail.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks for the link, Mikael. I'll take a look at it.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I added some plumbing to core to allow clients to
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> pass
>>>>>>>>>>>
>>>>>>>>>>>> a
>>>>>>>>>>>>
>>>>>>>>>>>>> StackTraceElement
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> to loggers. I'd like a code review. I'm happy to try
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>
>>>>>>>>>>>>>> methods.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> See
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> following commit.
>>>>>>>>>>>>>>>>>>>>>>> https://github.com/shawjef3/logging-log4j2/commit/
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 9c42073e9ca4f25a2f4075b1791eee2893534c54
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 10:09 AM, Mikael Ståldal <
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> mikes@apache.org>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Have you tried the Log4j Scala API?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> http://logging.apache.org/
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> log4j/2.x/manual/scala-api.
>>>>>>>>>>>
>>>>>>>>>>>> html
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It does currently not support this, but it uses
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Scala
>>>>>>>>>>>
>>>>>>>>>>>> macros, and
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> could be added there. But log4j-api and/or
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> log4j-core
>>>>>>>>>>>
>>>>>>>>>>>> probably
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> needs
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> adapted as well.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 2017-12-09 07:30, Jeffrey Shaw wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>>>>>>>> I've found that I am able to use Scala macros to
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> provide
>>>>>>>>>>>>>
>>>>>>>>>>>>>> compile-time
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> source information for log messages. However, I
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>
>>>>>>>>>>>> see
>>>>>>>>>>>>>
>>>>>>>>>>>>>> a way
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> inject
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> this into log4j's logging mechanism.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I'm wondering if there is something I'm missing, or
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>
>>>>>>>>>>>>> LogEvent's
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> getSource
>>>>>>>>>>>>>>>>>>>>>>>>> method could be duplicated in Message.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> We could then have zero-overhead location
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> information
>>>>>>>>>>>
>>>>>>>>>>>> in
>>>>>>>>>>>>>
>>>>>>>>>>>>>> logs.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>>>>>>>>>>>>> that tools other than Scala could also take
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> advantage
>>>>>>>>>>>
>>>>>>>>>>>> of
>>>>>>>>>>>>>
>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
Re: [log4j] providing sourcewith Message
Posted by Remko Popma <re...@gmail.com>.
I am interested and planning to take a look if others don’t beat me to it. Is there a corresponding JIRA ticket?
(Shameless plug) Every java main() method deserves http://picocli.info
> On Mar 16, 2018, at 5:33, Jeffrey Shaw <sh...@gmail.com> wrote:
>
> Hi, just hoping to get some eyes on this again.
>
>> On Fri, Feb 23, 2018 at 10:43 PM, Jeffrey Shaw <sh...@gmail.com> wrote:
>>
>> closed that one and opened a new one with the commits squashed
>> https://github.com/apache/logging-log4j2/pull/152
>>
>>> On Fri, Feb 23, 2018 at 10:11 PM, Jeffrey Shaw <sh...@gmail.com> wrote:
>>>
>>> done! https://github.com/apache/logging-log4j2/pull/151
>>>
>>> On Fri, Feb 23, 2018 at 9:22 PM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>>> On Fri, Feb 23, 2018 at 7:02 PM, Jeffrey Shaw <sh...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>> I spent some more time on this tonight. I've brought my code up to
>>>> date for
>>>>> log4j versions 2 and 3. version 2
>>>>> <https://github.com/shawjef3/logging-log4j2/tree/message-
>>>>> location-release-2.x>
>>>>> version
>>>>> 3 <https://github.com/shawjef3/logging-log4j2/tree/message-location>
>>>>> Per Ralph Goers and some others I removed SourceLocation and reverted
>>>> back
>>>>> to StackTraceElement.
>>>>>
>>>>
>>>> Hello,
>>>>
>>>> Can you create pull requests so we can see better what you are proposing?
>>>>
>>>> Thank you!
>>>> Gary
>>>>
>>>>
>>>>
>>>>>
>>>>> In case this thread is lost in your email, the changes I worked on
>>>> expose
>>>>> the location part of the Message to loggers, so that if the source
>>>> location
>>>>> is known at compile time, it can be added to the log with no runtime
>>>> cost.
>>>>> An example use is the scala loggers
>>>>> <https://github.com/shawjef3/logging-log4j-scala> which are
>>>> implemented
>>>>> with macros, and therefore have that information available at no cost
>>>> to
>>>>> the developer, either.
>>>>>
>>>>> On Sat, Dec 23, 2017 at 2:14 PM, Mikael Ståldal <mi...@apache.org>
>>>> wrote:
>>>>>
>>>>>> Yes, StackTraceElement does not allow null methodName.
>>>>>>
>>>>>> But what about using the empty string, or a string like "<unknown>"
>>>> if it
>>>>>> is not possible to get?
>>>>>>
>>>>>>
>>>>>>> On 2017-12-22 20:26, Jeffrey Shaw wrote:
>>>>>>>
>>>>>>> I didn't know about clirr, but I can try running that. I tried to
>>>> not
>>>>>>> break
>>>>>>> any existing public methods.
>>>>>>>
>>>>>>> I created SourceLocation because I think for Scala macros, the
>>>> method
>>>>> name
>>>>>>> can not exist, but StackTraceElement requires a method name. I'll
>>>> double
>>>>>>> check this.
>>>>>>>
>>>>>>> On Thu, Dec 21, 2017 at 12:40 AM, Ralph Goers <
>>>>> ralph.goers@dslextreme.com
>>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I’m not sure I would be comfortable applying the patch this way.
>>>> Have
>>>>> you
>>>>>>>> run a clirr report on your changes? I am concerned that this could
>>>>> break
>>>>>>>> customizations that users might have made. What is the reason
>>>>>>>> SourceLocation had to be used instead of StackTraceElement?
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Dec 20, 2017, at 9:58 PM, Jeffrey Shaw <sh...@gmail.com>
>>>> wrote:
>>>>>>>>>
>>>>>>>>> It looks like the location only ever gets the file name, because
>>>>> that's
>>>>>>>>> what StackTraceElement gives. So that's fine.
>>>>>>>>>
>>>>>>>>> I think I'm ready for a formal review. Should I create pull
>>>> requests
>>>>> on
>>>>>>>>> github for https://github.com/shawjef3/lo
>>>> gging-log4j2/tree/message-
>>>>>>>>>
>>>>>>>> location
>>>>>>>>
>>>>>>>>> and https://github.com/shawjef3/logging-log4j-scala/tree/
>>>>>>>>>
>>>>>>>> message-location,
>>>>>>>>
>>>>>>>>> or is there another process?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Dec 20, 2017 at 2:11 PM, Matt Sicker <bo...@gmail.com>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I think that should be configurable in the layout options.
>>>>>>>>>>
>>>>>>>>>> On 20 December 2017 at 13:04, Dominik Psenner <
>>>> dpsenner@gmail.com>
>>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Could a compile time environment variable like SrcRootDirectory
>>>> do
>>>>> the
>>>>>>>>>>>
>>>>>>>>>> job?
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 20 Dec 2017 7:49 p.m., "Jeffrey Shaw" <sh...@gmail.com>
>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I got it working using a custom ExtendedLogger instead of
>>>> mocking.
>>>>>>>>>>>>
>>>>>>>>>>>> It looks like for file name, there are only two options. We can
>>>>> have
>>>>>>>>>>>>
>>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>>>> file name, or the full path to the file. The path relative to
>>>> the
>>>>>>>>>>>>
>>>>>>>>>>> project
>>>>>>>>>>
>>>>>>>>>>> root looks impossible to get, unless we look for magic names
>>>> like
>>>>>>>>>>>>
>>>>>>>>>>> "src".
>>>>>>>>>>
>>>>>>>>>>> Any opinion as to which to use? I'm tempted to use just the file
>>>>> name,
>>>>>>>>>>>> since the full path to the file seems intrusive, and is
>>>> dependent
>>>>> on
>>>>>>>>>>>>
>>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>>>> build machine.
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Dec 20, 2017 at 11:35 AM, Matt Sicker <
>>>> boards@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> It's possible that macros and mocks don't work well together,
>>>>> though
>>>>>>>>>>>>>
>>>>>>>>>>>> that's
>>>>>>>>>>>>
>>>>>>>>>>>>> just a guess.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 20 December 2017 at 00:00, Jeff Shaw <sh...@gmail.com>
>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I should add that manually testing it works.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sent from my phone
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Dec 20, 2017, at 12:45 AM, Jeffrey Shaw <
>>>> shawjef3@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I added some tests for traced, but they don't pass. The
>>>> mocks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> say,
>>>>>>>>>>
>>>>>>>>>>> "Actually, there were zero interactions with this mock." I could
>>>>>>>>>>>>>>
>>>>>>>>>>>>> use
>>>>>>>>>>
>>>>>>>>>>> some
>>>>>>>>>>>>
>>>>>>>>>>>>> help getting these two tests to work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://github.com/shawjef3/logging-log4j-scala/blob/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> message-location/log4j-api-scala_2.12/src/test/scala/org/
>>>>>>>>>>>>>> apache/logging/log4j/scala/LoggerTest.scala#L574
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sun, Dec 17, 2017 at 8:50 PM, Jeffrey Shaw <
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> shawjef3@gmail.com
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks for the encouragement everyone! I never worked on an
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Apache
>>>>>>>>>>
>>>>>>>>>>> project before and had no idea what to expect from the
>>>> community.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I've made some progress. One cool thing I added was a
>>>> `traced`
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> method
>>>>>>>>>>>>
>>>>>>>>>>>>> (source), which does the work you'd want for traceEntry,
>>>>> traceExit,
>>>>>>>>>>>>>>
>>>>>>>>>>>>> and
>>>>>>>>>>>
>>>>>>>>>>>> throwing. It would be cool to add catching as well, but that
>>>> would
>>>>>>>>>>>>>>
>>>>>>>>>>>>> require
>>>>>>>>>>>>>
>>>>>>>>>>>>>> tree traversal, which is beyond me at the moment. I also
>>>> haven't
>>>>>>>>>>>>>>
>>>>>>>>>>>>> figured
>>>>>>>>>>>>
>>>>>>>>>>>>> out how to add the parameter lists. Anyway, an example:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> before:
>>>>>>>>>>>>>>>> def f() = {...}
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> after:
>>>>>>>>>>>>>>>> def f() = logger.traced(Level.INFO) {...}
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, Dec 11, 2017 at 9:55 PM, Matt Sicker <
>>>> boards@gmail.com
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> From the little I've worked with macros (worked more with
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> scalameta
>>>>>>>>>>>
>>>>>>>>>>>> and
>>>>>>>>>>>>>
>>>>>>>>>>>>>> shapeless), that looks good so far. If you can add some unit
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> tests,
>>>>>>>>>>>
>>>>>>>>>>>> then
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> we'd be happy to merge!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 11 December 2017 at 20:41, Jeffrey Shaw <
>>>>> shawjef3@gmail.com
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Great news! I'm able to run LoggingApp in the scala api
>>>> repo
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> without
>>>>>>>>>>>>>
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> calling StackLocatorUtil.calcLocation, but it prints the
>>>> same
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> messages as
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> before. I have to use my patch to log4j of course.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> See https://github.com/shawjef3/lo
>>>> gging-log4j-scala/commits/
>>>>>>>>>>>>>>>>>> message-location
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Sun, Dec 10, 2017 at 3:56 PM, Matt Sicker <
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> boards@gmail.com
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This sounds like it'd make a great addition to the Scala
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> API!
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 9 December 2017 at 15:36, Jeffrey Shaw <
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> shawjef3@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ralph, I agree with you entirely. My intent for these
>>>> new
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> log
>>>>>>>>>>>
>>>>>>>>>>>> methods
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> that they only be called from compile-time generated
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> code.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 4:30 PM, Ralph Goers <
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ralph.goers@dslextreme.com>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I don’t understand how this is a good idea. To use this
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>
>>>>>>>>>>>> would
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> do something like:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Message msg = new StringMessage(getCaller(), “My
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Message”);
>>>>>>>>>>>
>>>>>>>>>>>> logger.debug(msg);
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Unfortunately the line number would point to the line
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> where
>>>>>>>>>>>
>>>>>>>>>>>> getCaller()
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> called not to the logger statement.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I had thought about modifying AbstractLogger to do
>>>>>>>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> message)
>>>>>>>>>>>>
>>>>>>>>>>>>> {
>>>>>>>>>>>>>
>>>>>>>>>>>>>> logIfEnabled(getCaller(), Level.DEBUG, marker,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> message,
>>>>>>>>>>>
>>>>>>>>>>>> (Throwable)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> null);
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>> instead of the current
>>>>>>>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> message)
>>>>>>>>>>>>
>>>>>>>>>>>>> {
>>>>>>>>>>>>>
>>>>>>>>>>>>>> logIfEnabled(FQCN, Level.DEBUG, marker, message,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> (Throwable)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> null);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>> But the amount of changes required to get it into the
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> LogEvent
>>>>>>>>>>>>>
>>>>>>>>>>>>>> was
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> large.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> OTOH, if we create a CallerLocationMessage that
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> contains
>>>>>>>>>>
>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>>> StackTraceElement and then have existing Messages
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> extend
>>>>>>>>>>
>>>>>>>>>>> that
>>>>>>>>>>>>
>>>>>>>>>>>>> then we
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> store the location in the Message if it is a
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> CallerLocationMessage.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Calling
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> getCaller() in this way would be much better since it
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>
>>>>>>>>>>> at a
>>>>>>>>>>>>
>>>>>>>>>>>>> fixed
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> depth
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> from the caller.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> With Java 9 this could become:
>>>>>>>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> message)
>>>>>>>>>>>>
>>>>>>>>>>>>> {
>>>>>>>>>>>>>
>>>>>>>>>>>>>> logIfEnabled(stackWalker.walk(
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> s->s.skip(1).findFirst(),
>>>>>>>>>>>>
>>>>>>>>>>>>> Level.DEBUG,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> marker, message, (Throwable) null);
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>> although that would pass a StackFrame instead of a
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> StackTraceElement.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> only problems with this is that there is still some
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> overhead
>>>>>>>>>>>>
>>>>>>>>>>>>> in
>>>>>>>>>>>>>
>>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> StackWalker like this. Also, if this is called from a
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> facade,
>>>>>>>>>>>>
>>>>>>>>>>>>> such as
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> log4j-slf4j-impl then the number of levels that have to
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>
>>>>>>>>>>>> skipped
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> different.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I would really prefer if there was some way to capture
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>> line
>>>>>>>>>>>>>
>>>>>>>>>>>>>> number
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> information for the various loggers when the annotation
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> processor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> runs
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> compile time.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Dec 9, 2017, at 1:22 PM, Jeffrey Shaw <
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> shawjef3@gmail.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks for the link, Mikael. I'll take a look at it.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I added some plumbing to core to allow clients to
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> pass
>>>>>>>>>>
>>>>>>>>>>> a
>>>>>>>>>>>
>>>>>>>>>>>> StackTraceElement
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> to loggers. I'd like a code review. I'm happy to try
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>
>>>>>>>>>>>>> methods.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> See
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> following commit.
>>>>>>>>>>>>>>>>>>>>>> https://github.com/shawjef3/logging-log4j2/commit/
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 9c42073e9ca4f25a2f4075b1791eee2893534c54
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 10:09 AM, Mikael Ståldal <
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> mikes@apache.org>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Have you tried the Log4j Scala API?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> http://logging.apache.org/
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> log4j/2.x/manual/scala-api.
>>>>>>>>>>
>>>>>>>>>>> html
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It does currently not support this, but it uses
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Scala
>>>>>>>>>>
>>>>>>>>>>> macros, and
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> could be added there. But log4j-api and/or
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> log4j-core
>>>>>>>>>>
>>>>>>>>>>> probably
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> needs
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> adapted as well.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 2017-12-09 07:30, Jeffrey Shaw wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>>>>>>> I've found that I am able to use Scala macros to
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> provide
>>>>>>>>>>>>
>>>>>>>>>>>>> compile-time
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> source information for log messages. However, I
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>
>>>>>>>>>>> see
>>>>>>>>>>>>
>>>>>>>>>>>>> a way
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> inject
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> this into log4j's logging mechanism.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I'm wondering if there is something I'm missing, or
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>
>>>>>>>>>>>> LogEvent's
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> getSource
>>>>>>>>>>>>>>>>>>>>>>>> method could be duplicated in Message.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> We could then have zero-overhead location
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> information
>>>>>>>>>>
>>>>>>>>>>> in
>>>>>>>>>>>>
>>>>>>>>>>>>> logs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>>>>>>>>>>>> that tools other than Scala could also take
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> advantage
>>>>>>>>>>
>>>>>>>>>>> of
>>>>>>>>>>>>
>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
Re: [log4j] providing sourcewith Message
Posted by Jeffrey Shaw <sh...@gmail.com>.
Hi, just hoping to get some eyes on this again.
On Fri, Feb 23, 2018 at 10:43 PM, Jeffrey Shaw <sh...@gmail.com> wrote:
> closed that one and opened a new one with the commits squashed
> https://github.com/apache/logging-log4j2/pull/152
>
> On Fri, Feb 23, 2018 at 10:11 PM, Jeffrey Shaw <sh...@gmail.com> wrote:
>
>> done! https://github.com/apache/logging-log4j2/pull/151
>>
>> On Fri, Feb 23, 2018 at 9:22 PM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>> On Fri, Feb 23, 2018 at 7:02 PM, Jeffrey Shaw <sh...@gmail.com>
>>> wrote:
>>>
>>> > Hi All,
>>> > I spent some more time on this tonight. I've brought my code up to
>>> date for
>>> > log4j versions 2 and 3. version 2
>>> > <https://github.com/shawjef3/logging-log4j2/tree/message-
>>> > location-release-2.x>
>>> > version
>>> > 3 <https://github.com/shawjef3/logging-log4j2/tree/message-location>
>>> > Per Ralph Goers and some others I removed SourceLocation and reverted
>>> back
>>> > to StackTraceElement.
>>> >
>>>
>>> Hello,
>>>
>>> Can you create pull requests so we can see better what you are proposing?
>>>
>>> Thank you!
>>> Gary
>>>
>>>
>>>
>>> >
>>> > In case this thread is lost in your email, the changes I worked on
>>> expose
>>> > the location part of the Message to loggers, so that if the source
>>> location
>>> > is known at compile time, it can be added to the log with no runtime
>>> cost.
>>> > An example use is the scala loggers
>>> > <https://github.com/shawjef3/logging-log4j-scala> which are
>>> implemented
>>> > with macros, and therefore have that information available at no cost
>>> to
>>> > the developer, either.
>>> >
>>> > On Sat, Dec 23, 2017 at 2:14 PM, Mikael Ståldal <mi...@apache.org>
>>> wrote:
>>> >
>>> > > Yes, StackTraceElement does not allow null methodName.
>>> > >
>>> > > But what about using the empty string, or a string like "<unknown>"
>>> if it
>>> > > is not possible to get?
>>> > >
>>> > >
>>> > > On 2017-12-22 20:26, Jeffrey Shaw wrote:
>>> > >
>>> > >> I didn't know about clirr, but I can try running that. I tried to
>>> not
>>> > >> break
>>> > >> any existing public methods.
>>> > >>
>>> > >> I created SourceLocation because I think for Scala macros, the
>>> method
>>> > name
>>> > >> can not exist, but StackTraceElement requires a method name. I'll
>>> double
>>> > >> check this.
>>> > >>
>>> > >> On Thu, Dec 21, 2017 at 12:40 AM, Ralph Goers <
>>> > ralph.goers@dslextreme.com
>>> > >> >
>>> > >> wrote:
>>> > >>
>>> > >> I’m not sure I would be comfortable applying the patch this way.
>>> Have
>>> > you
>>> > >>> run a clirr report on your changes? I am concerned that this could
>>> > break
>>> > >>> customizations that users might have made. What is the reason
>>> > >>> SourceLocation had to be used instead of StackTraceElement?
>>> > >>>
>>> > >>> Ralph
>>> > >>>
>>> > >>> On Dec 20, 2017, at 9:58 PM, Jeffrey Shaw <sh...@gmail.com>
>>> wrote:
>>> > >>>>
>>> > >>>> It looks like the location only ever gets the file name, because
>>> > that's
>>> > >>>> what StackTraceElement gives. So that's fine.
>>> > >>>>
>>> > >>>> I think I'm ready for a formal review. Should I create pull
>>> requests
>>> > on
>>> > >>>> github for https://github.com/shawjef3/lo
>>> gging-log4j2/tree/message-
>>> > >>>>
>>> > >>> location
>>> > >>>
>>> > >>>> and https://github.com/shawjef3/logging-log4j-scala/tree/
>>> > >>>>
>>> > >>> message-location,
>>> > >>>
>>> > >>>> or is there another process?
>>> > >>>>
>>> > >>>>
>>> > >>>> On Wed, Dec 20, 2017 at 2:11 PM, Matt Sicker <bo...@gmail.com>
>>> > wrote:
>>> > >>>>
>>> > >>>> I think that should be configurable in the layout options.
>>> > >>>>>
>>> > >>>>> On 20 December 2017 at 13:04, Dominik Psenner <
>>> dpsenner@gmail.com>
>>> > >>>>>
>>> > >>>> wrote:
>>> > >>>
>>> > >>>>
>>> > >>>>> Could a compile time environment variable like SrcRootDirectory
>>> do
>>> > the
>>> > >>>>>>
>>> > >>>>> job?
>>> > >>>>>
>>> > >>>>>>
>>> > >>>>>> On 20 Dec 2017 7:49 p.m., "Jeffrey Shaw" <sh...@gmail.com>
>>> > wrote:
>>> > >>>>>>
>>> > >>>>>> I got it working using a custom ExtendedLogger instead of
>>> mocking.
>>> > >>>>>>>
>>> > >>>>>>> It looks like for file name, there are only two options. We can
>>> > have
>>> > >>>>>>>
>>> > >>>>>> the
>>> > >>>>>
>>> > >>>>>> file name, or the full path to the file. The path relative to
>>> the
>>> > >>>>>>>
>>> > >>>>>> project
>>> > >>>>>
>>> > >>>>>> root looks impossible to get, unless we look for magic names
>>> like
>>> > >>>>>>>
>>> > >>>>>> "src".
>>> > >>>>>
>>> > >>>>>> Any opinion as to which to use? I'm tempted to use just the file
>>> > name,
>>> > >>>>>>> since the full path to the file seems intrusive, and is
>>> dependent
>>> > on
>>> > >>>>>>>
>>> > >>>>>> the
>>> > >>>>>
>>> > >>>>>> build machine.
>>> > >>>>>>>
>>> > >>>>>>> On Wed, Dec 20, 2017 at 11:35 AM, Matt Sicker <
>>> boards@gmail.com>
>>> > >>>>>>>
>>> > >>>>>> wrote:
>>> > >>>>>
>>> > >>>>>>
>>> > >>>>>>> It's possible that macros and mocks don't work well together,
>>> > though
>>> > >>>>>>>>
>>> > >>>>>>> that's
>>> > >>>>>>>
>>> > >>>>>>>> just a guess.
>>> > >>>>>>>>
>>> > >>>>>>>> On 20 December 2017 at 00:00, Jeff Shaw <sh...@gmail.com>
>>> > wrote:
>>> > >>>>>>>>
>>> > >>>>>>>> I should add that manually testing it works.
>>> > >>>>>>>>>
>>> > >>>>>>>>> Sent from my phone
>>> > >>>>>>>>>
>>> > >>>>>>>>> On Dec 20, 2017, at 12:45 AM, Jeffrey Shaw <
>>> shawjef3@gmail.com>
>>> > >>>>>>>>>>
>>> > >>>>>>>>> wrote:
>>> > >>>>>>>
>>> > >>>>>>>>
>>> > >>>>>>>>>> I added some tests for traced, but they don't pass. The
>>> mocks
>>> > >>>>>>>>>>
>>> > >>>>>>>>> say,
>>> > >>>>>
>>> > >>>>>> "Actually, there were zero interactions with this mock." I could
>>> > >>>>>>>>>
>>> > >>>>>>>> use
>>> > >>>>>
>>> > >>>>>> some
>>> > >>>>>>>
>>> > >>>>>>>> help getting these two tests to work.
>>> > >>>>>>>>>
>>> > >>>>>>>>>>
>>> > >>>>>>>>>> https://github.com/shawjef3/logging-log4j-scala/blob/
>>> > >>>>>>>>>>
>>> > >>>>>>>>> message-location/log4j-api-scala_2.12/src/test/scala/org/
>>> > >>>>>>>>> apache/logging/log4j/scala/LoggerTest.scala#L574
>>> > >>>>>>>>>
>>> > >>>>>>>>>>
>>> > >>>>>>>>>> On Sun, Dec 17, 2017 at 8:50 PM, Jeffrey Shaw <
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>> shawjef3@gmail.com
>>> > >>>>>
>>> > >>>>>>
>>> > >>>>>>> wrote:
>>> > >>>>>>>>>
>>> > >>>>>>>>>> Thanks for the encouragement everyone! I never worked on an
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>> Apache
>>> > >>>>>
>>> > >>>>>> project before and had no idea what to expect from the
>>> community.
>>> > >>>>>>>>>
>>> > >>>>>>>>>>
>>> > >>>>>>>>>>> I've made some progress. One cool thing I added was a
>>> `traced`
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>> method
>>> > >>>>>>>
>>> > >>>>>>>> (source), which does the work you'd want for traceEntry,
>>> > traceExit,
>>> > >>>>>>>>>
>>> > >>>>>>>> and
>>> > >>>>>>
>>> > >>>>>>> throwing. It would be cool to add catching as well, but that
>>> would
>>> > >>>>>>>>>
>>> > >>>>>>>> require
>>> > >>>>>>>>
>>> > >>>>>>>>> tree traversal, which is beyond me at the moment. I also
>>> haven't
>>> > >>>>>>>>>
>>> > >>>>>>>> figured
>>> > >>>>>>>
>>> > >>>>>>>> out how to add the parameter lists. Anyway, an example:
>>> > >>>>>>>>>
>>> > >>>>>>>>>>
>>> > >>>>>>>>>>> before:
>>> > >>>>>>>>>>> def f() = {...}
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>>> after:
>>> > >>>>>>>>>>> def f() = logger.traced(Level.INFO) {...}
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>>> On Mon, Dec 11, 2017 at 9:55 PM, Matt Sicker <
>>> boards@gmail.com
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>
>>> > >>>>>> wrote:
>>> > >>>>>>>>
>>> > >>>>>>>>> From the little I've worked with macros (worked more with
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>> scalameta
>>> > >>>>>>
>>> > >>>>>>> and
>>> > >>>>>>>>
>>> > >>>>>>>>> shapeless), that looks good so far. If you can add some unit
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>> tests,
>>> > >>>>>>
>>> > >>>>>>> then
>>> > >>>>>>>>>
>>> > >>>>>>>>>> we'd be happy to merge!
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>> On 11 December 2017 at 20:41, Jeffrey Shaw <
>>> > shawjef3@gmail.com
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>
>>> > >>>>>> wrote:
>>> > >>>>>>>>
>>> > >>>>>>>>>
>>> > >>>>>>>>>>>> Great news! I'm able to run LoggingApp in the scala api
>>> repo
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>> without
>>> > >>>>>>>>
>>> > >>>>>>>>> it
>>> > >>>>>>>>>
>>> > >>>>>>>>>> calling StackLocatorUtil.calcLocation, but it prints the
>>> same
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>> messages as
>>> > >>>>>>>>>
>>> > >>>>>>>>>> before. I have to use my patch to log4j of course.
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>> See https://github.com/shawjef3/lo
>>> gging-log4j-scala/commits/
>>> > >>>>>>>>>>>>> message-location
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>> On Sun, Dec 10, 2017 at 3:56 PM, Matt Sicker <
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>> boards@gmail.com
>>> > >>>>>
>>> > >>>>>>
>>> > >>>>>>> wrote:
>>> > >>>>>>>>>
>>> > >>>>>>>>>>
>>> > >>>>>>>>>>>>> This sounds like it'd make a great addition to the Scala
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>> API!
>>> > >>>>>
>>> > >>>>>>
>>> > >>>>>>>>>>>>>> On 9 December 2017 at 15:36, Jeffrey Shaw <
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>> shawjef3@gmail.com>
>>> > >>>>>>
>>> > >>>>>>> wrote:
>>> > >>>>>>>>>
>>> > >>>>>>>>>>
>>> > >>>>>>>>>>>>>> Ralph, I agree with you entirely. My intent for these
>>> new
>>> > >>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> log
>>> > >>>>>>
>>> > >>>>>>> methods
>>> > >>>>>>>>>
>>> > >>>>>>>>>> is
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> that they only be called from compile-time generated
>>> > >>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> code.
>>> > >>>>>
>>> > >>>>>>
>>> > >>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 4:30 PM, Ralph Goers <
>>> > >>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> ralph.goers@dslextreme.com>
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> wrote:
>>> > >>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> I don’t understand how this is a good idea. To use this
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> you
>>> > >>>>>>
>>> > >>>>>>> would
>>> > >>>>>>>>>
>>> > >>>>>>>>>> need
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> to
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> do something like:
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>> Message msg = new StringMessage(getCaller(), “My
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> Message”);
>>> > >>>>>>
>>> > >>>>>>> logger.debug(msg);
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>> Unfortunately the line number would point to the line
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> where
>>> > >>>>>>
>>> > >>>>>>> getCaller()
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> is
>>> > >>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>> called not to the logger statement.
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>> I had thought about modifying AbstractLogger to do
>>> > >>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> message)
>>> > >>>>>>>
>>> > >>>>>>>> {
>>> > >>>>>>>>
>>> > >>>>>>>>> logIfEnabled(getCaller(), Level.DEBUG, marker,
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> message,
>>> > >>>>>>
>>> > >>>>>>> (Throwable)
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> null);
>>> > >>>>>>>>>>>>>>>> }
>>> > >>>>>>>>>>>>>>>> instead of the current
>>> > >>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> message)
>>> > >>>>>>>
>>> > >>>>>>>> {
>>> > >>>>>>>>
>>> > >>>>>>>>> logIfEnabled(FQCN, Level.DEBUG, marker, message,
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> (Throwable)
>>> > >>>>>>>>>
>>> > >>>>>>>>>> null);
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> }
>>> > >>>>>>>>>>>>>>>> But the amount of changes required to get it into the
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> LogEvent
>>> > >>>>>>>>
>>> > >>>>>>>>> was
>>> > >>>>>>>>>
>>> > >>>>>>>>>> large.
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> OTOH, if we create a CallerLocationMessage that
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> contains
>>> > >>>>>
>>> > >>>>>> the
>>> > >>>>>>>
>>> > >>>>>>>> StackTraceElement and then have existing Messages
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> extend
>>> > >>>>>
>>> > >>>>>> that
>>> > >>>>>>>
>>> > >>>>>>>> then we
>>> > >>>>>>>>>
>>> > >>>>>>>>>> could
>>> > >>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>> store the location in the Message if it is a
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> CallerLocationMessage.
>>> > >>>>>>>>>
>>> > >>>>>>>>>> Calling
>>> > >>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>> getCaller() in this way would be much better since it
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> is
>>> > >>>>>
>>> > >>>>>> at a
>>> > >>>>>>>
>>> > >>>>>>>> fixed
>>> > >>>>>>>>>
>>> > >>>>>>>>>> depth
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> from the caller.
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>> With Java 9 this could become:
>>> > >>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> message)
>>> > >>>>>>>
>>> > >>>>>>>> {
>>> > >>>>>>>>
>>> > >>>>>>>>> logIfEnabled(stackWalker.walk(
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> s->s.skip(1).findFirst(),
>>> > >>>>>>>
>>> > >>>>>>>> Level.DEBUG,
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> marker, message, (Throwable) null);
>>> > >>>>>>>>>>>>>>>> }
>>> > >>>>>>>>>>>>>>>> although that would pass a StackFrame instead of a
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> StackTraceElement.
>>> > >>>>>>>>>
>>> > >>>>>>>>>> The
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> only problems with this is that there is still some
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> overhead
>>> > >>>>>>>
>>> > >>>>>>>> in
>>> > >>>>>>>>
>>> > >>>>>>>>> calling
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> StackWalker like this. Also, if this is called from a
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> facade,
>>> > >>>>>>>
>>> > >>>>>>>> such as
>>> > >>>>>>>>>
>>> > >>>>>>>>>> log4j-slf4j-impl then the number of levels that have to
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> be
>>> > >>>>>>
>>> > >>>>>>> skipped
>>> > >>>>>>>>>
>>> > >>>>>>>>>> would
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> be
>>> > >>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>> different.
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>> I would really prefer if there was some way to capture
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> the
>>> > >>>>>>
>>> > >>>>>>> line
>>> > >>>>>>>>
>>> > >>>>>>>>> number
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> information for the various loggers when the annotation
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> processor
>>> > >>>>>>>>>
>>> > >>>>>>>>>> runs
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> at
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> compile time.
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>> Ralph
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>> On Dec 9, 2017, at 1:22 PM, Jeffrey Shaw <
>>> > >>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>> shawjef3@gmail.com
>>> > >>>>>>>>
>>> > >>>>>>>>>
>>> > >>>>>>>>>> wrote:
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>> Thanks for the link, Mikael. I'll take a look at it.
>>> > >>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>> I added some plumbing to core to allow clients to
>>> > >>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>> pass
>>> > >>>>>
>>> > >>>>>> a
>>> > >>>>>>
>>> > >>>>>>> StackTraceElement
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>> to loggers. I'd like a code review. I'm happy to try
>>> > >>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>> other
>>> > >>>>>>>
>>> > >>>>>>>> methods.
>>> > >>>>>>>>>
>>> > >>>>>>>>>> See
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> the
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>> following commit.
>>> > >>>>>>>>>>>>>>>>> https://github.com/shawjef3/logging-log4j2/commit/
>>> > >>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>> 9c42073e9ca4f25a2f4075b1791eee2893534c54
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 10:09 AM, Mikael Ståldal <
>>> > >>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>> mikes@apache.org>
>>> > >>>>>>>>>
>>> > >>>>>>>>>> wrote:
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>> Have you tried the Log4j Scala API?
>>> > >>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>>> http://logging.apache.org/
>>> > >>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>> log4j/2.x/manual/scala-api.
>>> > >>>>>
>>> > >>>>>> html
>>> > >>>>>>>
>>> > >>>>>>>>
>>> > >>>>>>>>>>>>>>>>>> It does currently not support this, but it uses
>>> > >>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>> Scala
>>> > >>>>>
>>> > >>>>>> macros, and
>>> > >>>>>>>>>
>>> > >>>>>>>>>> this
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> could be added there. But log4j-api and/or
>>> > >>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>> log4j-core
>>> > >>>>>
>>> > >>>>>> probably
>>> > >>>>>>>>>
>>> > >>>>>>>>>> needs
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> to
>>> > >>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>> adapted as well.
>>> > >>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>>> On 2017-12-09 07:30, Jeffrey Shaw wrote:
>>> > >>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>>> Hello,
>>> > >>>>>>>>>>>>>>>>>>> I've found that I am able to use Scala macros to
>>> > >>>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>>> provide
>>> > >>>>>>>
>>> > >>>>>>>> compile-time
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>> source information for log messages. However, I
>>> > >>>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>>> don't
>>> > >>>>>
>>> > >>>>>> see
>>> > >>>>>>>
>>> > >>>>>>>> a way
>>> > >>>>>>>>>
>>> > >>>>>>>>>> to
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> inject
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>> this into log4j's logging mechanism.
>>> > >>>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>>>> I'm wondering if there is something I'm missing, or
>>> > >>>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>>> if
>>> > >>>>>>
>>> > >>>>>>> LogEvent's
>>> > >>>>>>>>>
>>> > >>>>>>>>>> getSource
>>> > >>>>>>>>>>>>>>>>>>> method could be duplicated in Message.
>>> > >>>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>>>> We could then have zero-overhead location
>>> > >>>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>>> information
>>> > >>>>>
>>> > >>>>>> in
>>> > >>>>>>>
>>> > >>>>>>>> logs.
>>> > >>>>>>>>>
>>> > >>>>>>>>>> I'm
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> thinking
>>> > >>>>>>>>>>>>>>>>>>> that tools other than Scala could also take
>>> > >>>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>>> advantage
>>> > >>>>>
>>> > >>>>>> of
>>> > >>>>>>>
>>> > >>>>>>>> this.
>>> > >>>>>>>>>
>>> > >>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>> --
>>> > >>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>>
>>> > >>>>>>>>>>>>>
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>> --
>>> > >>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>> > >>>>>>>>>>>>
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>>>
>>> > >>>>>>>>>>
>>> > >>>>>>>>>
>>> > >>>>>>>>
>>> > >>>>>>>>
>>> > >>>>>>>> --
>>> > >>>>>>>> Matt Sicker <bo...@gmail.com>
>>> > >>>>>>>>
>>> > >>>>>>>>
>>> > >>>>>>>
>>> > >>>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> --
>>> > >>>>> Matt Sicker <bo...@gmail.com>
>>> > >>>>>
>>> > >>>>>
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>
>>> > >
>>> >
>>>
>>
>>
>
Re: [log4j] providing sourcewith Message
Posted by Jeffrey Shaw <sh...@gmail.com>.
closed that one and opened a new one with the commits squashed
https://github.com/apache/logging-log4j2/pull/152
On Fri, Feb 23, 2018 at 10:11 PM, Jeffrey Shaw <sh...@gmail.com> wrote:
> done! https://github.com/apache/logging-log4j2/pull/151
>
> On Fri, Feb 23, 2018 at 9:22 PM, Gary Gregory <ga...@gmail.com>
> wrote:
>
>> On Fri, Feb 23, 2018 at 7:02 PM, Jeffrey Shaw <sh...@gmail.com> wrote:
>>
>> > Hi All,
>> > I spent some more time on this tonight. I've brought my code up to date
>> for
>> > log4j versions 2 and 3. version 2
>> > <https://github.com/shawjef3/logging-log4j2/tree/message-
>> > location-release-2.x>
>> > version
>> > 3 <https://github.com/shawjef3/logging-log4j2/tree/message-location>
>> > Per Ralph Goers and some others I removed SourceLocation and reverted
>> back
>> > to StackTraceElement.
>> >
>>
>> Hello,
>>
>> Can you create pull requests so we can see better what you are proposing?
>>
>> Thank you!
>> Gary
>>
>>
>>
>> >
>> > In case this thread is lost in your email, the changes I worked on
>> expose
>> > the location part of the Message to loggers, so that if the source
>> location
>> > is known at compile time, it can be added to the log with no runtime
>> cost.
>> > An example use is the scala loggers
>> > <https://github.com/shawjef3/logging-log4j-scala> which are implemented
>> > with macros, and therefore have that information available at no cost to
>> > the developer, either.
>> >
>> > On Sat, Dec 23, 2017 at 2:14 PM, Mikael Ståldal <mi...@apache.org>
>> wrote:
>> >
>> > > Yes, StackTraceElement does not allow null methodName.
>> > >
>> > > But what about using the empty string, or a string like "<unknown>"
>> if it
>> > > is not possible to get?
>> > >
>> > >
>> > > On 2017-12-22 20:26, Jeffrey Shaw wrote:
>> > >
>> > >> I didn't know about clirr, but I can try running that. I tried to not
>> > >> break
>> > >> any existing public methods.
>> > >>
>> > >> I created SourceLocation because I think for Scala macros, the method
>> > name
>> > >> can not exist, but StackTraceElement requires a method name. I'll
>> double
>> > >> check this.
>> > >>
>> > >> On Thu, Dec 21, 2017 at 12:40 AM, Ralph Goers <
>> > ralph.goers@dslextreme.com
>> > >> >
>> > >> wrote:
>> > >>
>> > >> I’m not sure I would be comfortable applying the patch this way. Have
>> > you
>> > >>> run a clirr report on your changes? I am concerned that this could
>> > break
>> > >>> customizations that users might have made. What is the reason
>> > >>> SourceLocation had to be used instead of StackTraceElement?
>> > >>>
>> > >>> Ralph
>> > >>>
>> > >>> On Dec 20, 2017, at 9:58 PM, Jeffrey Shaw <sh...@gmail.com>
>> wrote:
>> > >>>>
>> > >>>> It looks like the location only ever gets the file name, because
>> > that's
>> > >>>> what StackTraceElement gives. So that's fine.
>> > >>>>
>> > >>>> I think I'm ready for a formal review. Should I create pull
>> requests
>> > on
>> > >>>> github for https://github.com/shawjef3/lo
>> gging-log4j2/tree/message-
>> > >>>>
>> > >>> location
>> > >>>
>> > >>>> and https://github.com/shawjef3/logging-log4j-scala/tree/
>> > >>>>
>> > >>> message-location,
>> > >>>
>> > >>>> or is there another process?
>> > >>>>
>> > >>>>
>> > >>>> On Wed, Dec 20, 2017 at 2:11 PM, Matt Sicker <bo...@gmail.com>
>> > wrote:
>> > >>>>
>> > >>>> I think that should be configurable in the layout options.
>> > >>>>>
>> > >>>>> On 20 December 2017 at 13:04, Dominik Psenner <dpsenner@gmail.com
>> >
>> > >>>>>
>> > >>>> wrote:
>> > >>>
>> > >>>>
>> > >>>>> Could a compile time environment variable like SrcRootDirectory do
>> > the
>> > >>>>>>
>> > >>>>> job?
>> > >>>>>
>> > >>>>>>
>> > >>>>>> On 20 Dec 2017 7:49 p.m., "Jeffrey Shaw" <sh...@gmail.com>
>> > wrote:
>> > >>>>>>
>> > >>>>>> I got it working using a custom ExtendedLogger instead of
>> mocking.
>> > >>>>>>>
>> > >>>>>>> It looks like for file name, there are only two options. We can
>> > have
>> > >>>>>>>
>> > >>>>>> the
>> > >>>>>
>> > >>>>>> file name, or the full path to the file. The path relative to the
>> > >>>>>>>
>> > >>>>>> project
>> > >>>>>
>> > >>>>>> root looks impossible to get, unless we look for magic names like
>> > >>>>>>>
>> > >>>>>> "src".
>> > >>>>>
>> > >>>>>> Any opinion as to which to use? I'm tempted to use just the file
>> > name,
>> > >>>>>>> since the full path to the file seems intrusive, and is
>> dependent
>> > on
>> > >>>>>>>
>> > >>>>>> the
>> > >>>>>
>> > >>>>>> build machine.
>> > >>>>>>>
>> > >>>>>>> On Wed, Dec 20, 2017 at 11:35 AM, Matt Sicker <boards@gmail.com
>> >
>> > >>>>>>>
>> > >>>>>> wrote:
>> > >>>>>
>> > >>>>>>
>> > >>>>>>> It's possible that macros and mocks don't work well together,
>> > though
>> > >>>>>>>>
>> > >>>>>>> that's
>> > >>>>>>>
>> > >>>>>>>> just a guess.
>> > >>>>>>>>
>> > >>>>>>>> On 20 December 2017 at 00:00, Jeff Shaw <sh...@gmail.com>
>> > wrote:
>> > >>>>>>>>
>> > >>>>>>>> I should add that manually testing it works.
>> > >>>>>>>>>
>> > >>>>>>>>> Sent from my phone
>> > >>>>>>>>>
>> > >>>>>>>>> On Dec 20, 2017, at 12:45 AM, Jeffrey Shaw <
>> shawjef3@gmail.com>
>> > >>>>>>>>>>
>> > >>>>>>>>> wrote:
>> > >>>>>>>
>> > >>>>>>>>
>> > >>>>>>>>>> I added some tests for traced, but they don't pass. The mocks
>> > >>>>>>>>>>
>> > >>>>>>>>> say,
>> > >>>>>
>> > >>>>>> "Actually, there were zero interactions with this mock." I could
>> > >>>>>>>>>
>> > >>>>>>>> use
>> > >>>>>
>> > >>>>>> some
>> > >>>>>>>
>> > >>>>>>>> help getting these two tests to work.
>> > >>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>> https://github.com/shawjef3/logging-log4j-scala/blob/
>> > >>>>>>>>>>
>> > >>>>>>>>> message-location/log4j-api-scala_2.12/src/test/scala/org/
>> > >>>>>>>>> apache/logging/log4j/scala/LoggerTest.scala#L574
>> > >>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>> On Sun, Dec 17, 2017 at 8:50 PM, Jeffrey Shaw <
>> > >>>>>>>>>>>
>> > >>>>>>>>>> shawjef3@gmail.com
>> > >>>>>
>> > >>>>>>
>> > >>>>>>> wrote:
>> > >>>>>>>>>
>> > >>>>>>>>>> Thanks for the encouragement everyone! I never worked on an
>> > >>>>>>>>>>>
>> > >>>>>>>>>> Apache
>> > >>>>>
>> > >>>>>> project before and had no idea what to expect from the community.
>> > >>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>> I've made some progress. One cool thing I added was a
>> `traced`
>> > >>>>>>>>>>>
>> > >>>>>>>>>> method
>> > >>>>>>>
>> > >>>>>>>> (source), which does the work you'd want for traceEntry,
>> > traceExit,
>> > >>>>>>>>>
>> > >>>>>>>> and
>> > >>>>>>
>> > >>>>>>> throwing. It would be cool to add catching as well, but that
>> would
>> > >>>>>>>>>
>> > >>>>>>>> require
>> > >>>>>>>>
>> > >>>>>>>>> tree traversal, which is beyond me at the moment. I also
>> haven't
>> > >>>>>>>>>
>> > >>>>>>>> figured
>> > >>>>>>>
>> > >>>>>>>> out how to add the parameter lists. Anyway, an example:
>> > >>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>> before:
>> > >>>>>>>>>>> def f() = {...}
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> after:
>> > >>>>>>>>>>> def f() = logger.traced(Level.INFO) {...}
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> On Mon, Dec 11, 2017 at 9:55 PM, Matt Sicker <
>> boards@gmail.com
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>> wrote:
>> > >>>>>>>>
>> > >>>>>>>>> From the little I've worked with macros (worked more with
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>> scalameta
>> > >>>>>>
>> > >>>>>>> and
>> > >>>>>>>>
>> > >>>>>>>>> shapeless), that looks good so far. If you can add some unit
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>> tests,
>> > >>>>>>
>> > >>>>>>> then
>> > >>>>>>>>>
>> > >>>>>>>>>> we'd be happy to merge!
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> On 11 December 2017 at 20:41, Jeffrey Shaw <
>> > shawjef3@gmail.com
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>> wrote:
>> > >>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>>>> Great news! I'm able to run LoggingApp in the scala api
>> repo
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>> without
>> > >>>>>>>>
>> > >>>>>>>>> it
>> > >>>>>>>>>
>> > >>>>>>>>>> calling StackLocatorUtil.calcLocation, but it prints the same
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>> messages as
>> > >>>>>>>>>
>> > >>>>>>>>>> before. I have to use my patch to log4j of course.
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>> See https://github.com/shawjef3/lo
>> gging-log4j-scala/commits/
>> > >>>>>>>>>>>>> message-location
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>> On Sun, Dec 10, 2017 at 3:56 PM, Matt Sicker <
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>> boards@gmail.com
>> > >>>>>
>> > >>>>>>
>> > >>>>>>> wrote:
>> > >>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>>>> This sounds like it'd make a great addition to the Scala
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>> API!
>> > >>>>>
>> > >>>>>>
>> > >>>>>>>>>>>>>> On 9 December 2017 at 15:36, Jeffrey Shaw <
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>> shawjef3@gmail.com>
>> > >>>>>>
>> > >>>>>>> wrote:
>> > >>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>>>>> Ralph, I agree with you entirely. My intent for these new
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> log
>> > >>>>>>
>> > >>>>>>> methods
>> > >>>>>>>>>
>> > >>>>>>>>>> is
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> that they only be called from compile-time generated
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> code.
>> > >>>>>
>> > >>>>>>
>> > >>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 4:30 PM, Ralph Goers <
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> ralph.goers@dslextreme.com>
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> wrote:
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> I don’t understand how this is a good idea. To use this
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> you
>> > >>>>>>
>> > >>>>>>> would
>> > >>>>>>>>>
>> > >>>>>>>>>> need
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> to
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> do something like:
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> Message msg = new StringMessage(getCaller(), “My
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> Message”);
>> > >>>>>>
>> > >>>>>>> logger.debug(msg);
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> Unfortunately the line number would point to the line
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> where
>> > >>>>>>
>> > >>>>>>> getCaller()
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> is
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> called not to the logger statement.
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> I had thought about modifying AbstractLogger to do
>> > >>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> message)
>> > >>>>>>>
>> > >>>>>>>> {
>> > >>>>>>>>
>> > >>>>>>>>> logIfEnabled(getCaller(), Level.DEBUG, marker,
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> message,
>> > >>>>>>
>> > >>>>>>> (Throwable)
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> null);
>> > >>>>>>>>>>>>>>>> }
>> > >>>>>>>>>>>>>>>> instead of the current
>> > >>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> message)
>> > >>>>>>>
>> > >>>>>>>> {
>> > >>>>>>>>
>> > >>>>>>>>> logIfEnabled(FQCN, Level.DEBUG, marker, message,
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> (Throwable)
>> > >>>>>>>>>
>> > >>>>>>>>>> null);
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> }
>> > >>>>>>>>>>>>>>>> But the amount of changes required to get it into the
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> LogEvent
>> > >>>>>>>>
>> > >>>>>>>>> was
>> > >>>>>>>>>
>> > >>>>>>>>>> large.
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> OTOH, if we create a CallerLocationMessage that
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> contains
>> > >>>>>
>> > >>>>>> the
>> > >>>>>>>
>> > >>>>>>>> StackTraceElement and then have existing Messages
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> extend
>> > >>>>>
>> > >>>>>> that
>> > >>>>>>>
>> > >>>>>>>> then we
>> > >>>>>>>>>
>> > >>>>>>>>>> could
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> store the location in the Message if it is a
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> CallerLocationMessage.
>> > >>>>>>>>>
>> > >>>>>>>>>> Calling
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> getCaller() in this way would be much better since it
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> is
>> > >>>>>
>> > >>>>>> at a
>> > >>>>>>>
>> > >>>>>>>> fixed
>> > >>>>>>>>>
>> > >>>>>>>>>> depth
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> from the caller.
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> With Java 9 this could become:
>> > >>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> message)
>> > >>>>>>>
>> > >>>>>>>> {
>> > >>>>>>>>
>> > >>>>>>>>> logIfEnabled(stackWalker.walk(
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> s->s.skip(1).findFirst(),
>> > >>>>>>>
>> > >>>>>>>> Level.DEBUG,
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> marker, message, (Throwable) null);
>> > >>>>>>>>>>>>>>>> }
>> > >>>>>>>>>>>>>>>> although that would pass a StackFrame instead of a
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> StackTraceElement.
>> > >>>>>>>>>
>> > >>>>>>>>>> The
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> only problems with this is that there is still some
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> overhead
>> > >>>>>>>
>> > >>>>>>>> in
>> > >>>>>>>>
>> > >>>>>>>>> calling
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> StackWalker like this. Also, if this is called from a
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> facade,
>> > >>>>>>>
>> > >>>>>>>> such as
>> > >>>>>>>>>
>> > >>>>>>>>>> log4j-slf4j-impl then the number of levels that have to
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> be
>> > >>>>>>
>> > >>>>>>> skipped
>> > >>>>>>>>>
>> > >>>>>>>>>> would
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> be
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> different.
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> I would really prefer if there was some way to capture
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> the
>> > >>>>>>
>> > >>>>>>> line
>> > >>>>>>>>
>> > >>>>>>>>> number
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> information for the various loggers when the annotation
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> processor
>> > >>>>>>>>>
>> > >>>>>>>>>> runs
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> at
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> compile time.
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> Ralph
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> On Dec 9, 2017, at 1:22 PM, Jeffrey Shaw <
>> > >>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> shawjef3@gmail.com
>> > >>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>> wrote:
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>> Thanks for the link, Mikael. I'll take a look at it.
>> > >>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>> I added some plumbing to core to allow clients to
>> > >>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> pass
>> > >>>>>
>> > >>>>>> a
>> > >>>>>>
>> > >>>>>>> StackTraceElement
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>> to loggers. I'd like a code review. I'm happy to try
>> > >>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> other
>> > >>>>>>>
>> > >>>>>>>> methods.
>> > >>>>>>>>>
>> > >>>>>>>>>> See
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> the
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>> following commit.
>> > >>>>>>>>>>>>>>>>> https://github.com/shawjef3/logging-log4j2/commit/
>> > >>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> 9c42073e9ca4f25a2f4075b1791eee2893534c54
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 10:09 AM, Mikael Ståldal <
>> > >>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> mikes@apache.org>
>> > >>>>>>>>>
>> > >>>>>>>>>> wrote:
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>> Have you tried the Log4j Scala API?
>> > >>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>> http://logging.apache.org/
>> > >>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>> log4j/2.x/manual/scala-api.
>> > >>>>>
>> > >>>>>> html
>> > >>>>>>>
>> > >>>>>>>>
>> > >>>>>>>>>>>>>>>>>> It does currently not support this, but it uses
>> > >>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>> Scala
>> > >>>>>
>> > >>>>>> macros, and
>> > >>>>>>>>>
>> > >>>>>>>>>> this
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> could be added there. But log4j-api and/or
>> > >>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>> log4j-core
>> > >>>>>
>> > >>>>>> probably
>> > >>>>>>>>>
>> > >>>>>>>>>> needs
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> to
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> adapted as well.
>> > >>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>> On 2017-12-09 07:30, Jeffrey Shaw wrote:
>> > >>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>> Hello,
>> > >>>>>>>>>>>>>>>>>>> I've found that I am able to use Scala macros to
>> > >>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>> provide
>> > >>>>>>>
>> > >>>>>>>> compile-time
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> source information for log messages. However, I
>> > >>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>> don't
>> > >>>>>
>> > >>>>>> see
>> > >>>>>>>
>> > >>>>>>>> a way
>> > >>>>>>>>>
>> > >>>>>>>>>> to
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> inject
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>> this into log4j's logging mechanism.
>> > >>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>> I'm wondering if there is something I'm missing, or
>> > >>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>> if
>> > >>>>>>
>> > >>>>>>> LogEvent's
>> > >>>>>>>>>
>> > >>>>>>>>>> getSource
>> > >>>>>>>>>>>>>>>>>>> method could be duplicated in Message.
>> > >>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>> We could then have zero-overhead location
>> > >>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>> information
>> > >>>>>
>> > >>>>>> in
>> > >>>>>>>
>> > >>>>>>>> logs.
>> > >>>>>>>>>
>> > >>>>>>>>>> I'm
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> thinking
>> > >>>>>>>>>>>>>>>>>>> that tools other than Scala could also take
>> > >>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>> advantage
>> > >>>>>
>> > >>>>>> of
>> > >>>>>>>
>> > >>>>>>>> this.
>> > >>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> --
>> > >>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> --
>> > >>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>> --
>> > >>>>>>>> Matt Sicker <bo...@gmail.com>
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>
>> > >>>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>> --
>> > >>>>> Matt Sicker <bo...@gmail.com>
>> > >>>>>
>> > >>>>>
>> > >>>
>> > >>>
>> > >>>
>> > >>
>> > >
>> >
>>
>
>
Re: [log4j] providing sourcewith Message
Posted by Jeffrey Shaw <sh...@gmail.com>.
done! https://github.com/apache/logging-log4j2/pull/151
On Fri, Feb 23, 2018 at 9:22 PM, Gary Gregory <ga...@gmail.com>
wrote:
> On Fri, Feb 23, 2018 at 7:02 PM, Jeffrey Shaw <sh...@gmail.com> wrote:
>
> > Hi All,
> > I spent some more time on this tonight. I've brought my code up to date
> for
> > log4j versions 2 and 3. version 2
> > <https://github.com/shawjef3/logging-log4j2/tree/message-
> > location-release-2.x>
> > version
> > 3 <https://github.com/shawjef3/logging-log4j2/tree/message-location>
> > Per Ralph Goers and some others I removed SourceLocation and reverted
> back
> > to StackTraceElement.
> >
>
> Hello,
>
> Can you create pull requests so we can see better what you are proposing?
>
> Thank you!
> Gary
>
>
>
> >
> > In case this thread is lost in your email, the changes I worked on expose
> > the location part of the Message to loggers, so that if the source
> location
> > is known at compile time, it can be added to the log with no runtime
> cost.
> > An example use is the scala loggers
> > <https://github.com/shawjef3/logging-log4j-scala> which are implemented
> > with macros, and therefore have that information available at no cost to
> > the developer, either.
> >
> > On Sat, Dec 23, 2017 at 2:14 PM, Mikael Ståldal <mi...@apache.org>
> wrote:
> >
> > > Yes, StackTraceElement does not allow null methodName.
> > >
> > > But what about using the empty string, or a string like "<unknown>" if
> it
> > > is not possible to get?
> > >
> > >
> > > On 2017-12-22 20:26, Jeffrey Shaw wrote:
> > >
> > >> I didn't know about clirr, but I can try running that. I tried to not
> > >> break
> > >> any existing public methods.
> > >>
> > >> I created SourceLocation because I think for Scala macros, the method
> > name
> > >> can not exist, but StackTraceElement requires a method name. I'll
> double
> > >> check this.
> > >>
> > >> On Thu, Dec 21, 2017 at 12:40 AM, Ralph Goers <
> > ralph.goers@dslextreme.com
> > >> >
> > >> wrote:
> > >>
> > >> I’m not sure I would be comfortable applying the patch this way. Have
> > you
> > >>> run a clirr report on your changes? I am concerned that this could
> > break
> > >>> customizations that users might have made. What is the reason
> > >>> SourceLocation had to be used instead of StackTraceElement?
> > >>>
> > >>> Ralph
> > >>>
> > >>> On Dec 20, 2017, at 9:58 PM, Jeffrey Shaw <sh...@gmail.com>
> wrote:
> > >>>>
> > >>>> It looks like the location only ever gets the file name, because
> > that's
> > >>>> what StackTraceElement gives. So that's fine.
> > >>>>
> > >>>> I think I'm ready for a formal review. Should I create pull requests
> > on
> > >>>> github for https://github.com/shawjef3/logging-log4j2/tree/message-
> > >>>>
> > >>> location
> > >>>
> > >>>> and https://github.com/shawjef3/logging-log4j-scala/tree/
> > >>>>
> > >>> message-location,
> > >>>
> > >>>> or is there another process?
> > >>>>
> > >>>>
> > >>>> On Wed, Dec 20, 2017 at 2:11 PM, Matt Sicker <bo...@gmail.com>
> > wrote:
> > >>>>
> > >>>> I think that should be configurable in the layout options.
> > >>>>>
> > >>>>> On 20 December 2017 at 13:04, Dominik Psenner <dp...@gmail.com>
> > >>>>>
> > >>>> wrote:
> > >>>
> > >>>>
> > >>>>> Could a compile time environment variable like SrcRootDirectory do
> > the
> > >>>>>>
> > >>>>> job?
> > >>>>>
> > >>>>>>
> > >>>>>> On 20 Dec 2017 7:49 p.m., "Jeffrey Shaw" <sh...@gmail.com>
> > wrote:
> > >>>>>>
> > >>>>>> I got it working using a custom ExtendedLogger instead of mocking.
> > >>>>>>>
> > >>>>>>> It looks like for file name, there are only two options. We can
> > have
> > >>>>>>>
> > >>>>>> the
> > >>>>>
> > >>>>>> file name, or the full path to the file. The path relative to the
> > >>>>>>>
> > >>>>>> project
> > >>>>>
> > >>>>>> root looks impossible to get, unless we look for magic names like
> > >>>>>>>
> > >>>>>> "src".
> > >>>>>
> > >>>>>> Any opinion as to which to use? I'm tempted to use just the file
> > name,
> > >>>>>>> since the full path to the file seems intrusive, and is dependent
> > on
> > >>>>>>>
> > >>>>>> the
> > >>>>>
> > >>>>>> build machine.
> > >>>>>>>
> > >>>>>>> On Wed, Dec 20, 2017 at 11:35 AM, Matt Sicker <bo...@gmail.com>
> > >>>>>>>
> > >>>>>> wrote:
> > >>>>>
> > >>>>>>
> > >>>>>>> It's possible that macros and mocks don't work well together,
> > though
> > >>>>>>>>
> > >>>>>>> that's
> > >>>>>>>
> > >>>>>>>> just a guess.
> > >>>>>>>>
> > >>>>>>>> On 20 December 2017 at 00:00, Jeff Shaw <sh...@gmail.com>
> > wrote:
> > >>>>>>>>
> > >>>>>>>> I should add that manually testing it works.
> > >>>>>>>>>
> > >>>>>>>>> Sent from my phone
> > >>>>>>>>>
> > >>>>>>>>> On Dec 20, 2017, at 12:45 AM, Jeffrey Shaw <shawjef3@gmail.com
> >
> > >>>>>>>>>>
> > >>>>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>>
> > >>>>>>>>>> I added some tests for traced, but they don't pass. The mocks
> > >>>>>>>>>>
> > >>>>>>>>> say,
> > >>>>>
> > >>>>>> "Actually, there were zero interactions with this mock." I could
> > >>>>>>>>>
> > >>>>>>>> use
> > >>>>>
> > >>>>>> some
> > >>>>>>>
> > >>>>>>>> help getting these two tests to work.
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> https://github.com/shawjef3/logging-log4j-scala/blob/
> > >>>>>>>>>>
> > >>>>>>>>> message-location/log4j-api-scala_2.12/src/test/scala/org/
> > >>>>>>>>> apache/logging/log4j/scala/LoggerTest.scala#L574
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On Sun, Dec 17, 2017 at 8:50 PM, Jeffrey Shaw <
> > >>>>>>>>>>>
> > >>>>>>>>>> shawjef3@gmail.com
> > >>>>>
> > >>>>>>
> > >>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> Thanks for the encouragement everyone! I never worked on an
> > >>>>>>>>>>>
> > >>>>>>>>>> Apache
> > >>>>>
> > >>>>>> project before and had no idea what to expect from the community.
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>> I've made some progress. One cool thing I added was a
> `traced`
> > >>>>>>>>>>>
> > >>>>>>>>>> method
> > >>>>>>>
> > >>>>>>>> (source), which does the work you'd want for traceEntry,
> > traceExit,
> > >>>>>>>>>
> > >>>>>>>> and
> > >>>>>>
> > >>>>>>> throwing. It would be cool to add catching as well, but that
> would
> > >>>>>>>>>
> > >>>>>>>> require
> > >>>>>>>>
> > >>>>>>>>> tree traversal, which is beyond me at the moment. I also
> haven't
> > >>>>>>>>>
> > >>>>>>>> figured
> > >>>>>>>
> > >>>>>>>> out how to add the parameter lists. Anyway, an example:
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>> before:
> > >>>>>>>>>>> def f() = {...}
> > >>>>>>>>>>>
> > >>>>>>>>>>> after:
> > >>>>>>>>>>> def f() = logger.traced(Level.INFO) {...}
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Mon, Dec 11, 2017 at 9:55 PM, Matt Sicker <
> boards@gmail.com
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> From the little I've worked with macros (worked more with
> > >>>>>>>>>>>>
> > >>>>>>>>>>> scalameta
> > >>>>>>
> > >>>>>>> and
> > >>>>>>>>
> > >>>>>>>>> shapeless), that looks good so far. If you can add some unit
> > >>>>>>>>>>>>
> > >>>>>>>>>>> tests,
> > >>>>>>
> > >>>>>>> then
> > >>>>>>>>>
> > >>>>>>>>>> we'd be happy to merge!
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On 11 December 2017 at 20:41, Jeffrey Shaw <
> > shawjef3@gmail.com
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>>>> Great news! I'm able to run LoggingApp in the scala api repo
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> without
> > >>>>>>>>
> > >>>>>>>>> it
> > >>>>>>>>>
> > >>>>>>>>>> calling StackLocatorUtil.calcLocation, but it prints the same
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> messages as
> > >>>>>>>>>
> > >>>>>>>>>> before. I have to use my patch to log4j of course.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> See https://github.com/shawjef3/
> logging-log4j-scala/commits/
> > >>>>>>>>>>>>> message-location
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Sun, Dec 10, 2017 at 3:56 PM, Matt Sicker <
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> boards@gmail.com
> > >>>>>
> > >>>>>>
> > >>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>>>> This sounds like it'd make a great addition to the Scala
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>> API!
> > >>>>>
> > >>>>>>
> > >>>>>>>>>>>>>> On 9 December 2017 at 15:36, Jeffrey Shaw <
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>> shawjef3@gmail.com>
> > >>>>>>
> > >>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>>>>> Ralph, I agree with you entirely. My intent for these new
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> log
> > >>>>>>
> > >>>>>>> methods
> > >>>>>>>>>
> > >>>>>>>>>> is
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> that they only be called from compile-time generated
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> code.
> > >>>>>
> > >>>>>>
> > >>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 4:30 PM, Ralph Goers <
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> ralph.goers@dslextreme.com>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> I don’t understand how this is a good idea. To use this
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> you
> > >>>>>>
> > >>>>>>> would
> > >>>>>>>>>
> > >>>>>>>>>> need
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> do something like:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Message msg = new StringMessage(getCaller(), “My
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Message”);
> > >>>>>>
> > >>>>>>> logger.debug(msg);
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Unfortunately the line number would point to the line
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> where
> > >>>>>>
> > >>>>>>> getCaller()
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> is
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> called not to the logger statement.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> I had thought about modifying AbstractLogger to do
> > >>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> message)
> > >>>>>>>
> > >>>>>>>> {
> > >>>>>>>>
> > >>>>>>>>> logIfEnabled(getCaller(), Level.DEBUG, marker,
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> message,
> > >>>>>>
> > >>>>>>> (Throwable)
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> null);
> > >>>>>>>>>>>>>>>> }
> > >>>>>>>>>>>>>>>> instead of the current
> > >>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> message)
> > >>>>>>>
> > >>>>>>>> {
> > >>>>>>>>
> > >>>>>>>>> logIfEnabled(FQCN, Level.DEBUG, marker, message,
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> (Throwable)
> > >>>>>>>>>
> > >>>>>>>>>> null);
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> }
> > >>>>>>>>>>>>>>>> But the amount of changes required to get it into the
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> LogEvent
> > >>>>>>>>
> > >>>>>>>>> was
> > >>>>>>>>>
> > >>>>>>>>>> large.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> OTOH, if we create a CallerLocationMessage that
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> contains
> > >>>>>
> > >>>>>> the
> > >>>>>>>
> > >>>>>>>> StackTraceElement and then have existing Messages
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> extend
> > >>>>>
> > >>>>>> that
> > >>>>>>>
> > >>>>>>>> then we
> > >>>>>>>>>
> > >>>>>>>>>> could
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> store the location in the Message if it is a
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> CallerLocationMessage.
> > >>>>>>>>>
> > >>>>>>>>>> Calling
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> getCaller() in this way would be much better since it
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> is
> > >>>>>
> > >>>>>> at a
> > >>>>>>>
> > >>>>>>>> fixed
> > >>>>>>>>>
> > >>>>>>>>>> depth
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> from the caller.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> With Java 9 this could become:
> > >>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> message)
> > >>>>>>>
> > >>>>>>>> {
> > >>>>>>>>
> > >>>>>>>>> logIfEnabled(stackWalker.walk(
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> s->s.skip(1).findFirst(),
> > >>>>>>>
> > >>>>>>>> Level.DEBUG,
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> marker, message, (Throwable) null);
> > >>>>>>>>>>>>>>>> }
> > >>>>>>>>>>>>>>>> although that would pass a StackFrame instead of a
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> StackTraceElement.
> > >>>>>>>>>
> > >>>>>>>>>> The
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> only problems with this is that there is still some
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> overhead
> > >>>>>>>
> > >>>>>>>> in
> > >>>>>>>>
> > >>>>>>>>> calling
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> StackWalker like this. Also, if this is called from a
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> facade,
> > >>>>>>>
> > >>>>>>>> such as
> > >>>>>>>>>
> > >>>>>>>>>> log4j-slf4j-impl then the number of levels that have to
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> be
> > >>>>>>
> > >>>>>>> skipped
> > >>>>>>>>>
> > >>>>>>>>>> would
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> different.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> I would really prefer if there was some way to capture
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> the
> > >>>>>>
> > >>>>>>> line
> > >>>>>>>>
> > >>>>>>>>> number
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> information for the various loggers when the annotation
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> processor
> > >>>>>>>>>
> > >>>>>>>>>> runs
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> at
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> compile time.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Ralph
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On Dec 9, 2017, at 1:22 PM, Jeffrey Shaw <
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> shawjef3@gmail.com
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Thanks for the link, Mikael. I'll take a look at it.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> I added some plumbing to core to allow clients to
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> pass
> > >>>>>
> > >>>>>> a
> > >>>>>>
> > >>>>>>> StackTraceElement
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> to loggers. I'd like a code review. I'm happy to try
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> other
> > >>>>>>>
> > >>>>>>>> methods.
> > >>>>>>>>>
> > >>>>>>>>>> See
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> following commit.
> > >>>>>>>>>>>>>>>>> https://github.com/shawjef3/logging-log4j2/commit/
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 9c42073e9ca4f25a2f4075b1791eee2893534c54
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 10:09 AM, Mikael Ståldal <
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> mikes@apache.org>
> > >>>>>>>>>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Have you tried the Log4j Scala API?
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> http://logging.apache.org/
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> log4j/2.x/manual/scala-api.
> > >>>>>
> > >>>>>> html
> > >>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>>>>>>>>> It does currently not support this, but it uses
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Scala
> > >>>>>
> > >>>>>> macros, and
> > >>>>>>>>>
> > >>>>>>>>>> this
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> could be added there. But log4j-api and/or
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> log4j-core
> > >>>>>
> > >>>>>> probably
> > >>>>>>>>>
> > >>>>>>>>>> needs
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> adapted as well.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> On 2017-12-09 07:30, Jeffrey Shaw wrote:
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Hello,
> > >>>>>>>>>>>>>>>>>>> I've found that I am able to use Scala macros to
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> provide
> > >>>>>>>
> > >>>>>>>> compile-time
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> source information for log messages. However, I
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> don't
> > >>>>>
> > >>>>>> see
> > >>>>>>>
> > >>>>>>>> a way
> > >>>>>>>>>
> > >>>>>>>>>> to
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> inject
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> this into log4j's logging mechanism.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> I'm wondering if there is something I'm missing, or
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> if
> > >>>>>>
> > >>>>>>> LogEvent's
> > >>>>>>>>>
> > >>>>>>>>>> getSource
> > >>>>>>>>>>>>>>>>>>> method could be duplicated in Message.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> We could then have zero-overhead location
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> information
> > >>>>>
> > >>>>>> in
> > >>>>>>>
> > >>>>>>>> logs.
> > >>>>>>>>>
> > >>>>>>>>>> I'm
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> thinking
> > >>>>>>>>>>>>>>>>>>> that tools other than Scala could also take
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> advantage
> > >>>>>
> > >>>>>> of
> > >>>>>>>
> > >>>>>>>> this.
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> --
> > >>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> Matt Sicker <bo...@gmail.com>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Matt Sicker <bo...@gmail.com>
> > >>>>>
> > >>>>>
> > >>>
> > >>>
> > >>>
> > >>
> > >
> >
>
Re: [log4j] providing sourcewith Message
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Feb 23, 2018 at 7:02 PM, Jeffrey Shaw <sh...@gmail.com> wrote:
> Hi All,
> I spent some more time on this tonight. I've brought my code up to date for
> log4j versions 2 and 3. version 2
> <https://github.com/shawjef3/logging-log4j2/tree/message-
> location-release-2.x>
> version
> 3 <https://github.com/shawjef3/logging-log4j2/tree/message-location>
> Per Ralph Goers and some others I removed SourceLocation and reverted back
> to StackTraceElement.
>
Hello,
Can you create pull requests so we can see better what you are proposing?
Thank you!
Gary
>
> In case this thread is lost in your email, the changes I worked on expose
> the location part of the Message to loggers, so that if the source location
> is known at compile time, it can be added to the log with no runtime cost.
> An example use is the scala loggers
> <https://github.com/shawjef3/logging-log4j-scala> which are implemented
> with macros, and therefore have that information available at no cost to
> the developer, either.
>
> On Sat, Dec 23, 2017 at 2:14 PM, Mikael Ståldal <mi...@apache.org> wrote:
>
> > Yes, StackTraceElement does not allow null methodName.
> >
> > But what about using the empty string, or a string like "<unknown>" if it
> > is not possible to get?
> >
> >
> > On 2017-12-22 20:26, Jeffrey Shaw wrote:
> >
> >> I didn't know about clirr, but I can try running that. I tried to not
> >> break
> >> any existing public methods.
> >>
> >> I created SourceLocation because I think for Scala macros, the method
> name
> >> can not exist, but StackTraceElement requires a method name. I'll double
> >> check this.
> >>
> >> On Thu, Dec 21, 2017 at 12:40 AM, Ralph Goers <
> ralph.goers@dslextreme.com
> >> >
> >> wrote:
> >>
> >> I’m not sure I would be comfortable applying the patch this way. Have
> you
> >>> run a clirr report on your changes? I am concerned that this could
> break
> >>> customizations that users might have made. What is the reason
> >>> SourceLocation had to be used instead of StackTraceElement?
> >>>
> >>> Ralph
> >>>
> >>> On Dec 20, 2017, at 9:58 PM, Jeffrey Shaw <sh...@gmail.com> wrote:
> >>>>
> >>>> It looks like the location only ever gets the file name, because
> that's
> >>>> what StackTraceElement gives. So that's fine.
> >>>>
> >>>> I think I'm ready for a formal review. Should I create pull requests
> on
> >>>> github for https://github.com/shawjef3/logging-log4j2/tree/message-
> >>>>
> >>> location
> >>>
> >>>> and https://github.com/shawjef3/logging-log4j-scala/tree/
> >>>>
> >>> message-location,
> >>>
> >>>> or is there another process?
> >>>>
> >>>>
> >>>> On Wed, Dec 20, 2017 at 2:11 PM, Matt Sicker <bo...@gmail.com>
> wrote:
> >>>>
> >>>> I think that should be configurable in the layout options.
> >>>>>
> >>>>> On 20 December 2017 at 13:04, Dominik Psenner <dp...@gmail.com>
> >>>>>
> >>>> wrote:
> >>>
> >>>>
> >>>>> Could a compile time environment variable like SrcRootDirectory do
> the
> >>>>>>
> >>>>> job?
> >>>>>
> >>>>>>
> >>>>>> On 20 Dec 2017 7:49 p.m., "Jeffrey Shaw" <sh...@gmail.com>
> wrote:
> >>>>>>
> >>>>>> I got it working using a custom ExtendedLogger instead of mocking.
> >>>>>>>
> >>>>>>> It looks like for file name, there are only two options. We can
> have
> >>>>>>>
> >>>>>> the
> >>>>>
> >>>>>> file name, or the full path to the file. The path relative to the
> >>>>>>>
> >>>>>> project
> >>>>>
> >>>>>> root looks impossible to get, unless we look for magic names like
> >>>>>>>
> >>>>>> "src".
> >>>>>
> >>>>>> Any opinion as to which to use? I'm tempted to use just the file
> name,
> >>>>>>> since the full path to the file seems intrusive, and is dependent
> on
> >>>>>>>
> >>>>>> the
> >>>>>
> >>>>>> build machine.
> >>>>>>>
> >>>>>>> On Wed, Dec 20, 2017 at 11:35 AM, Matt Sicker <bo...@gmail.com>
> >>>>>>>
> >>>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>>> It's possible that macros and mocks don't work well together,
> though
> >>>>>>>>
> >>>>>>> that's
> >>>>>>>
> >>>>>>>> just a guess.
> >>>>>>>>
> >>>>>>>> On 20 December 2017 at 00:00, Jeff Shaw <sh...@gmail.com>
> wrote:
> >>>>>>>>
> >>>>>>>> I should add that manually testing it works.
> >>>>>>>>>
> >>>>>>>>> Sent from my phone
> >>>>>>>>>
> >>>>>>>>> On Dec 20, 2017, at 12:45 AM, Jeffrey Shaw <sh...@gmail.com>
> >>>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>> I added some tests for traced, but they don't pass. The mocks
> >>>>>>>>>>
> >>>>>>>>> say,
> >>>>>
> >>>>>> "Actually, there were zero interactions with this mock." I could
> >>>>>>>>>
> >>>>>>>> use
> >>>>>
> >>>>>> some
> >>>>>>>
> >>>>>>>> help getting these two tests to work.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> https://github.com/shawjef3/logging-log4j-scala/blob/
> >>>>>>>>>>
> >>>>>>>>> message-location/log4j-api-scala_2.12/src/test/scala/org/
> >>>>>>>>> apache/logging/log4j/scala/LoggerTest.scala#L574
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Sun, Dec 17, 2017 at 8:50 PM, Jeffrey Shaw <
> >>>>>>>>>>>
> >>>>>>>>>> shawjef3@gmail.com
> >>>>>
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Thanks for the encouragement everyone! I never worked on an
> >>>>>>>>>>>
> >>>>>>>>>> Apache
> >>>>>
> >>>>>> project before and had no idea what to expect from the community.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> I've made some progress. One cool thing I added was a `traced`
> >>>>>>>>>>>
> >>>>>>>>>> method
> >>>>>>>
> >>>>>>>> (source), which does the work you'd want for traceEntry,
> traceExit,
> >>>>>>>>>
> >>>>>>>> and
> >>>>>>
> >>>>>>> throwing. It would be cool to add catching as well, but that would
> >>>>>>>>>
> >>>>>>>> require
> >>>>>>>>
> >>>>>>>>> tree traversal, which is beyond me at the moment. I also haven't
> >>>>>>>>>
> >>>>>>>> figured
> >>>>>>>
> >>>>>>>> out how to add the parameter lists. Anyway, an example:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> before:
> >>>>>>>>>>> def f() = {...}
> >>>>>>>>>>>
> >>>>>>>>>>> after:
> >>>>>>>>>>> def f() = logger.traced(Level.INFO) {...}
> >>>>>>>>>>>
> >>>>>>>>>>> On Mon, Dec 11, 2017 at 9:55 PM, Matt Sicker <boards@gmail.com
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> From the little I've worked with macros (worked more with
> >>>>>>>>>>>>
> >>>>>>>>>>> scalameta
> >>>>>>
> >>>>>>> and
> >>>>>>>>
> >>>>>>>>> shapeless), that looks good so far. If you can add some unit
> >>>>>>>>>>>>
> >>>>>>>>>>> tests,
> >>>>>>
> >>>>>>> then
> >>>>>>>>>
> >>>>>>>>>> we'd be happy to merge!
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 11 December 2017 at 20:41, Jeffrey Shaw <
> shawjef3@gmail.com
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>> Great news! I'm able to run LoggingApp in the scala api repo
> >>>>>>>>>>>>>
> >>>>>>>>>>>> without
> >>>>>>>>
> >>>>>>>>> it
> >>>>>>>>>
> >>>>>>>>>> calling StackLocatorUtil.calcLocation, but it prints the same
> >>>>>>>>>>>>>
> >>>>>>>>>>>> messages as
> >>>>>>>>>
> >>>>>>>>>> before. I have to use my patch to log4j of course.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> See https://github.com/shawjef3/logging-log4j-scala/commits/
> >>>>>>>>>>>>> message-location
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Sun, Dec 10, 2017 at 3:56 PM, Matt Sicker <
> >>>>>>>>>>>>>
> >>>>>>>>>>>> boards@gmail.com
> >>>>>
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>> This sounds like it'd make a great addition to the Scala
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> API!
> >>>>>
> >>>>>>
> >>>>>>>>>>>>>> On 9 December 2017 at 15:36, Jeffrey Shaw <
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> shawjef3@gmail.com>
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>>> Ralph, I agree with you entirely. My intent for these new
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> log
> >>>>>>
> >>>>>>> methods
> >>>>>>>>>
> >>>>>>>>>> is
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> that they only be called from compile-time generated
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> code.
> >>>>>
> >>>>>>
> >>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 4:30 PM, Ralph Goers <
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> ralph.goers@dslextreme.com>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I don’t understand how this is a good idea. To use this
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> you
> >>>>>>
> >>>>>>> would
> >>>>>>>>>
> >>>>>>>>>> need
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> do something like:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Message msg = new StringMessage(getCaller(), “My
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Message”);
> >>>>>>
> >>>>>>> logger.debug(msg);
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Unfortunately the line number would point to the line
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> where
> >>>>>>
> >>>>>>> getCaller()
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> called not to the logger statement.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I had thought about modifying AbstractLogger to do
> >>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> message)
> >>>>>>>
> >>>>>>>> {
> >>>>>>>>
> >>>>>>>>> logIfEnabled(getCaller(), Level.DEBUG, marker,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> message,
> >>>>>>
> >>>>>>> (Throwable)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> null);
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>> instead of the current
> >>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> message)
> >>>>>>>
> >>>>>>>> {
> >>>>>>>>
> >>>>>>>>> logIfEnabled(FQCN, Level.DEBUG, marker, message,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> (Throwable)
> >>>>>>>>>
> >>>>>>>>>> null);
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>> But the amount of changes required to get it into the
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> LogEvent
> >>>>>>>>
> >>>>>>>>> was
> >>>>>>>>>
> >>>>>>>>>> large.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> OTOH, if we create a CallerLocationMessage that
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> contains
> >>>>>
> >>>>>> the
> >>>>>>>
> >>>>>>>> StackTraceElement and then have existing Messages
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> extend
> >>>>>
> >>>>>> that
> >>>>>>>
> >>>>>>>> then we
> >>>>>>>>>
> >>>>>>>>>> could
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> store the location in the Message if it is a
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> CallerLocationMessage.
> >>>>>>>>>
> >>>>>>>>>> Calling
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> getCaller() in this way would be much better since it
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> is
> >>>>>
> >>>>>> at a
> >>>>>>>
> >>>>>>>> fixed
> >>>>>>>>>
> >>>>>>>>>> depth
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> from the caller.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> With Java 9 this could become:
> >>>>>>>>>>>>>>>> public void debug(final Marker marker, final String
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> message)
> >>>>>>>
> >>>>>>>> {
> >>>>>>>>
> >>>>>>>>> logIfEnabled(stackWalker.walk(
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> s->s.skip(1).findFirst(),
> >>>>>>>
> >>>>>>>> Level.DEBUG,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> marker, message, (Throwable) null);
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>> although that would pass a StackFrame instead of a
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> StackTraceElement.
> >>>>>>>>>
> >>>>>>>>>> The
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> only problems with this is that there is still some
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> overhead
> >>>>>>>
> >>>>>>>> in
> >>>>>>>>
> >>>>>>>>> calling
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> StackWalker like this. Also, if this is called from a
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> facade,
> >>>>>>>
> >>>>>>>> such as
> >>>>>>>>>
> >>>>>>>>>> log4j-slf4j-impl then the number of levels that have to
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> be
> >>>>>>
> >>>>>>> skipped
> >>>>>>>>>
> >>>>>>>>>> would
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> different.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I would really prefer if there was some way to capture
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> the
> >>>>>>
> >>>>>>> line
> >>>>>>>>
> >>>>>>>>> number
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> information for the various loggers when the annotation
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> processor
> >>>>>>>>>
> >>>>>>>>>> runs
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> at
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> compile time.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Ralph
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Dec 9, 2017, at 1:22 PM, Jeffrey Shaw <
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> shawjef3@gmail.com
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Thanks for the link, Mikael. I'll take a look at it.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I added some plumbing to core to allow clients to
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> pass
> >>>>>
> >>>>>> a
> >>>>>>
> >>>>>>> StackTraceElement
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> to loggers. I'd like a code review. I'm happy to try
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> other
> >>>>>>>
> >>>>>>>> methods.
> >>>>>>>>>
> >>>>>>>>>> See
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> following commit.
> >>>>>>>>>>>>>>>>> https://github.com/shawjef3/logging-log4j2/commit/
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 9c42073e9ca4f25a2f4075b1791eee2893534c54
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Sat, Dec 9, 2017 at 10:09 AM, Mikael Ståldal <
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> mikes@apache.org>
> >>>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Have you tried the Log4j Scala API?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> http://logging.apache.org/
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> log4j/2.x/manual/scala-api.
> >>>>>
> >>>>>> html
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>>>>>>>>> It does currently not support this, but it uses
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Scala
> >>>>>
> >>>>>> macros, and
> >>>>>>>>>
> >>>>>>>>>> this
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> could be added there. But log4j-api and/or
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> log4j-core
> >>>>>
> >>>>>> probably
> >>>>>>>>>
> >>>>>>>>>> needs
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> adapted as well.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 2017-12-09 07:30, Jeffrey Shaw wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Hello,
> >>>>>>>>>>>>>>>>>>> I've found that I am able to use Scala macros to
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> provide
> >>>>>>>
> >>>>>>>> compile-time
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> source information for log messages. However, I
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> don't
> >>>>>
> >>>>>> see
> >>>>>>>
> >>>>>>>> a way
> >>>>>>>>>
> >>>>>>>>>> to
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> inject
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> this into log4j's logging mechanism.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I'm wondering if there is something I'm missing, or
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> if
> >>>>>>
> >>>>>>> LogEvent's
> >>>>>>>>>
> >>>>>>>>>> getSource
> >>>>>>>>>>>>>>>>>>> method could be duplicated in Message.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> We could then have zero-overhead location
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> information
> >>>>>
> >>>>>> in
> >>>>>>>
> >>>>>>>> logs.
> >>>>>>>>>
> >>>>>>>>>> I'm
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> thinking
> >>>>>>>>>>>>>>>>>>> that tools other than Scala could also take
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> advantage
> >>>>>
> >>>>>> of
> >>>>>>>
> >>>>>>>> this.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Matt Sicker <bo...@gmail.com>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Matt Sicker <bo...@gmail.com>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>
> >
>