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.
>>>
>>
