Thanks for confirming, Ralph. I'd seriously consider adding a
state-check assertion in the code to just throw something reasonable
at folks like me who try to do such hacks - would save tons of time
and code-digging. :)
Dawid
On Tue, Nov 9, 2021 at 4:57 PM Ralph Goers <ralph.go...@dslextreme.com> wrote:
>
> 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 <dawid.we...@gmail.com> 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 <dawid.we...@gmail.com> 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: log4j-user-unsubscr...@logging.apache.org
> > For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
