-
Enhancement
-
Resolution: Unresolved
-
P4
-
8
-
None
There has been a long email thread on core-libs-dev about deadlocks happening when Logger was recursively invoked by a custom formatter.
However there are more subtle cases where the same kind of deadlocks could occur: for instance, when using a simple formatter, a recursive call to Logger may occur if one of the message parameters passed to the formatter is an object whose toString() invokes a methods that happens to do some logging.
I believe we should at least recommend - as a general programming rule - to avoid calling Logger from within toString(), hashCode(), equals(), or j.u.l.Formatter. We should also investigate whether we could make handlers safer wrt to recursive logging.
However there are more subtle cases where the same kind of deadlocks could occur: for instance, when using a simple formatter, a recursive call to Logger may occur if one of the message parameters passed to the formatter is an object whose toString() invokes a methods that happens to do some logging.
I believe we should at least recommend - as a general programming rule - to avoid calling Logger from within toString(), hashCode(), equals(), or j.u.l.Formatter. We should also investigate whether we could make handlers safer wrt to recursive logging.