Hi Volkan, On Sat, 9 Jul 2022 at 12:05, Volkan Yazıcı <vol...@yazi.ci> wrote: > I think we can extend this experiment to implement zero-cost source > location capture for Log4j. Though I will appreciate your help on some > loose ends. Assuming we have a bullet-proof mechanism to inline source > location capture given a class, what is the right way to ship this? As a > Maven plugin that kicks in at compile time? Wouldn't that make this feature > impossible to use without recompiling user sources? As a runtime utility? > If so, what about the cost of classpath scanning & weaving? If the bytecode > weaving only intercepts at Log4j API calls, this won't work for Log4j 1 > bridge, SLF4J, or any other indirect access to the Log4j API. What do you > think? I have used a thread-local to pass the source location to the > caller, is there a better alternative? (Putting aside the dynamic-scoped > variables to be shipped with Loom.)
Great idea. I think that we can provide both a static and dynamic weaver from the same code (cf. SPI-Fly: https://github.com/apache/aries/tree/trunk/spi-fly). Developers would be advised to statically weave their artifacts, while system administrators could do it during runtime. The usage of a `ThreadLocal` seems Ok to me. Alternatively we could add some parameters to the `Logger.log` calls, but this would mean 4 additional parameters on each simple call and we'll end up using the `Logger.log` method with an Object array. Piotr
