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 interact with the JUL config), so I have no objections to that.
On Sun, 6 Dec 2020 at 17:16, Carter Kozak <cko...@ckozak.net> wrote: > > 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 log4j-core attempts > to initialize the JUL LogManager if Disruptor is used. If One thread attempts > to initialize JUL directly while another begins to initialize log4j via a > non-jul path, we may deadlock. I have an example stack trace in the ticket. > > This problem is specific to JUL due to the synchronization incurred while > initializing our LogManager via java.util.logging.LogManager, so we could > update our JUL implementation to lazily connect jul logger instances to the > log4j framework. Instead of reaching out to the loggercontext when JUL > loggers are requested, we can initialize the delegate log4j components upon > the first interaction rather than when the logger is requested, decoupling > JUL LogManager initialization from log4j init so it behaves like other > bindings. We would need to be careful to track the original caller data to > avoid associating JUL loggers with incorrect log4j contexts. > > What do you think? Any alternative ideas or suggestions? > > Thanks, > Carter
