When initial log4j appender, PaxLoggingServiceImpl.updated will hold a readwrite lock, during the initial (AppenderSkeleton.activateOptions), if a new thread start, and the new started thread try to use org.slf4j.Logger for log, then it will call PaxLoggerImpl.setDelegateContext, which also require the same lock, the it is the deadlock.
It will happened when initial some DB connection in AppenderSkeleton.activateOptions, and the third part lib may start new thread for some tasks.
Do we really need the lock?
This is very special case. I didn't expect that appender initialization would actually use logging that's being reconfigured. Checking Log4J1, Log4J2 and Logback, all internal code use some special "internal log" or "LogLog" classes that in simplest case call System.out.println().
My proposal is org.ops4j.pax.logging.useLocks option, which defaults to true, but may be changed to false for your case. It's a PID property.
I'll fix this issue by implementing this property and turning off the locking if org.ops4j.pax.logging.useLocks=false.
If you have other suggestions, please let me know.
Fixed here by making locking configurable.
If you want to skip locking, just add this to Karaf's etc/system.properties or etc/config.properties:
or this to etc/org.ops4j.pax.logging.cfg (the PID):
by default (when not specified), the locks will be used.