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
wrote:
> I don’t understand how this is a good idea. To use this you would need to
> do something like:
>
> Message msg
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 thoug
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/9c42073e9ca4f25a2f4075b179
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 wro
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#