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.
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
