I think i found a way to do this. Without reloading a file or using any
reconfigure methods.
I can use for example
ConfigurationBuilder builder =
ConfigurationBuilderFactory.newConfigurationBuilder();
builder.add(builder.newLogger("org.apache.mina", Level.WARN));
builder.build();
But
I’m not sure what that means.
The original configuration was loaded. Somehow it was modified
programmatically. Then someone changed the configuration file and it needs to
be reloaded. How are you supposed to know how to reconcile the changes made
programmatically against the changes made to
Hmm, i doint use programic configuation, is there a way i can use the prevous
configuation which is merged in when i load the file?
On Wednesday, 20 December 2017, 16:41:35 GMT, Matt Sicker
wrote:
Manually managing configurations along with a config file sounds overly
complicated. A co
Manually managing configurations along with a config file sounds overly
complicated. A composite configuration might work here, though I've never
used that feature yet. You could use the config file as the first config,
then the programmatic config as the second config so it overrides the first
(or
“remember the configuration when reconfiguring”
because we add appenders with java, they will get lost after the
reconfiguration as they are not in the configuation file. We want to reload the
configuation without losing anything.
"Again, what is the behavior you are looking for? What are you c
OK. But I am still unclear on what you want the behavior to be. Sometimes you
speak of reconfiguring and sometimes not. For example, why do you want to
“remember the configuration when reconfiguring”?
The “normal” behavior of Log4j 2 when reconfiguring based on a change to the
configuration is
We set it to null so that we can load the configuation file without resetting
anything.
So if we set the logger to null and load the configuation file it would not
erase anything like the appenders we added with java instead it would just add
back the loggers we set to null and use the level we
I still have no idea why you think you need to reset the log level to null.
When you reconfigure you are going to get a brand new configuration with
everything reset anyway.
If I was doing what you say you want to do I would create a configuration file
that has the stuff that you always want t
Thanks, hmm. Im a little unsure how to do this part now. Im only stuck on this
last part. Then we can migrate to log42.
Im wondering how do i get log4j2 to remember the configuation when
reconfiguring. As all i need is to reset the log level to null then load the
file which reads the logging wi
The way log4j 1 worked and how log4j 2 works are a bit different. Log4j 1 only
had Loggers. When you wanted to configure a Logger you obtained a Logger and
added an appender to it or set its logging level. If you created a Logger that
didn’t have a logging level it would go to its parent Logger
Please see
https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
(left side).
On Sunday, 17 December 2017, 22:41:02 GMT, Paladox
wrote:
"You didn’t answer what logging level you are setting to null and why."
Im
"You didn’t answer what logging level you are setting to null and why."
Im not really sure why it was set to null as this was done long before i
started contributing to gerrit.
I can presume it was done because PropertyConfiguator would reload the file but
wouldn't discard anything else so if we
You didn’t answer what logging level you are setting to null and why.
I’m still not getting a clear picture of what the real requirements are. "we
use java to add appenders and other things because we want users to customise
the behavour through a config” tells me you want users to be able to us
for "“Then loads the property file” - what property file? The log4j 2
configuration file? Why would you set the log sell to null before reloaded the
configuration? "
We doin't, we would load it after we set the log level to null.
Also for the "what". Well we use java to add appenders and othe
"Sets the log level to null” - which log level? The root, a particular logger,
or a Threshold Filter on a particular appender? FWIW, in Log4j 1 setting the
log level to null on a Logger just means it will inherit from its parent. That
is not necessarily the case in Log4j 2.
“Then loads the prop
Im trying to migrate gerrit from log4j1 to log4j2.
With this we have a ssh command that resets log levels (ie sets the log level
to null then loads the Property file without restarting from fresh and loosing
any appenders that were created with java).
On Sunday, 17 December 2017, 17:56:42 GM
Why are you trying to do this? What problem are you trying to solve? Simply
trying to port code from Log4j 1 to Log4j 2 without evaluating what the best
way is to achieve the desired results is not an approach I recommend.
Ralph
> On Dec 16, 2017, at 1:18 PM, Paladox
> wrote:
>
> Would like
Take a look at the Configurator class in the core module.
Gary
On Dec 16, 2017 13:18, "Paladox" wrote:
> Would like to add more to this question.
> Im wondering is it possible to also reset log levels?
> In log4j1.x we did
> private static void reset() throws MalformedURLException {for
>
Would like to add more to this question.
Im wondering is it possible to also reset log levels?
In log4j1.x we did
private static void reset() throws MalformedURLException { for
(Enumeration logger = LogManager.getCurrentLoggers();
logger.hasMoreElements(); ) { logger.nextElement().setL
19 matches
Mail list logo
