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 <[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/logging-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]> >
