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 > <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 <[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/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]> >> > > >> > >> >> >> >> -- >> Matt Sicker <[email protected]> >> > >
