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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> wrote: >> >> >> >> Hi, just hoping to get some eyes on this again. >> >> >> >>> On Fri, Feb 23, 2018 at 10:43 PM, Jeffrey Shaw <[email protected]> >> 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 <[email protected]> >> wrote: >> >>>> >> >>>> done! https://github.com/apache/logging-log4j2/pull/151 >> >>>> >> >>>> On Fri, Feb 23, 2018 at 9:22 PM, Gary Gregory < >> [email protected]> >> >>>> wrote: >> >>>> >> >>>>> On Fri, Feb 23, 2018 at 7:02 PM, Jeffrey Shaw <[email protected]> >> >>>>> 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 <[email protected]> >> >>>>> 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 < >> >>>>>> [email protected] >> >>>>>>>>> >> >>>>>>>> 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 <[email protected]> >> >>>>> 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 <[email protected] >> > >> >>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>> I think that should be configurable in the layout options. >> >>>>>>>>>>> >> >>>>>>>>>>> On 20 December 2017 at 13:04, Dominik Psenner < >> >>>>> [email protected]> >> >>>>>>>>>>> >> >>>>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>> Could a compile time environment variable like >> SrcRootDirectory >> >>>>> do >> >>>>>> the >> >>>>>>>>>>>> >> >>>>>>>>>>> job? >> >>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> On 20 Dec 2017 7:49 p.m., "Jeffrey Shaw" <[email protected] >> > >> >>>>>> 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 < >> >>>>> [email protected]> >> >>>>>>>>>>>>> >> >>>>>>>>>>>> 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 < >> [email protected]> >> >>>>>> wrote: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> I should add that manually testing it works. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Sent from my phone >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> On Dec 20, 2017, at 12:45 AM, Jeffrey Shaw < >> >>>>> [email protected]> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> 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 < >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> [email protected] >> >>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>>> 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 < >> >>>>> [email protected] >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>> 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 < >> >>>>>> [email protected] >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>> 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 < >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> [email protected] >> >>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> This sounds like it'd make a great addition to the >> Scala >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> API! >> >>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> On 9 December 2017 at 15:36, Jeffrey Shaw < >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> [email protected]> >> >>>>>>>>>>>> >> >>>>>>>>>>>>> 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 < >> >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> [email protected]> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> 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 < >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> [email protected] >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> 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 < >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> [email protected]> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> 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 <[email protected]> >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> -- >> >>>>>>>>>>>>>>>>>> Matt Sicker <[email protected]> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> -- >> >>>>>>>>>>>>>> Matt Sicker <[email protected]> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> -- >> >>>>>>>>>>> Matt Sicker <[email protected]> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>> >> >>>> >> >>>> >> >>> >> > >
