Good morning!
On 4/7/22 23:59, Kasper Nielsen wrote:
Hi Michael,
I don't really have an opinion on how you obtain a logger. But one
particular
use-case I've had was that I would like to perform some access checks based
on the module of the caller. Something similar to how Panama checks for
native access:
Reflection.ensureNativeAccess(Reflection.getCallerClass());
Hmh, but wouldn't it be sufficient to perform these checks at
initialization time?
On 4/7/22 21:01, Ralph Goers wrote:
> In Log4j’s case there are two places that accessing the stack comes
into play:
> 1. Obtaining a Logger .
> 2. Logging an event and including the caller’s location information.
>
> To be honest, what sucks for Logging frameworks is that we really want
> access to the location information at compile time such that the overhead
> to include it would be zero. I’ve never understood why Java doesn’t
include it.
That I totally agree! Having the exact line number in the log statement
would be a huge win.
But to be honest, Reflection::getCallerClass wouldn't help either.
I agree that such an inlined statement would be a huge win.
But to also put this into relation: From my opinion, logging frameworks
should be most performant in the cases where they are *not* logging. Or
in those cases where you would log a lot even in production environment
- like for financial calculations - the exact line number isn't that
relevant any more.
But that's just my opinion.
-Michael
