> On Jul 10, 2022, at 9:36 PM, Piotr P. Karwasz wrote:
>
> Hi Volkan,
>
> On Sun, 10 Jul 2022 at 21:47, Volkan Yazıcı wrote:
>> Piotr, what is your take on my claim that this optimization won't work for
>> bridges (SLF4J, log4j-1.2-api, etc.)?
>
> If you are using a `ThreadLocal` to store t
Hi Volkan,
On Sun, 10 Jul 2022 at 21:47, Volkan Yazıcı wrote:
> Piotr, what is your take on my claim that this optimization won't work for
> bridges (SLF4J, log4j-1.2-api, etc.)?
If you are using a `ThreadLocal` to store the location information
just before a logging call, you can use it before
Lookking at master I see the following:
./log4j-jpl/src/main/java/module-info.java
./log4j-api-test/src/main/java9/module-info.java
./log4j-plugins/src/main/java/module-info.java
./log4j-api/src/main/java/module-info.java
./log4j-layout-template-json/src/main/java/module-info.java
./log4j-plugins-
I should note that It would of course be possible to support using our own
@Log4j2 annotation and support Lombok’s annotation if it is present, but
if we do not require Lombok we are almost certainly going to end up creating
our own version of
https://github.com/projectlombok/lombok/blob/master
Yes, I read the code and I don’t like it. There is no reason to create the
ThreadLocal.
You have some magic code that isn’t demonstrated in your POC to create
a StackTraceElement. That is actually the hard part. Setting it into a
ThreadLocal so it can be used later will work but really doesn’
Might I ask why? lots of people use it and adding the ability to enhance the
logging just by adding a dependency seems like a win to me.
Ralph
> On Jul 10, 2022, at 2:27 PM, Volkan Yazıcı wrote:
>
> -1 from me for a Log4j functionality depending on Lombok.
>
>> On Sun, Jul 10, 2022 at 11:17
-1 from me for a Log4j functionality depending on Lombok.
On Sun, Jul 10, 2022 at 11:17 PM Ralph Goers
wrote:
> https://www.baeldung.com/lombok-custom-annotation seems to imply that we
> could
> add this support by extending Lombok.
>
> Ralph
>
> > On Jul 10, 2022, at 1:58 PM, Ralph Goers
> wro
Ralph, have you read the sources I have shared in the email? The only
runtime cost in my example was a thread-local set and get. I use the TL as
an indirect comm. medium to pass the source location information to the
logger and it works. Given you said "I don’t see how it can work", can you
give an
On Sun, Jul 10, 2022 at 4:58 PM Ralph Goers wrote:
>
> Because I don’t see how it can work.
>
> A ThreadLocal is a run time construct. If you are saving location information
> in
> a ThreadLocal then it is only good for the life of the request and/or thread.
> But
> the location information will
https://www.baeldung.com/lombok-custom-annotation seems to imply that we could
add this support by extending Lombok.
Ralph
> On Jul 10, 2022, at 1:58 PM, Ralph Goers wrote:
>
> Because I don’t see how it can work.
>
> A ThreadLocal is a run time construct. If you are saving location informat
Because I don’t see how it can work.
A ThreadLocal is a run time construct. If you are saving location information
in
a ThreadLocal then it is only good for the life of the request and/or thread.
But
the location information will never change. It is fixed even before the Class
is loaded.
So
Why do you prefer `withLocation()` compared to the thread-local approach?
On Sun, Jul 10, 2022 at 9:55 PM Ralph Goers
wrote:
> This is exactly why I believe we should only support LogBuilder as it
> already
> has withLocation(). I see no point in adding the parameter to all the
> non-fluent
> va
On Sat, Jul 9, 2022 at 8:16 PM Ralph Goers
wrote:
> 1. I’d like to not have to generate new source code for every class doing
> logging.
> I am not sure how Lombok does it but I will want to investigate that.
>
I have studied (at least tried to!) Lombok sources a bit... They are pretty
arcane. N
This is exactly why I believe we should only support LogBuilder as it already
has withLocation(). I see no point in adding the parameter to all the
non-fluent
variations.
To work, the location must be passed as a parameter on the logging API call.
Thus it won’t work for Log4j 1 or SLF4J.
Ralp
Indeed supporting both static and dynamic weaving seems like the ideal
approach. (SPI-Fly is an interesting one. My OSGi illiteracy blocked me
from wrapping my mind around all of its details. Nevertheless, I think I
get the gist of it.) For both functionalities, we need to receive a package
list to
15 matches
Mail list logo
