On Sun, Dec 19, 2021 at 10:25 AM Christopher Schultz <ch...@christopherschultz.net> wrote: > > Gary, > > On 12/17/21 22:18, Gary Gregory wrote: > > Log4j 2 can reconfigure itself when its configuration file changes by > > using the monitorInterval attribute, for example: > > > > <Configuration name="ConfigTest" status="ERROR" monitorInterval="5"> > > > > See https://logging.apache.org/log4j/2.x/manual/configuration.html > > > > For programmatic reconfiguration, you can use > > org.apache.logging.log4j.core.config.Configurator. > > > > I hope that gives you a place to start. > > I'll give it a shot. What we are doing is loading a default > configuration (like "log to console") on startup and then, after reading > a client-specific configuration file, applying that configuration to the > already-initialized logging system. We can't predict the name of the > config file at-or-before startup and we don't want to re-write the > default configuration. I'm sure we can pass either a new file path to a > Configurator and/or have it an in-memory configuration. We don't need to > monkey-around with the in-memory Logger or Appender objects; just tell > the logging system to reconfigure. > > I have seen in the log4j debug logs that it knows how to "reconfigure" > because it does it pretty much right away after loading. So I think I > just need to tell it to reload again, but with a different set of configs. >
You're on the right track, Chris. Please see the Configurator.initialize() APIs and for an advance use case, see also org.apache.logging.log4j.junit.LoggerContextRule Gary > Thanks, > -chris > > > On Thu, Dec 16, 2021 at 11:02 AM Christopher Schultz > > <ch...@christopherschultz.net> wrote: > >> > >> All, > >> > >> My understanding is that under many circumstances, migrating from log4j > >> 1.x -> 2.x is nearly as easy as simply upgrading the JAR file (and using > >> the migration bridge library), but there are some other restrictions as > >> noted here: > >> > >> https://logging.apache.org/log4j/2.x/manual/migration.html > >> > >> In various programs and services, we are using log4j 1.x in a way that > >> might be a little hacky. Specifically, we have a set of classes which > >> allow appenders and loggers to be reconfigured at runtime using calls > >> such as Appender(Skeleton).setThreshold. Is there a way to do this kind > >> of thing in log4j 2.x? > >> > >> We are also doing things like starting up with a hard-coded > >> configuration to print-to-console and then, after loading a > >> configuration from elsewhere (which may fail, hence logging to the > >> console), re-initialing the logging system, with the new setup (e.g. log > >> to file, network, etc.). > >> > >> The migration guide seems to say "you can't do this", but I think there > >> reality may be "you can't do it anymore.... in the same way". > >> > >> Can I get some practical tips for upgrading from log4j 1.x -> 2.x given > >> the desire to do some of the things listed above? > >> > >> Thanks, > >> -chris > >> > >> --------------------------------------------------------------------- > >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
