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 2017/12/09 06:30:02 UTC
[log4j] providing sourcewith Message
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.
Thanks,
Jeff
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>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>
> >
>
Re: [log4j] providing sourcewith Message
Posted by Jeffrey Shaw <sh...@gmail.com>.
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 Mikael Ståldal <mi...@apache.org>.
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 <ra...@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 Matt Sicker <bo...@gmail.com>.
A normal GitHub PR works. Have you signed an ICLA for Apache yet? And yes,
we'll need to compare API changes to verify it doesn't cause BC problems.
On 20 December 2017 at 23:40, Ralph Goers <ra...@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>
> >>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [log4j] providing sourcewith Message
Posted by Matt Sicker <bo...@gmail.com>.
Is there no mangled method name generated? For example, inside a lambda,
the function might be called Foo$1 like with Java 8 lambdas.
On 22 December 2017 at 14:18, Ralph Goers <ra...@dslextreme.com>
wrote:
> I am concerned because users can create customer Appenders and Layouts
> that will be affected by a change to the signature of getSource() in the
> LogEvent. I suspect that there are other things that use the LogEvent (the
> Logging Server? Lillith?) that would be impacted by this.
>
> Ralph
>
> > On Dec 22, 2017, at 12:26 PM, Jeffrey Shaw <sh...@gmail.com> 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>
> >>>>
> >>
> >>
> >>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [log4j] providing sourcewith Message
Posted by Ralph Goers <ra...@dslextreme.com>.
I am concerned because users can create customer Appenders and Layouts that will be affected by a change to the signature of getSource() in the LogEvent. I suspect that there are other things that use the LogEvent (the Logging Server? Lillith?) that would be impacted by this.
Ralph
> On Dec 22, 2017, at 12:26 PM, Jeffrey Shaw <sh...@gmail.com> 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 <ra...@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>.
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 <ra...@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 Ralph Goers <ra...@dslextreme.com>.
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>.
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 Matt Sicker <bo...@gmail.com>.
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 <bo...@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 <sh...@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 Dominik Psenner <dp...@gmail.com>.
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 <sh...@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 <bo...@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 <sh...@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 <bo...@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 <sh...@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>
> >
>
Re: [log4j] providing sourcewith Message
Posted by Jeffrey Shaw <sh...@gmail.com>.
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 <sh...@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 <bo...@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 <sh...@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 <bo...@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 <sh...@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>
>
Re: [log4j] providing sourcewith Message
Posted by Matt Sicker <bo...@gmail.com>.
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 <sh...@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 <bo...@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 <sh...@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 <bo...@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 <sh...@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>
Re: [log4j] providing sourcewith Message
Posted by Jeff Shaw <sh...@gmail.com>.
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 <sh...@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 <bo...@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 <sh...@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 <bo...@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 <sh...@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 <sh...@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 <mi...@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>
>>
>
Re: [log4j] providing sourcewith Message
Posted by Jeffrey Shaw <sh...@gmail.com>.
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 <sh...@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
> <https://github.com/shawjef3/logging-log4j-scala/commit/281778ecdcb644c4d79cb34910ad0097a28a5fae#diff-e9515b71e3d44dedb5a56082c18f1ff6R46>),
> 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 <bo...@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 <sh...@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 <bo...@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 <sh...@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 <sh...@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>
>>
>
>
Re: [log4j] providing sourcewith Message
Posted by Jeffrey Shaw <sh...@gmail.com>.
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
<https://github.com/shawjef3/logging-log4j-scala/commit/281778ecdcb644c4d79cb34910ad0097a28a5fae#diff-e9515b71e3d44dedb5a56082c18f1ff6R46>),
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 <bo...@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 <sh...@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 <bo...@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 <sh...@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 <sh...@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>
>
Re: [log4j] providing sourcewith Message
Posted by Matt Sicker <bo...@gmail.com>.
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 <sh...@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 <bo...@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 <sh...@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 <sh...@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 <mi...@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>
Re: [log4j] providing sourcewith Message
Posted by Jeffrey Shaw <sh...@gmail.com>.
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 <bo...@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 <sh...@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 <ra...@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 <sh...@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 <mi...@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>
>
Re: [log4j] providing sourcewith Message
Posted by Matt Sicker <bo...@gmail.com>.
This sounds like it'd make a great addition to the Scala API!
On 9 December 2017 at 15:36, Jeffrey Shaw <sh...@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 <ra...@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 <sh...@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 <mi...@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>
Re: [log4j] providing sourcewith Message
Posted by Jeffrey Shaw <sh...@gmail.com>.
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 <ra...@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 <sh...@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 <mi...@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.
> >>>
> >>
>
>
Re: [log4j] providing sourcewith Message
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <sh...@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 <mi...@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.
>>>
>>
Re: [log4j] providing sourcewith Message
Posted by Jeffrey Shaw <sh...@gmail.com>.
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 <mi...@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.
>>
>
Re: [log4j] providing sourcewith Message
Posted by Mikael Ståldal <mi...@apache.org>.
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.
Re: [log4j] providing sourcewith Message
Posted by Jeffrey Shaw <sh...@gmail.com>.
I got the idea from https://github.com/outr/scribe, and I wanted to adapt
it for log4j. Basically the idea is that I'd create a wrapper for Loggers
that provides information from the compiler for source code.
See
https://github.com/outr/scribe/blob/master/shared/src/main/scala/scribe/Macros.scala#L35
for one example of how this can work. It's a bit dense, but basically you
can see that there's a context, and it's used to generate some logging code
that includes the class name, method name, and line number. Something
similar could help Log4j skip any reflection or stack analysis it would use
to get the same information.
On Sat, Dec 9, 2017 at 2:31 AM, Remko Popma <re...@gmail.com> wrote:
> Interesting!
> Can you point to an example of how this works? I’m trying to understand
> what changes would be required.
>
> Remko
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
> > On Dec 9, 2017, at 15:30, Jeffrey Shaw <sh...@gmail.com> 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.
> >
> > Thanks,
> > Jeff
>
Re: [log4j] providing sourcewith Message
Posted by Remko Popma <re...@gmail.com>.
Interesting!
Can you point to an example of how this works? I’m trying to understand what changes would be required.
Remko
(Shameless plug) Every java main() method deserves http://picocli.info
> On Dec 9, 2017, at 15:30, Jeffrey Shaw <sh...@gmail.com> 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.
>
> Thanks,
> Jeff