Hi Remko,
I had thought exactly the same thing until I drafted my email, but in doing so
I came to the realization (hopefully correctly) that the problem is the direct
result of jul.LogManager synchronizing initialization, so if we can avoid log4j
initialization within the locked region and def
Hi Carter,
I’m not sure if I understand the problem and your proposed solution fully
but it sounds like it may reduce the probability of a deadlock occurring
but not fully eliminate the possibility.
(Without looking at the code, away from pc),
would it be an idea to expose a status (or perhaps we
As one of the biggest tinkerers in log4j-jul myself, I have to say
that sounds like a decent idea. I haven't revisited my assumptions in
that module in a long time as I haven't had to integrate with JUL
lately (at least outside Jenkins, but there I'm using log4j-audit in a
plugin which doesn't inte
Hi Friends,
I've been thinking about ways that we can solve LOG4J2-2965 which is a deadlock
between JUL init and log4j init, both of which use synchronization. The crux of
the issue is that JUL LogManager uses a synchronized block to initialize, which
requests log4j-core initialization and log4
