Re: Fwd: Temporarily store/restore the current configuration

So I took a closer look and even found another place in my code where
I previously had the same problem... setConfiguration() won't work in
my
example code - ever. Seems like Configuration objects are not meant to
be reused at all. They have an internal state (lifecycle) and, once
stopped, they're effectively unusable. So, when you try to do this:

var ctx = (LoggerContext) LogManager.getContext(false);
var current = ctx.getConfiguration();
try {
  ctx.setConfiguration(myQuietConfiguration);
  otherCode();
} finally {
  ctx.setConfiguration(current);
}

what happens is the "current" configuration is stopped and internally
will never reinitialize all the appenders (and internals) again.
Here's why:

https://github.com/apache/logging-log4j2/blob/0043e9238af0efd9dbce462463e0fa1bf14e35b0/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AbstractConfiguration.java#L290-L292

The initialization routine calls doConfigure which in turn does all
the tricky stuff adding appenders, etc. I'm not sure whether this is
intentional or not but if Configuration objects are not meant for
reuse then I'd throw an exception if they're in illegal state (in
ctx.setConfiguration)... this would make it much easier to figure out.
And if there should be a way to reuse them then I think it's a bug
somewhere because it currently doesn't work (even on the simplest of
examples).

Incidentally, you can reinitialize the configuration from scratch -
then everything works like a charm, no need to call updateLoggers
(it's done internally):

LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
URI previousConfiguration = ctx.getConfigLocation();
ctx.setConfigLocation(newConfigLocation);
try {
  otherCode();
} finally {
  ctx.setConfigLocation(previousConfiguration);
}

Of course it requires re-parsing the configuration multiple times so
is not ideal.

I'd love to hear from the developers about what they think in terms of
the Configuration object reuse/ lifecycle.

Dawid


On Tue, Nov 9, 2021 at 10:30 AM Dawid Weiss <[email protected]> wrote:
>
>
> Hi Chris!
>
> Small world, eh? :)
>
>> Dawid: The piece you're missing is LoggerContext.updateLoggers(...)
>
>
> I did that too... I think. I have dynamic appender redirection (teeing) in another place - this is where updateLoggers() is used. But this time I wanted to swap out entire configurations (this may involve different logger setup, appenders, etc.) and could't make it work properly, no matter what. I'll go back to the drawing board and retry.
>
> I do understand it's not a typical use-case but it's actually a fairly frequent thing that happens in integration tests when you don't want to see stuff
> that is tested (well, maybe you do, but only if something fails).
>
> Dawid