Details
-
Task
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
I've been trying to overwrite log configuration programmatically with new configuration when my config file in s3 changes. I've spent a day chasing various LoggerContexts through the code, and I still don't understand why there are so many. There's one I set from my config, and there's a "default" one and there's a thread-local one. If these are explained somewhere, I couldn't find it.
What I have figured out is if one reconfigures the wrong one, one does not get the behavior one was hoping for. And there's no obvious way to list them all or to simply clobber them all and start fresh.
LoggerContext's Javadoc says it's "the anchor for the logging system." But then there's a ContextAnchor class which claims to be the "anchor for the ThreadContext." How many anchors does this ship have? What's the relationship between the ThreadContext and LoggerContexts?
LogManager.getContext() bears this inscrutable comment:
currentContext if false the LoggerContext appropriate for the caller of this method is returned. For example, in a web application if the caller is a class in WEB-INF/lib then one LoggerContext may be returned and if the caller is a class in the container's classpath then a different LoggerContext may be returned. If true then only a single LoggerContext will be returned.
Of course, the method always returns a single LoggerContext. Whether it's "appropriate for the caller" obviously depends on what the caller is trying to do, which is why there's a parameter, right? Could you please explain what context is "current" and what's "not current" so schmoes like me can figure out how to call it?