Re: Temporarily store/restore the current configuration

Sorry for not replying sooner but yes, that was going to be my response. Once 
stopped a Configuration cannot be restarted. 

I have wanted to be able to provide an easy way to clone a configuration but 
have never gotten around to it. This would be useful if you have modified the c
onfiguration after it initialized 

We have also discussed having the configuration be able to serialize itself back 
into a configuration file but again, no one has attempted to do it.

Ralph

> On Nov 9, 2021, at 5:15 AM, Dawid Weiss <[email protected]> wrote:
> 
> 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
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
>