Migrating from log4j1 to log4j2

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Migrating from log4j1 to log4j2

Paladox
Hi, im wondering if i could have some help with migrating from log4j1 to log4j2 please?
Im trying to update gerrit to log4j2 but am stuck on some things. [1]
1. How do i migrate from PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2 compatible please?
Im trying to migrate all the way without trying to use log4j1 compatible api log4j2. (Though im still pulling it in i am trying not to use it).
I found doing something like
    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source = ConfigurationSource.fromResource(LOG_CONFIGURATION, null);      Configurator.initialize(null, source);    } else {      URL in = new URL(path);      Configurator.initialize((String) null, null, in.toURI());    }
could work but then it wont reload the configuation without restarting the configuation as new (ie gets rid of everything). which .reconfigure() does.
Im trying to reset log levels to null so that we can reload the configuation but reconfigure gets rid of everything thus causing problems if you used java to add appenders or anything else. see [2]
Also how would i migrate from using removeAllAppenders to log4j2 compatible code please?
[1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/
[2] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java 

Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Paladox
 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> logger = LogManager.getCurrentLoggers(); logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);    }
    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION));    } else {      PropertyConfigurator.configure(new URL(path));    }  }
in log4j2 i carn't find any good replacements. Setting setLevel results in null pointer same would be for setAllLevels. (Works in log4j1).
Then when i try to reload the properties file it just resets everything then loads the file. Thus if you used some java code it would be lost and you would have to restart your java application to get the appenders or anything added with java code.
In log4j1 you need PropertyConfigurator.configure which re added the log levels that were from the file without resetting anything.
    On Friday, 15 December 2017, 16:50:28 GMT, Paladox <[hidden email]> wrote:  
 
 Hi, im wondering if i could have some help with migrating from log4j1 to log4j2 please?
Im trying to update gerrit to log4j2 but am stuck on some things. [1]
1. How do i migrate from PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2 compatible please?
Im trying to migrate all the way without trying to use log4j1 compatible api log4j2. (Though im still pulling it in i am trying not to use it).
I found doing something like
    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source = ConfigurationSource.fromResource(LOG_CONFIGURATION, null);      Configurator.initialize(null, source);    } else {      URL in = new URL(path);      Configurator.initialize((String) null, null, in.toURI());    }
could work but then it wont reload the configuation without restarting the configuation as new (ie gets rid of everything). which .reconfigure() does.
Im trying to reset log levels to null so that we can reload the configuation but reconfigure gets rid of everything thus causing problems if you used java to add appenders or anything else. see [2]
Also how would i migrate from using removeAllAppenders to log4j2 compatible code please?
[1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/
[2] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java 
 
Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Gary Gregory-4
Take a look at the Configurator class in the core module.

Gary

On Dec 16, 2017 13:18, "Paladox" <[hidden email]> 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
> (Enumeration<Logger> logger = LogManager.getCurrentLoggers();
> logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);
>   }
>     String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if
> (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.
> configure(Loader.getResource(LOG_CONFIGURATION));    } else {
> PropertyConfigurator.configure(new URL(path));    }  }
> in log4j2 i carn't find any good replacements. Setting setLevel results in
> null pointer same would be for setAllLevels. (Works in log4j1).
> Then when i try to reload the properties file it just resets everything
> then loads the file. Thus if you used some java code it would be lost and
> you would have to restart your java application to get the appenders or
> anything added with java code.
> In log4j1 you need PropertyConfigurator.configure which re added the log
> levels that were from the file without resetting anything.
>     On Friday, 15 December 2017, 16:50:28 GMT, Paladox <
> [hidden email]> wrote:
>
>  Hi, im wondering if i could have some help with migrating from log4j1 to
> log4j2 please?
> Im trying to update gerrit to log4j2 but am stuck on some things. [1]
> 1. How do i migrate from PropertyConfigurator.
> configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2
> compatible please?
> Im trying to migrate all the way without trying to use log4j1 compatible
> api log4j2. (Though im still pulling it in i am trying not to use it).
> I found doing something like
>     String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if
> (Strings.isNullOrEmpty(path)) {      ConfigurationSource source =
> ConfigurationSource.fromResource(LOG_CONFIGURATION, null);
> Configurator.initialize(null, source);    } else {      URL in = new
> URL(path);      Configurator.initialize((String) null, null,
> in.toURI());    }
> could work but then it wont reload the configuation without restarting the
> configuation as new (ie gets rid of everything). which .reconfigure() does.
> Im trying to reset log levels to null so that we can reload the
> configuation but reconfigure gets rid of everything thus causing problems
> if you used java to add appenders or anything else. see [2]
> Also how would i migrate from using removeAllAppenders to log4j2
> compatible code please?
> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/
> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/
> 142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Ralph Goers
In reply to this post by Paladox
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 <[hidden email]> 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 (Enumeration<Logger> logger = LogManager.getCurrentLoggers(); logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);    }
>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION));    } else {      PropertyConfigurator.configure(new URL(path));    }  }
> in log4j2 i carn't find any good replacements. Setting setLevel results in null pointer same would be for setAllLevels. (Works in log4j1).
> Then when i try to reload the properties file it just resets everything then loads the file. Thus if you used some java code it would be lost and you would have to restart your java application to get the appenders or anything added with java code.
> In log4j1 you need PropertyConfigurator.configure which re added the log levels that were from the file without resetting anything.
>   On Friday, 15 December 2017, 16:50:28 GMT, Paladox <[hidden email]> wrote:  
>
> Hi, im wondering if i could have some help with migrating from log4j1 to log4j2 please?
> Im trying to update gerrit to log4j2 but am stuck on some things. [1]
> 1. How do i migrate from PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2 compatible please?
> Im trying to migrate all the way without trying to use log4j1 compatible api log4j2. (Though im still pulling it in i am trying not to use it).
> I found doing something like
>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source = ConfigurationSource.fromResource(LOG_CONFIGURATION, null);      Configurator.initialize(null, source);    } else {      URL in = new URL(path);      Configurator.initialize((String) null, null, in.toURI());    }
> could work but then it wont reload the configuation without restarting the configuation as new (ie gets rid of everything). which .reconfigure() does.
> Im trying to reset log levels to null so that we can reload the configuation but reconfigure gets rid of everything thus causing problems if you used java to add appenders or anything else. see [2]
> Also how would i migrate from using removeAllAppenders to log4j2 compatible code please?
> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/
> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java 



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Paladox
 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 GMT, Ralph Goers <[hidden email]> wrote:  
 
 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 <[hidden email]> 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 (Enumeration<Logger> logger = LogManager.getCurrentLoggers(); logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);    }
>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION));    } else {      PropertyConfigurator.configure(new URL(path));    }  }
> in log4j2 i carn't find any good replacements. Setting setLevel results in null pointer same would be for setAllLevels. (Works in log4j1).
> Then when i try to reload the properties file it just resets everything then loads the file. Thus if you used some java code it would be lost and you would have to restart your java application to get the appenders or anything added with java code.
> In log4j1 you need PropertyConfigurator.configure which re added the log levels that were from the file without resetting anything.
>  On Friday, 15 December 2017, 16:50:28 GMT, Paladox <[hidden email]> wrote: 
>
> Hi, im wondering if i could have some help with migrating from log4j1 to log4j2 please?
> Im trying to update gerrit to log4j2 but am stuck on some things. [1]
> 1. How do i migrate from PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2 compatible please?
> Im trying to migrate all the way without trying to use log4j1 compatible api log4j2. (Though im still pulling it in i am trying not to use it).
> I found doing something like
>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source = ConfigurationSource.fromResource(LOG_CONFIGURATION, null);      Configurator.initialize(null, source);    } else {      URL in = new URL(path);      Configurator.initialize((String) null, null, in.toURI());    }
> could work but then it wont reload the configuation without restarting the configuation as new (ie gets rid of everything). which .reconfigure() does.
> Im trying to reset log levels to null so that we can reload the configuation but reconfigure gets rid of everything thus causing problems if you used java to add appenders or anything else. see [2]
> Also how would i migrate from using removeAllAppenders to log4j2 compatible code please?
> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/
> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java 



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
 
Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Ralph Goers
"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 property file” - what property file? The log4j 2 configuration file?  Why would you set the log sell to null before reloaded the configuration?

“Without losing any appenders created with Java” - How are the appenders created with Java and why are they created with Java? You could use a composite configuration that adds your the “standard” configuration to what a user provides or you could extend XMLConfiguratoin with your own extra configuration.

In short, you still haven’t described what you want the resultant behavior to be. You are still describing “How?” instead of “What?”.  In other words - something like - “We want to require that a specific logger is always logged at error and those logs are always routed to a file named xxxx, regardless of what other things the user might configure”.

Ralph

> On Dec 17, 2017, at 11:22 AM, Paladox <[hidden email]> wrote:
>
> 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 GMT, Ralph Goers <[hidden email]> wrote:  
>
> 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 <[hidden email]> 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 (Enumeration<Logger> logger = LogManager.getCurrentLoggers(); logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);    }
>>     String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION));    } else {      PropertyConfigurator.configure(new URL(path));    }  }
>> in log4j2 i carn't find any good replacements. Setting setLevel results in null pointer same would be for setAllLevels. (Works in log4j1).
>> Then when i try to reload the properties file it just resets everything then loads the file. Thus if you used some java code it would be lost and you would have to restart your java application to get the appenders or anything added with java code.
>> In log4j1 you need PropertyConfigurator.configure which re added the log levels that were from the file without resetting anything.
>>   On Friday, 15 December 2017, 16:50:28 GMT, Paladox <[hidden email]> wrote:  
>>
>> Hi, im wondering if i could have some help with migrating from log4j1 to log4j2 please?
>> Im trying to update gerrit to log4j2 but am stuck on some things. [1]
>> 1. How do i migrate from PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2 compatible please?
>> Im trying to migrate all the way without trying to use log4j1 compatible api log4j2. (Though im still pulling it in i am trying not to use it).
>> I found doing something like
>>     String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source = ConfigurationSource.fromResource(LOG_CONFIGURATION, null);      Configurator.initialize(null, source);    } else {      URL in = new URL(path);      Configurator.initialize((String) null, null, in.toURI());    }
>> could work but then it wont reload the configuation without restarting the configuation as new (ie gets rid of everything). which .reconfigure() does.
>> Im trying to reset log levels to null so that we can reload the configuation but reconfigure gets rid of everything thus causing problems if you used java to add appenders or anything else. see [2]
>> Also how would i migrate from using removeAllAppenders to log4j2 compatible code please?
>> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/
>> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java 
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Paladox
 
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 other things because we want users to customise the behavour through a config. For example some users want log4j to log with json instead of the pattern layout. Though if users want to modify it more then a config they use the system property to override the default log4j configuation file and use there own.
    On Sunday, 17 December 2017, 20:44:09 GMT, Ralph Goers <[hidden email]> wrote:  
 
 "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 property file” - what property file? The log4j 2 configuration file?  Why would you set the log sell to null before reloaded the configuration?

“Without losing any appenders created with Java” - How are the appenders created with Java and why are they created with Java? You could use a composite configuration that adds your the “standard” configuration to what a user provides or you could extend XMLConfiguratoin with your own extra configuration.

In short, you still haven’t described what you want the resultant behavior to be. You are still describing “How?” instead of “What?”.  In other words - something like - “We want to require that a specific logger is always logged at error and those logs are always routed to a file named xxxx, regardless of what other things the user might configure”.

Ralph

> On Dec 17, 2017, at 11:22 AM, Paladox <[hidden email]> wrote:
>
> 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 GMT, Ralph Goers <[hidden email]> wrote: 
>
> 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 <[hidden email]> 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 (Enumeration<Logger> logger = LogManager.getCurrentLoggers(); logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);    }
>>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION));    } else {      PropertyConfigurator.configure(new URL(path));    }  }
>> in log4j2 i carn't find any good replacements. Setting setLevel results in null pointer same would be for setAllLevels. (Works in log4j1).
>> Then when i try to reload the properties file it just resets everything then loads the file. Thus if you used some java code it would be lost and you would have to restart your java application to get the appenders or anything added with java code.
>> In log4j1 you need PropertyConfigurator.configure which re added the log levels that were from the file without resetting anything.
>>  On Friday, 15 December 2017, 16:50:28 GMT, Paladox <[hidden email]> wrote: 
>>
>> Hi, im wondering if i could have some help with migrating from log4j1 to log4j2 please?
>> Im trying to update gerrit to log4j2 but am stuck on some things. [1]
>> 1. How do i migrate from PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2 compatible please?
>> Im trying to migrate all the way without trying to use log4j1 compatible api log4j2. (Though im still pulling it in i am trying not to use it).
>> I found doing something like
>>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source = ConfigurationSource.fromResource(LOG_CONFIGURATION, null);      Configurator.initialize(null, source);    } else {      URL in = new URL(path);      Configurator.initialize((String) null, null, in.toURI());    }
>> could work but then it wont reload the configuation without restarting the configuation as new (ie gets rid of everything). which .reconfigure() does.
>> Im trying to reset log levels to null so that we can reload the configuation but reconfigure gets rid of everything thus causing problems if you used java to add appenders or anything else. see [2]
>> Also how would i migrate from using removeAllAppenders to log4j2 compatible code please?
>> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/
>> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java 
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
 
Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Ralph Goers
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 use their own configuration but not why you want to add appenders and “other things” or what requirement you are trying to solve with them. What I need here is some sort of “user story definition” like - “As a user of Gerrit I need to be able to provide my own logging configuration while Gerrit makes sure that error conditions are always logged even if my configuration doesn’t specify it” or something like that. We can tell you how to implement something once we understand what you are really trying to achieve. You probably have done this before, but in case you haven’t done that before you can look at https://www.mountaingoatsoftware.com/agile/user-stories <https://www.mountaingoatsoftware.com/agile/user-stories>. Also, you might have a definition of what you want the experience for a user of Gerrit to be vs that of a developer. If so, tell me what they both are.

Ralph

> On Dec 17, 2017, at 1:58 PM, Paladox <[hidden email]> wrote:
>
>
> 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 other things because we want users to customise the behavour through a config. For example some users want log4j to log with json instead of the pattern layout. Though if users want to modify it more then a config they use the system property to override the default log4j configuation file and use there own.
>
> On Sunday, 17 December 2017, 20:44:09 GMT, Ralph Goers <[hidden email]> wrote:
>
>
> "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 property file” - what property file? The log4j 2 configuration file?  Why would you set the log sell to null before reloaded the configuration?
>
> “Without losing any appenders created with Java” - How are the appenders created with Java and why are they created with Java? You could use a composite configuration that adds your the “standard” configuration to what a user provides or you could extend XMLConfiguratoin with your own extra configuration.
>
> In short, you still haven’t described what you want the resultant behavior to be. You are still describing “How?” instead of “What?”.  In other words - something like - “We want to require that a specific logger is always logged at error and those logs are always routed to a file named xxxx, regardless of what other things the user might configure”.
>
> Ralph
>
> > On Dec 17, 2017, at 11:22 AM, Paladox <[hidden email] <mailto:[hidden email]>> wrote:
> >
> > 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 GMT, Ralph Goers <[hidden email] <mailto:[hidden email]>> wrote:  
> >
> > 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 <[hidden email] <mailto:[hidden email]>> 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 (Enumeration<Logger> logger = LogManager.getCurrentLoggers(); logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);    }
> >>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION));    } else {      PropertyConfigurator.configure(new URL(path));    }  }
> >> in log4j2 i carn't find any good replacements. Setting setLevel results in null pointer same would be for setAllLevels. (Works in log4j1).
> >> Then when i try to reload the properties file it just resets everything then loads the file. Thus if you used some java code it would be lost and you would have to restart your java application to get the appenders or anything added with java code.
> >> In log4j1 you need PropertyConfigurator.configure which re added the log levels that were from the file without resetting anything.
> >>  On Friday, 15 December 2017, 16:50:28 GMT, Paladox <[hidden email] <mailto:[hidden email]>> wrote:  
> >>
> >> Hi, im wondering if i could have some help with migrating from log4j1 to log4j2 please?
> >> Im trying to update gerrit to log4j2 but am stuck on some things. [1]
> >> 1. How do i migrate from PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2 compatible please?
> >> Im trying to migrate all the way without trying to use log4j1 compatible api log4j2. (Though im still pulling it in i am trying not to use it).
> >> I found doing something like
> >>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source = ConfigurationSource.fromResource(LOG_CONFIGURATION, null);      Configurator.initialize(null, source);    } else {      URL in = new URL(path);      Configurator.initialize((String) null, null, in.toURI());    }
> >> could work but then it wont reload the configuation without restarting the configuation as new (ie gets rid of everything). which .reconfigure() does.
> >> Im trying to reset log levels to null so that we can reload the configuation but reconfigure gets rid of everything thus causing problems if you used java to add appenders or anything else. see [2]
> >> Also how would i migrate from using removeAllAppenders to log4j2 compatible code please?
> >> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/ <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/>
> >> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java  <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
> > For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Paladox
 "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 set loggers through java then reloading the file would not affect them. So i guess they wanted to make sure everything goes back to the way it was.
More explementation, because we have a ssh command that can set log levels for either all or specific loggers we want to be able to remove the levels to put it back to how it was done when the application was started. So ie if we set debug on com.google. then that will be added to the loggers as
com.google = DEBUG
but when the application was started that was not in the loggers so we did not get any debug in the output.
But we want to set it to the default by removing com.google as loggers in com.google have different levels. IE in the log4j2.properties file we have
com.google.gerrit.sshd.GerritServerSession which is set to WARN

but now because we did com.google @ debug com.google.gerrit.sshd.GerritServerSession will be debug and everything else under com.google class path that uses loggers.
But users would not know every logger under com.google so they wouldn't be able to put them all back to the default so we set the log level to null and reloaded the file without loosing any java appenders. But with log4j2 it seems to restart as new.
    On Sunday, 17 December 2017, 22:25:28 GMT, Ralph Goers <[hidden email]> wrote:  
 
 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 use their own configuration but not why you want to add appenders and “other things” or what requirement you are trying to solve with them. What I need here is some sort of “user story definition” like - “As a user of Gerrit I need to be able to provide my own logging configuration while Gerrit makes sure that error conditions are always logged even if my configuration doesn’t specify it” or something like that. We can tell you how to implement something once we understand what you are really trying to achieve. You probably have done this before, but in case you haven’t done that before you can look at https://www.mountaingoatsoftware.com/agile/user-stories <https://www.mountaingoatsoftware.com/agile/user-stories>. Also, you might have a definition of what you want the experience for a user of Gerrit to be vs that of a developer. If so, tell me what they both are.

Ralph

> On Dec 17, 2017, at 1:58 PM, Paladox <[hidden email]> wrote:
>
>
> 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 other things because we want users to customise the behavour through a config. For example some users want log4j to log with json instead of the pattern layout. Though if users want to modify it more then a config they use the system property to override the default log4j configuation file and use there own.
>
> On Sunday, 17 December 2017, 20:44:09 GMT, Ralph Goers <[hidden email]> wrote:
>
>
> "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 property file” - what property file? The log4j 2 configuration file?  Why would you set the log sell to null before reloaded the configuration?
>
> “Without losing any appenders created with Java” - How are the appenders created with Java and why are they created with Java? You could use a composite configuration that adds your the “standard” configuration to what a user provides or you could extend XMLConfiguratoin with your own extra configuration.
>
> In short, you still haven’t described what you want the resultant behavior to be. You are still describing “How?” instead of “What?”.  In other words - something like - “We want to require that a specific logger is always logged at error and those logs are always routed to a file named xxxx, regardless of what other things the user might configure”.
>
> Ralph
>
> > On Dec 17, 2017, at 11:22 AM, Paladox <[hidden email] <mailto:[hidden email]>> wrote:
> >
> > 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 GMT, Ralph Goers <[hidden email] <mailto:[hidden email]>> wrote: 
> >
> > 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 <[hidden email] <mailto:[hidden email]>> 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 (Enumeration<Logger> logger = LogManager.getCurrentLoggers(); logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);    }
> >>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION));    } else {      PropertyConfigurator.configure(new URL(path));    }  }
> >> in log4j2 i carn't find any good replacements. Setting setLevel results in null pointer same would be for setAllLevels. (Works in log4j1).
> >> Then when i try to reload the properties file it just resets everything then loads the file. Thus if you used some java code it would be lost and you would have to restart your java application to get the appenders or anything added with java code.
> >> In log4j1 you need PropertyConfigurator.configure which re added the log levels that were from the file without resetting anything.
> >>  On Friday, 15 December 2017, 16:50:28 GMT, Paladox <[hidden email] <mailto:[hidden email]>> wrote: 
> >>
> >> Hi, im wondering if i could have some help with migrating from log4j1 to log4j2 please?
> >> Im trying to update gerrit to log4j2 but am stuck on some things. [1]
> >> 1. How do i migrate from PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2 compatible please?
> >> Im trying to migrate all the way without trying to use log4j1 compatible api log4j2. (Though im still pulling it in i am trying not to use it).
> >> I found doing something like
> >>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source = ConfigurationSource.fromResource(LOG_CONFIGURATION, null);      Configurator.initialize(null, source);    } else {      URL in = new URL(path);      Configurator.initialize((String) null, null, in.toURI());    }
> >> could work but then it wont reload the configuation without restarting the configuation as new (ie gets rid of everything). which .reconfigure() does.
> >> Im trying to reset log levels to null so that we can reload the configuation but reconfigure gets rid of everything thus causing problems if you used java to add appenders or anything else. see [2]
> >> Also how would i migrate from using removeAllAppenders to log4j2 compatible code please?
> >> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/ <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/>
> >> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java  <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
> > For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
 
Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Paladox
 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 <[hidden email]> wrote:  
 
  "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 set loggers through java then reloading the file would not affect them. So i guess they wanted to make sure everything goes back to the way it was.
More explementation, because we have a ssh command that can set log levels for either all or specific loggers we want to be able to remove the levels to put it back to how it was done when the application was started. So ie if we set debug on com.google. then that will be added to the loggers as
com.google = DEBUG
but when the application was started that was not in the loggers so we did not get any debug in the output.
But we want to set it to the default by removing com.google as loggers in com.google have different levels. IE in the log4j2.properties file we have
com.google.gerrit.sshd.GerritServerSession which is set to WARN

but now because we did com.google @ debug com.google.gerrit.sshd.GerritServerSession will be debug and everything else under com.google class path that uses loggers.
But users would not know every logger under com.google so they wouldn't be able to put them all back to the default so we set the log level to null and reloaded the file without loosing any java appenders. But with log4j2 it seems to restart as new.
    On Sunday, 17 December 2017, 22:25:28 GMT, Ralph Goers <[hidden email]> wrote: 
 
 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 use their own configuration but not why you want to add appenders and “other things” or what requirement you are trying to solve with them. What I need here is some sort of “user story definition” like - “As a user of Gerrit I need to be able to provide my own logging configuration while Gerrit makes sure that error conditions are always logged even if my configuration doesn’t specify it” or something like that. We can tell you how to implement something once we understand what you are really trying to achieve. You probably have done this before, but in case you haven’t done that before you can look at https://www.mountaingoatsoftware.com/agile/user-stories <https://www.mountaingoatsoftware.com/agile/user-stories>. Also, you might have a definition of what you want the experience for a user of Gerrit to be vs that of a developer. If so, tell me what they both are.

Ralph

> On Dec 17, 2017, at 1:58 PM, Paladox <[hidden email]> wrote:
>
>
> 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 other things because we want users to customise the behavour through a config. For example some users want log4j to log with json instead of the pattern layout. Though if users want to modify it more then a config they use the system property to override the default log4j configuation file and use there own.
>
> On Sunday, 17 December 2017, 20:44:09 GMT, Ralph Goers <[hidden email]> wrote:
>
>
> "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 property file” - what property file? The log4j 2 configuration file?  Why would you set the log sell to null before reloaded the configuration?
>
> “Without losing any appenders created with Java” - How are the appenders created with Java and why are they created with Java? You could use a composite configuration that adds your the “standard” configuration to what a user provides or you could extend XMLConfiguratoin with your own extra configuration.
>
> In short, you still haven’t described what you want the resultant behavior to be. You are still describing “How?” instead of “What?”.  In other words - something like - “We want to require that a specific logger is always logged at error and those logs are always routed to a file named xxxx, regardless of what other things the user might configure”.
>
> Ralph
>
> > On Dec 17, 2017, at 11:22 AM, Paladox <[hidden email] <mailto:[hidden email]>> wrote:
> >
> > 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 GMT, Ralph Goers <[hidden email] <mailto:[hidden email]>> wrote: 
> >
> > 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 <[hidden email] <mailto:[hidden email]>> 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 (Enumeration<Logger> logger = LogManager.getCurrentLoggers(); logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);    }
> >>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION));    } else {      PropertyConfigurator.configure(new URL(path));    }  }
> >> in log4j2 i carn't find any good replacements. Setting setLevel results in null pointer same would be for setAllLevels. (Works in log4j1).
> >> Then when i try to reload the properties file it just resets everything then loads the file. Thus if you used some java code it would be lost and you would have to restart your java application to get the appenders or anything added with java code.
> >> In log4j1 you need PropertyConfigurator.configure which re added the log levels that were from the file without resetting anything.
> >>  On Friday, 15 December 2017, 16:50:28 GMT, Paladox <[hidden email] <mailto:[hidden email]>> wrote: 
> >>
> >> Hi, im wondering if i could have some help with migrating from log4j1 to log4j2 please?
> >> Im trying to update gerrit to log4j2 but am stuck on some things. [1]
> >> 1. How do i migrate from PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2 compatible please?
> >> Im trying to migrate all the way without trying to use log4j1 compatible api log4j2. (Though im still pulling it in i am trying not to use it).
> >> I found doing something like
> >>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source = ConfigurationSource.fromResource(LOG_CONFIGURATION, null);      Configurator.initialize(null, source);    } else {      URL in = new URL(path);      Configurator.initialize((String) null, null, in.toURI());    }
> >> could work but then it wont reload the configuation without restarting the configuation as new (ie gets rid of everything). which .reconfigure() does.
> >> Im trying to reset log levels to null so that we can reload the configuation but reconfigure gets rid of everything thus causing problems if you used java to add appenders or anything else. see [2]
> >> Also how would i migrate from using removeAllAppenders to log4j2 compatible code please?
> >> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/ <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/>
> >> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java  <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
> > For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
   
Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Ralph Goers
In reply to this post by Paladox
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 and get it from there. So setting a Logger’s logging level to null basically said “look at your parent”.  When an application wants to log something it also obtains a Logger. So the Loggers used for logging and configuration were the same. In order to reconfigure, Log4j 1 would clear everything from the Loggers and then start adding configuration back to them as it processed the configuration. During the time that the Loggers are cleared and before configuration is added back events are ignored.

Log4j 2 doesn’t work this way at all. When the configuration is read a set of LoggerConfig objects is created. These all contain the same information that is in the configuration file. When an application wants to log it gets a Logger. The Logger looks for a LoggerConfig with its name or, if one isn’t found, one of its ancestors. The Logger then is set with a reference to the LoggerConfig that provides its configuration and it copies that LoggerConfig’s logging level into it to improve performance. Thus, when you want to  change a logging level you need to locate the LoggerConfig for the Logger, update its logging level, and then call updateLoggers to cause all Loggers to reevaluate which LoggerConfig they should be using and what their current logging level is.

There are several ways to deal with changes.
You add a listener to handle configuration changes. This would allow you to reinsert changes to the configuration.
You can create your own Configuration and combine it with the user’s configuration using a CompositeConfiguration. Your configuration can be created with a config file or via the ConfigurationBuilder.
You can extend XMLConfiguration and/or PropertiesConfiguration and add your own definitions to it.

I am sure there are other ways this can all be done depending on what you are trying to achieve. If you modify the logging level of a LoggerConfig and then a reconfigure occurs Log4j will automatically handle resetting the configuration. You don’t have to do anything. If you want to reinsert changes to the user’s configuration then you have to use one of the techniques I noted above.

Ralph




> On Dec 17, 2017, at 3:40 PM, Paladox <[hidden email]> wrote:
>
> "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 set loggers through java then reloading the file would not affect them. So i guess they wanted to make sure everything goes back to the way it was.
> More explementation, because we have a ssh command that can set log levels for either all or specific loggers we want to be able to remove the levels to put it back to how it was done when the application was started. So ie if we set debug on com.google. then that will be added to the loggers as
> com.google = DEBUG
> but when the application was started that was not in the loggers so we did not get any debug in the output.
> But we want to set it to the default by removing com.google as loggers in com.google have different levels. IE in the log4j2.properties file we have
> com.google.gerrit.sshd.GerritServerSession which is set to WARN
>
> but now because we did com.google @ debug com.google.gerrit.sshd.GerritServerSession will be debug and everything else under com.google class path that uses loggers.
> But users would not know every logger under com.google so they wouldn't be able to put them all back to the default so we set the log level to null and reloaded the file without loosing any java appenders. But with log4j2 it seems to restart as new.
>    On Sunday, 17 December 2017, 22:25:28 GMT, Ralph Goers <[hidden email]> wrote:  
>
> 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 use their own configuration but not why you want to add appenders and “other things” or what requirement you are trying to solve with them. What I need here is some sort of “user story definition” like - “As a user of Gerrit I need to be able to provide my own logging configuration while Gerrit makes sure that error conditions are always logged even if my configuration doesn’t specify it” or something like that. We can tell you how to implement something once we understand what you are really trying to achieve. You probably have done this before, but in case you haven’t done that before you can look at https://www.mountaingoatsoftware.com/agile/user-stories <https://www.mountaingoatsoftware.com/agile/user-stories>. Also, you might have a definition of what you want the experience for a user of Gerrit to be vs that of a developer. If so, tell me what they both are.
>
> Ralph
>
>> On Dec 17, 2017, at 1:58 PM, Paladox <[hidden email]> wrote:
>>
>>
>> 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 other things because we want users to customise the behavour through a config. For example some users want log4j to log with json instead of the pattern layout. Though if users want to modify it more then a config they use the system property to override the default log4j configuation file and use there own.
>>
>> On Sunday, 17 December 2017, 20:44:09 GMT, Ralph Goers <[hidden email]> wrote:
>>
>>
>> "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 property file” - what property file? The log4j 2 configuration file?  Why would you set the log sell to null before reloaded the configuration?
>>
>> “Without losing any appenders created with Java” - How are the appenders created with Java and why are they created with Java? You could use a composite configuration that adds your the “standard” configuration to what a user provides or you could extend XMLConfiguratoin with your own extra configuration.
>>
>> In short, you still haven’t described what you want the resultant behavior to be. You are still describing “How?” instead of “What?”.  In other words - something like - “We want to require that a specific logger is always logged at error and those logs are always routed to a file named xxxx, regardless of what other things the user might configure”.
>>
>> Ralph
>>
>>> On Dec 17, 2017, at 11:22 AM, Paladox <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>> 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 GMT, Ralph Goers <[hidden email] <mailto:[hidden email]>> wrote:  
>>>
>>> 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 <[hidden email] <mailto:[hidden email]>> 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 (Enumeration<Logger> logger = LogManager.getCurrentLoggers(); logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);    }
>>>>     String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION));    } else {      PropertyConfigurator.configure(new URL(path));    }  }
>>>> in log4j2 i carn't find any good replacements. Setting setLevel results in null pointer same would be for setAllLevels. (Works in log4j1).
>>>> Then when i try to reload the properties file it just resets everything then loads the file. Thus if you used some java code it would be lost and you would have to restart your java application to get the appenders or anything added with java code.
>>>> In log4j1 you need PropertyConfigurator.configure which re added the log levels that were from the file without resetting anything.
>>>>   On Friday, 15 December 2017, 16:50:28 GMT, Paladox <[hidden email] <mailto:[hidden email]>> wrote:  
>>>>
>>>> Hi, im wondering if i could have some help with migrating from log4j1 to log4j2 please?
>>>> Im trying to update gerrit to log4j2 but am stuck on some things. [1]
>>>> 1. How do i migrate from PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2 compatible please?
>>>> Im trying to migrate all the way without trying to use log4j1 compatible api log4j2. (Though im still pulling it in i am trying not to use it).
>>>> I found doing something like
>>>>     String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source = ConfigurationSource.fromResource(LOG_CONFIGURATION, null);      Configurator.initialize(null, source);    } else {      URL in = new URL(path);      Configurator.initialize((String) null, null, in.toURI());    }
>>>> could work but then it wont reload the configuation without restarting the configuation as new (ie gets rid of everything). which .reconfigure() does.
>>>> Im trying to reset log levels to null so that we can reload the configuation but reconfigure gets rid of everything thus causing problems if you used java to add appenders or anything else. see [2]
>>>> Also how would i migrate from using removeAllAppenders to log4j2 compatible code please?
>>>> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/ <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/>
>>>> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java  <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
>>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Paladox
 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 without causing a null pointer.
I see there's ConfigurationBuilder as you pointed too but we use a mixture of java / using the properties files.
So we add a appender with java but add ConsoleAppender through the properties file.
Reading this https://github.com/apache/log4j/blob/c5f4279081091e562c44bb753f6e52dc6be5fa52/src/main/java/org/apache/log4j/PropertyConfigurator.java#L120 seems to say that it just reads the configuation but dosen't clear anything. I wonder would something like be able to be added to log4j2 please?


    On Sunday, 17 December 2017, 23:30:02 GMT, Ralph Goers <[hidden email]> wrote:  
 
 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 and get it from there. So setting a Logger’s logging level to null basically said “look at your parent”.  When an application wants to log something it also obtains a Logger. So the Loggers used for logging and configuration were the same. In order to reconfigure, Log4j 1 would clear everything from the Loggers and then start adding configuration back to them as it processed the configuration. During the time that the Loggers are cleared and before configuration is added back events are ignored.

Log4j 2 doesn’t work this way at all. When the configuration is read a set of LoggerConfig objects is created. These all contain the same information that is in the configuration file. When an application wants to log it gets a Logger. The Logger looks for a LoggerConfig with its name or, if one isn’t found, one of its ancestors. The Logger then is set with a reference to the LoggerConfig that provides its configuration and it copies that LoggerConfig’s logging level into it to improve performance. Thus, when you want to  change a logging level you need to locate the LoggerConfig for the Logger, update its logging level, and then call updateLoggers to cause all Loggers to reevaluate which LoggerConfig they should be using and what their current logging level is.

There are several ways to deal with changes.
You add a listener to handle configuration changes. This would allow you to reinsert changes to the configuration.
You can create your own Configuration and combine it with the user’s configuration using a CompositeConfiguration. Your configuration can be created with a config file or via the ConfigurationBuilder.
You can extend XMLConfiguration and/or PropertiesConfiguration and add your own definitions to it.

I am sure there are other ways this can all be done depending on what you are trying to achieve. If you modify the logging level of a LoggerConfig and then a reconfigure occurs Log4j will automatically handle resetting the configuration. You don’t have to do anything. If you want to reinsert changes to the user’s configuration then you have to use one of the techniques I noted above.

Ralph




> On Dec 17, 2017, at 3:40 PM, Paladox <[hidden email]> wrote:
>
> "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 set loggers through java then reloading the file would not affect them. So i guess they wanted to make sure everything goes back to the way it was.
> More explementation, because we have a ssh command that can set log levels for either all or specific loggers we want to be able to remove the levels to put it back to how it was done when the application was started. So ie if we set debug on com.google. then that will be added to the loggers as
> com.google = DEBUG
> but when the application was started that was not in the loggers so we did not get any debug in the output.
> But we want to set it to the default by removing com.google as loggers in com.google have different levels. IE in the log4j2.properties file we have
> com.google.gerrit.sshd.GerritServerSession which is set to WARN
>
> but now because we did com.google @ debug com.google.gerrit.sshd.GerritServerSession will be debug and everything else under com.google class path that uses loggers.
> But users would not know every logger under com.google so they wouldn't be able to put them all back to the default so we set the log level to null and reloaded the file without loosing any java appenders. But with log4j2 it seems to restart as new.
>    On Sunday, 17 December 2017, 22:25:28 GMT, Ralph Goers <[hidden email]> wrote: 
>
> 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 use their own configuration but not why you want to add appenders and “other things” or what requirement you are trying to solve with them. What I need here is some sort of “user story definition” like - “As a user of Gerrit I need to be able to provide my own logging configuration while Gerrit makes sure that error conditions are always logged even if my configuration doesn’t specify it” or something like that. We can tell you how to implement something once we understand what you are really trying to achieve. You probably have done this before, but in case you haven’t done that before you can look at https://www.mountaingoatsoftware.com/agile/user-stories <https://www.mountaingoatsoftware.com/agile/user-stories>. Also, you might have a definition of what you want the experience for a user of Gerrit to be vs that of a developer. If so, tell me what they both are.
>
> Ralph
>
>> On Dec 17, 2017, at 1:58 PM, Paladox <[hidden email]> wrote:
>>
>>
>> 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 other things because we want users to customise the behavour through a config. For example some users want log4j to log with json instead of the pattern layout. Though if users want to modify it more then a config they use the system property to override the default log4j configuation file and use there own.
>>
>> On Sunday, 17 December 2017, 20:44:09 GMT, Ralph Goers <[hidden email]> wrote:
>>
>>
>> "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 property file” - what property file? The log4j 2 configuration file?  Why would you set the log sell to null before reloaded the configuration?
>>
>> “Without losing any appenders created with Java” - How are the appenders created with Java and why are they created with Java? You could use a composite configuration that adds your the “standard” configuration to what a user provides or you could extend XMLConfiguratoin with your own extra configuration.
>>
>> In short, you still haven’t described what you want the resultant behavior to be. You are still describing “How?” instead of “What?”.  In other words - something like - “We want to require that a specific logger is always logged at error and those logs are always routed to a file named xxxx, regardless of what other things the user might configure”.
>>
>> Ralph
>>
>>> On Dec 17, 2017, at 11:22 AM, Paladox <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>> 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 GMT, Ralph Goers <[hidden email] <mailto:[hidden email]>> wrote: 
>>>
>>> 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 <[hidden email] <mailto:[hidden email]>> 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 (Enumeration<Logger> logger = LogManager.getCurrentLoggers(); logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);    }
>>>>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION));    } else {      PropertyConfigurator.configure(new URL(path));    }  }
>>>> in log4j2 i carn't find any good replacements. Setting setLevel results in null pointer same would be for setAllLevels. (Works in log4j1).
>>>> Then when i try to reload the properties file it just resets everything then loads the file. Thus if you used some java code it would be lost and you would have to restart your java application to get the appenders or anything added with java code.
>>>> In log4j1 you need PropertyConfigurator.configure which re added the log levels that were from the file without resetting anything.
>>>>  On Friday, 15 December 2017, 16:50:28 GMT, Paladox <[hidden email] <mailto:[hidden email]>> wrote: 
>>>>
>>>> Hi, im wondering if i could have some help with migrating from log4j1 to log4j2 please?
>>>> Im trying to update gerrit to log4j2 but am stuck on some things. [1]
>>>> 1. How do i migrate from PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2 compatible please?
>>>> Im trying to migrate all the way without trying to use log4j1 compatible api log4j2. (Though im still pulling it in i am trying not to use it).
>>>> I found doing something like
>>>>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source = ConfigurationSource.fromResource(LOG_CONFIGURATION, null);      Configurator.initialize(null, source);    } else {      URL in = new URL(path);      Configurator.initialize((String) null, null, in.toURI());    }
>>>> could work but then it wont reload the configuation without restarting the configuation as new (ie gets rid of everything). which .reconfigure() does.
>>>> Im trying to reset log levels to null so that we can reload the configuation but reconfigure gets rid of everything thus causing problems if you used java to add appenders or anything else. see [2]
>>>> Also how would i migrate from using removeAllAppenders to log4j2 compatible code please?
>>>> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/ <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/>
>>>> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java  <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
>>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
 
Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Ralph Goers
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 to add. I would then use Configurator.initialize(“file1, file2”) to combine the user’s configuration with yours.

Ralph

> On Dec 19, 2017, at 12:23 PM, Paladox <[hidden email]> wrote:
>
> 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 without causing a null pointer.
>
> I see there's ConfigurationBuilder as you pointed too but we use a mixture of java / using the properties files.
>
> So we add a appender with java but add ConsoleAppender through the properties file.
>
> Reading this https://github.com/apache/log4j/blob/c5f4279081091e562c44bb753f6e52dc6be5fa52/src/main/java/org/apache/log4j/PropertyConfigurator.java#L120 seems to say that it just reads the configuation but dosen't clear anything. I wonder would something like be able to be added to log4j2 please?
>
>
>
> On Sunday, 17 December 2017, 23:30:02 GMT, Ralph Goers <[hidden email]> wrote:
>
>
> 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 and get it from there. So setting a Logger’s logging level to null basically said “look at your parent”.  When an application wants to log something it also obtains a Logger. So the Loggers used for logging and configuration were the same. In order to reconfigure, Log4j 1 would clear everything from the Loggers and then start adding configuration back to them as it processed the configuration. During the time that the Loggers are cleared and before configuration is added back events are ignored.
>
> Log4j 2 doesn’t work this way at all. When the configuration is read a set of LoggerConfig objects is created. These all contain the same information that is in the configuration file. When an application wants to log it gets a Logger. The Logger looks for a LoggerConfig with its name or, if one isn’t found, one of its ancestors. The Logger then is set with a reference to the LoggerConfig that provides its configuration and it copies that LoggerConfig’s logging level into it to improve performance. Thus, when you want to  change a logging level you need to locate the LoggerConfig for the Logger, update its logging level, and then call updateLoggers to cause all Loggers to reevaluate which LoggerConfig they should be using and what their current logging level is.
>
> There are several ways to deal with changes.
> You add a listener to handle configuration changes. This would allow you to reinsert changes to the configuration.
> You can create your own Configuration and combine it with the user’s configuration using a CompositeConfiguration. Your configuration can be created with a config file or via the ConfigurationBuilder.
> You can extend XMLConfiguration and/or PropertiesConfiguration and add your own definitions to it.
>
> I am sure there are other ways this can all be done depending on what you are trying to achieve. If you modify the logging level of a LoggerConfig and then a reconfigure occurs Log4j will automatically handle resetting the configuration. You don’t have to do anything. If you want to reinsert changes to the user’s configuration then you have to use one of the techniques I noted above.
>
> Ralph
>
>
>
>
> > On Dec 17, 2017, at 3:40 PM, Paladox <[hidden email] <mailto:[hidden email]>> wrote:
> >
> > "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 set loggers through java then reloading the file would not affect them. So i guess they wanted to make sure everything goes back to the way it was.
> > More explementation, because we have a ssh command that can set log levels for either all or specific loggers we want to be able to remove the levels to put it back to how it was done when the application was started. So ie if we set debug on com.google. then that will be added to the loggers as
> > com.google = DEBUG
> > but when the application was started that was not in the loggers so we did not get any debug in the output.
> > But we want to set it to the default by removing com.google as loggers in com.google have different levels. IE in the log4j2.properties file we have
> > com.google.gerrit.sshd.GerritServerSession which is set to WARN
> >
> > but now because we did com.google @ debug com.google.gerrit.sshd.GerritServerSession will be debug and everything else under com.google class path that uses loggers.
> > But users would not know every logger under com.google so they wouldn't be able to put them all back to the default so we set the log level to null and reloaded the file without loosing any java appenders. But with log4j2 it seems to restart as new.
> >    On Sunday, 17 December 2017, 22:25:28 GMT, Ralph Goers <[hidden email] <mailto:[hidden email]>> wrote:  
> >
> > 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 use their own configuration but not why you want to add appenders and “other things” or what requirement you are trying to solve with them. What I need here is some sort of “user story definition” like - “As a user of Gerrit I need to be able to provide my own logging configuration while Gerrit makes sure that error conditions are always logged even if my configuration doesn’t specify it” or something like that. We can tell you how to implement something once we understand what you are really trying to achieve. You probably have done this before, but in case you haven’t done that before you can look at https://www.mountaingoatsoftware.com/agile/user-stories  <https://www.mountaingoatsoftware.com/agile/user-stories><https://www.mountaingoatsoftware.com/agile/user-stories <https://www.mountaingoatsoftware.com/agile/user-stories>>. Also, you might have a definition of what you want the experience for a user of Gerrit to be vs that of a developer. If so, tell me what they both are.
> >
> > Ralph
> >
> >> On Dec 17, 2017, at 1:58 PM, Paladox <[hidden email] <mailto:[hidden email]>> wrote:
> >>
> >>
> >> 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 other things because we want users to customise the behavour through a config. For example some users want log4j to log with json instead of the pattern layout. Though if users want to modify it more then a config they use the system property to override the default log4j configuation file and use there own.
> >>
> >> On Sunday, 17 December 2017, 20:44:09 GMT, Ralph Goers <[hidden email] <mailto:[hidden email]>> wrote:
> >>
> >>
> >> "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 property file” - what property file? The log4j 2 configuration file?  Why would you set the log sell to null before reloaded the configuration?
> >>
> >> “Without losing any appenders created with Java” - How are the appenders created with Java and why are they created with Java? You could use a composite configuration that adds your the “standard” configuration to what a user provides or you could extend XMLConfiguratoin with your own extra configuration.
> >>
> >> In short, you still haven’t described what you want the resultant behavior to be. You are still describing “How?” instead of “What?”.  In other words - something like - “We want to require that a specific logger is always logged at error and those logs are always routed to a file named xxxx, regardless of what other things the user might configure”.
> >>
> >> Ralph
> >>
> >>> On Dec 17, 2017, at 11:22 AM, Paladox <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
> >>>
> >>> 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 GMT, Ralph Goers <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:  
> >>>
> >>> 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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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 (Enumeration<Logger> logger = LogManager.getCurrentLoggers(); logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);    }
> >>>>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION));    } else {      PropertyConfigurator.configure(new URL(path));    }  }
> >>>> in log4j2 i carn't find any good replacements. Setting setLevel results in null pointer same would be for setAllLevels. (Works in log4j1).
> >>>> Then when i try to reload the properties file it just resets everything then loads the file. Thus if you used some java code it would be lost and you would have to restart your java application to get the appenders or anything added with java code.
> >>>> In log4j1 you need PropertyConfigurator.configure which re added the log levels that were from the file without resetting anything.
> >>>>  On Friday, 15 December 2017, 16:50:28 GMT, Paladox <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:  
> >>>>
> >>>> Hi, im wondering if i could have some help with migrating from log4j1 to log4j2 please?
> >>>> Im trying to update gerrit to log4j2 but am stuck on some things. [1]
> >>>> 1. How do i migrate from PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2 compatible please?
> >>>> Im trying to migrate all the way without trying to use log4j1 compatible api log4j2. (Though im still pulling it in i am trying not to use it).
> >>>> I found doing something like
> >>>>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source = ConfigurationSource.fromResource(LOG_CONFIGURATION, null);      Configurator.initialize(null, source);    } else {      URL in = new URL(path);      Configurator.initialize((String) null, null, in.toURI());    }
> >>>> could work but then it wont reload the configuation without restarting the configuation as new (ie gets rid of everything). which .reconfigure() does.
> >>>> Im trying to reset log levels to null so that we can reload the configuation but reconfigure gets rid of everything thus causing problems if you used java to add appenders or anything else. see [2]
> >>>> Also how would i migrate from using removeAllAppenders to log4j2 compatible code please?
> >>>> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/  <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/><https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/ <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/>>
> >>>> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java  <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java><https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
> >>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
> >> For additional commands, e-mail: [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>

Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Paladox
 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 set in the configuation file.
In log4j2 it seems to not support a way like https://github.com/apache/log4j/blob/c5f4279081091e562c44bb753f6e52dc6be5fa52/src/main/java/org/apache/log4j/PropertyConfigurator.java#L120 

"    Read configuration from a file. <b>The existing configuration is    not cleared nor reset.</b> If you require a different behavior,    then call {@link  LogManager#resetConfiguration    resetConfiguration} method before calling    <code>doConfigure</code>."
Thats one of the reasons why we had to use null as it did not reset it (which we doint want anyways) we needed to remove the log level to prevent it for example writing tons of info if you have it set to DEBUG. But by re adding the file we got the loggers back to the default value we had them set at.
Now in log4j2 there dosen't seem to be anything similar except from the one you pointed too but that reset everything.

    On Tuesday, 19 December 2017, 21:11:26 GMT, Ralph Goers <[hidden email]> wrote:  
 
 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 to add. I would then use Configurator.initialize(“file1, file2”) to combine the user’s configuration with yours.

Ralph

> On Dec 19, 2017, at 12:23 PM, Paladox <[hidden email]> wrote:
>
> 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 without causing a null pointer.
>
> I see there's ConfigurationBuilder as you pointed too but we use a mixture of java / using the properties files.
>
> So we add a appender with java but add ConsoleAppender through the properties file.
>
> Reading this https://github.com/apache/log4j/blob/c5f4279081091e562c44bb753f6e52dc6be5fa52/src/main/java/org/apache/log4j/PropertyConfigurator.java#L120 seems to say that it just reads the configuation but dosen't clear anything. I wonder would something like be able to be added to log4j2 please?
>
>
>
> On Sunday, 17 December 2017, 23:30:02 GMT, Ralph Goers <[hidden email]> wrote:
>
>
> 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 and get it from there. So setting a Logger’s logging level to null basically said “look at your parent”.  When an application wants to log something it also obtains a Logger. So the Loggers used for logging and configuration were the same. In order to reconfigure, Log4j 1 would clear everything from the Loggers and then start adding configuration back to them as it processed the configuration. During the time that the Loggers are cleared and before configuration is added back events are ignored.
>
> Log4j 2 doesn’t work this way at all. When the configuration is read a set of LoggerConfig objects is created. These all contain the same information that is in the configuration file. When an application wants to log it gets a Logger. The Logger looks for a LoggerConfig with its name or, if one isn’t found, one of its ancestors. The Logger then is set with a reference to the LoggerConfig that provides its configuration and it copies that LoggerConfig’s logging level into it to improve performance. Thus, when you want to  change a logging level you need to locate the LoggerConfig for the Logger, update its logging level, and then call updateLoggers to cause all Loggers to reevaluate which LoggerConfig they should be using and what their current logging level is.
>
> There are several ways to deal with changes.
> You add a listener to handle configuration changes. This would allow you to reinsert changes to the configuration.
> You can create your own Configuration and combine it with the user’s configuration using a CompositeConfiguration. Your configuration can be created with a config file or via the ConfigurationBuilder.
> You can extend XMLConfiguration and/or PropertiesConfiguration and add your own definitions to it.
>
> I am sure there are other ways this can all be done depending on what you are trying to achieve. If you modify the logging level of a LoggerConfig and then a reconfigure occurs Log4j will automatically handle resetting the configuration. You don’t have to do anything. If you want to reinsert changes to the user’s configuration then you have to use one of the techniques I noted above.
>
> Ralph
>
>
>
>
> > On Dec 17, 2017, at 3:40 PM, Paladox <[hidden email] <mailto:[hidden email]>> wrote:
> >
> > "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 set loggers through java then reloading the file would not affect them. So i guess they wanted to make sure everything goes back to the way it was.
> > More explementation, because we have a ssh command that can set log levels for either all or specific loggers we want to be able to remove the levels to put it back to how it was done when the application was started. So ie if we set debug on com.google. then that will be added to the loggers as
> > com.google = DEBUG
> > but when the application was started that was not in the loggers so we did not get any debug in the output.
> > But we want to set it to the default by removing com.google as loggers in com.google have different levels. IE in the log4j2.properties file we have
> > com.google.gerrit.sshd.GerritServerSession which is set to WARN
> >
> > but now because we did com.google @ debug com.google.gerrit.sshd.GerritServerSession will be debug and everything else under com.google class path that uses loggers.
> > But users would not know every logger under com.google so they wouldn't be able to put them all back to the default so we set the log level to null and reloaded the file without loosing any java appenders. But with log4j2 it seems to restart as new.
> >    On Sunday, 17 December 2017, 22:25:28 GMT, Ralph Goers <[hidden email] <mailto:[hidden email]>> wrote: 
> >
> > 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 use their own configuration but not why you want to add appenders and “other things” or what requirement you are trying to solve with them. What I need here is some sort of “user story definition” like - “As a user of Gerrit I need to be able to provide my own logging configuration while Gerrit makes sure that error conditions are always logged even if my configuration doesn’t specify it” or something like that. We can tell you how to implement something once we understand what you are really trying to achieve. You probably have done this before, but in case you haven’t done that before you can look at https://www.mountaingoatsoftware.com/agile/user-stories  <https://www.mountaingoatsoftware.com/agile/user-stories><https://www.mountaingoatsoftware.com/agile/user-stories <https://www.mountaingoatsoftware.com/agile/user-stories>>. Also, you might have a definition of what you want the experience for a user of Gerrit to be vs that of a developer. If so, tell me what they both are.
> >
> > Ralph
> >
> >> On Dec 17, 2017, at 1:58 PM, Paladox <[hidden email] <mailto:[hidden email]>> wrote:
> >>
> >>
> >> 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 other things because we want users to customise the behavour through a config. For example some users want log4j to log with json instead of the pattern layout. Though if users want to modify it more then a config they use the system property to override the default log4j configuation file and use there own.
> >>
> >> On Sunday, 17 December 2017, 20:44:09 GMT, Ralph Goers <[hidden email] <mailto:[hidden email]>> wrote:
> >>
> >>
> >> "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 property file” - what property file? The log4j 2 configuration file?  Why would you set the log sell to null before reloaded the configuration?
> >>
> >> “Without losing any appenders created with Java” - How are the appenders created with Java and why are they created with Java? You could use a composite configuration that adds your the “standard” configuration to what a user provides or you could extend XMLConfiguratoin with your own extra configuration.
> >>
> >> In short, you still haven’t described what you want the resultant behavior to be. You are still describing “How?” instead of “What?”.  In other words - something like - “We want to require that a specific logger is always logged at error and those logs are always routed to a file named xxxx, regardless of what other things the user might configure”.
> >>
> >> Ralph
> >>
> >>> On Dec 17, 2017, at 11:22 AM, Paladox <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
> >>>
> >>> 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 GMT, Ralph Goers <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote: 
> >>>
> >>> 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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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 (Enumeration<Logger> logger = LogManager.getCurrentLoggers(); logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);    }
> >>>>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION));    } else {      PropertyConfigurator.configure(new URL(path));    }  }
> >>>> in log4j2 i carn't find any good replacements. Setting setLevel results in null pointer same would be for setAllLevels. (Works in log4j1).
> >>>> Then when i try to reload the properties file it just resets everything then loads the file. Thus if you used some java code it would be lost and you would have to restart your java application to get the appenders or anything added with java code.
> >>>> In log4j1 you need PropertyConfigurator.configure which re added the log levels that were from the file without resetting anything.
> >>>>  On Friday, 15 December 2017, 16:50:28 GMT, Paladox <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote: 
> >>>>
> >>>> Hi, im wondering if i could have some help with migrating from log4j1 to log4j2 please?
> >>>> Im trying to update gerrit to log4j2 but am stuck on some things. [1]
> >>>> 1. How do i migrate from PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2 compatible please?
> >>>> Im trying to migrate all the way without trying to use log4j1 compatible api log4j2. (Though im still pulling it in i am trying not to use it).
> >>>> I found doing something like
> >>>>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source = ConfigurationSource.fromResource(LOG_CONFIGURATION, null);      Configurator.initialize(null, source);    } else {      URL in = new URL(path);      Configurator.initialize((String) null, null, in.toURI());    }
> >>>> could work but then it wont reload the configuation without restarting the configuation as new (ie gets rid of everything). which .reconfigure() does.
> >>>> Im trying to reset log levels to null so that we can reload the configuation but reconfigure gets rid of everything thus causing problems if you used java to add appenders or anything else. see [2]
> >>>> Also how would i migrate from using removeAllAppenders to log4j2 compatible code please?
> >>>> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/  <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/><https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/ <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/>>
> >>>> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java  <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java><https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
> >>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
> >> For additional commands, e-mail: [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
 
Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Ralph Goers
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:
Re-read the configuration and create a brand new Configuration.
Start the new Configuration (starts the new Appenders).
Set the LoggerContext to point to the new Configuration.
Update all Loggers to use the new Configuration.
Stop the old Configuration.

This happens automatically if you have set monitorInterval to a non-zero value on a Configuration element in a config file. You can force it to happen by calling LoggerContext.reconfigure().

If you have made any programmatic changes to the configuration they will be lost during this process.  If you are “remembering the changes” you made programmatically and have captured them you can just reapply them after Log4j 2 reconfigures.

Again, what is the behavior you are looking for? What are you changing programmatically? Just the log levels of Loggers? Are you wanting those changes re-applied after a reconfiguration?

Ralph




> On Dec 19, 2017, at 2:28 PM, Paladox <[hidden email]> wrote:
>
> 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 set in the configuation file.
> In log4j2 it seems to not support a way like https://github.com/apache/log4j/blob/c5f4279081091e562c44bb753f6e52dc6be5fa52/src/main/java/org/apache/log4j/PropertyConfigurator.java#L120 
>
> "    Read configuration from a file. <b>The existing configuration is    not cleared nor reset.</b> If you require a different behavior,    then call {@link  LogManager#resetConfiguration    resetConfiguration} method before calling    <code>doConfigure</code>."
> Thats one of the reasons why we had to use null as it did not reset it (which we doint want anyways) we needed to remove the log level to prevent it for example writing tons of info if you have it set to DEBUG. But by re adding the file we got the loggers back to the default value we had them set at.
> Now in log4j2 there dosen't seem to be anything similar except from the one you pointed too but that reset everything.
>
>    On Tuesday, 19 December 2017, 21:11:26 GMT, Ralph Goers <[hidden email]> wrote:  
>
> 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 to add. I would then use Configurator.initialize(“file1, file2”) to combine the user’s configuration with yours.
>
> Ralph
>
>> On Dec 19, 2017, at 12:23 PM, Paladox <[hidden email]> wrote:
>>
>> 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 without causing a null pointer.
>>
>> I see there's ConfigurationBuilder as you pointed too but we use a mixture of java / using the properties files.
>>
>> So we add a appender with java but add ConsoleAppender through the properties file.
>>
>> Reading this https://github.com/apache/log4j/blob/c5f4279081091e562c44bb753f6e52dc6be5fa52/src/main/java/org/apache/log4j/PropertyConfigurator.java#L120 seems to say that it just reads the configuation but dosen't clear anything. I wonder would something like be able to be added to log4j2 please?
>>
>>
>>
>> On Sunday, 17 December 2017, 23:30:02 GMT, Ralph Goers <[hidden email]> wrote:
>>
>>
>> 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 and get it from there. So setting a Logger’s logging level to null basically said “look at your parent”.  When an application wants to log something it also obtains a Logger. So the Loggers used for logging and configuration were the same. In order to reconfigure, Log4j 1 would clear everything from the Loggers and then start adding configuration back to them as it processed the configuration. During the time that the Loggers are cleared and before configuration is added back events are ignored.
>>
>> Log4j 2 doesn’t work this way at all. When the configuration is read a set of LoggerConfig objects is created. These all contain the same information that is in the configuration file. When an application wants to log it gets a Logger. The Logger looks for a LoggerConfig with its name or, if one isn’t found, one of its ancestors. The Logger then is set with a reference to the LoggerConfig that provides its configuration and it copies that LoggerConfig’s logging level into it to improve performance. Thus, when you want to  change a logging level you need to locate the LoggerConfig for the Logger, update its logging level, and then call updateLoggers to cause all Loggers to reevaluate which LoggerConfig they should be using and what their current logging level is.
>>
>> There are several ways to deal with changes.
>> You add a listener to handle configuration changes. This would allow you to reinsert changes to the configuration.
>> You can create your own Configuration and combine it with the user’s configuration using a CompositeConfiguration. Your configuration can be created with a config file or via the ConfigurationBuilder.
>> You can extend XMLConfiguration and/or PropertiesConfiguration and add your own definitions to it.
>>
>> I am sure there are other ways this can all be done depending on what you are trying to achieve. If you modify the logging level of a LoggerConfig and then a reconfigure occurs Log4j will automatically handle resetting the configuration. You don’t have to do anything. If you want to reinsert changes to the user’s configuration then you have to use one of the techniques I noted above.
>>
>> Ralph
>>
>>
>>
>>
>>> On Dec 17, 2017, at 3:40 PM, Paladox <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>> "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 set loggers through java then reloading the file would not affect them. So i guess they wanted to make sure everything goes back to the way it was.
>>> More explementation, because we have a ssh command that can set log levels for either all or specific loggers we want to be able to remove the levels to put it back to how it was done when the application was started. So ie if we set debug on com.google. then that will be added to the loggers as
>>> com.google = DEBUG
>>> but when the application was started that was not in the loggers so we did not get any debug in the output.
>>> But we want to set it to the default by removing com.google as loggers in com.google have different levels. IE in the log4j2.properties file we have
>>> com.google.gerrit.sshd.GerritServerSession which is set to WARN
>>>
>>> but now because we did com.google @ debug com.google.gerrit.sshd.GerritServerSession will be debug and everything else under com.google class path that uses loggers.
>>> But users would not know every logger under com.google so they wouldn't be able to put them all back to the default so we set the log level to null and reloaded the file without loosing any java appenders. But with log4j2 it seems to restart as new.
>>>     On Sunday, 17 December 2017, 22:25:28 GMT, Ralph Goers <[hidden email] <mailto:[hidden email]>> wrote:  
>>>
>>> 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 use their own configuration but not why you want to add appenders and “other things” or what requirement you are trying to solve with them. What I need here is some sort of “user story definition” like - “As a user of Gerrit I need to be able to provide my own logging configuration while Gerrit makes sure that error conditions are always logged even if my configuration doesn’t specify it” or something like that. We can tell you how to implement something once we understand what you are really trying to achieve. You probably have done this before, but in case you haven’t done that before you can look at https://www.mountaingoatsoftware.com/agile/user-stories  <https://www.mountaingoatsoftware.com/agile/user-stories><https://www.mountaingoatsoftware.com/agile/user-stories <https://www.mountaingoatsoftware.com/agile/user-stories>>. Also, you might have a definition of what you want the experience for a user of Gerrit to be vs that of a developer. If so, tell me what they both are.
>>>
>>> Ralph
>>>
>>>> On Dec 17, 2017, at 1:58 PM, Paladox <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>>
>>>> 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 other things because we want users to customise the behavour through a config. For example some users want log4j to log with json instead of the pattern layout. Though if users want to modify it more then a config they use the system property to override the default log4j configuation file and use there own.
>>>>
>>>> On Sunday, 17 December 2017, 20:44:09 GMT, Ralph Goers <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>>
>>>> "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 property file” - what property file? The log4j 2 configuration file?  Why would you set the log sell to null before reloaded the configuration?
>>>>
>>>> “Without losing any appenders created with Java” - How are the appenders created with Java and why are they created with Java? You could use a composite configuration that adds your the “standard” configuration to what a user provides or you could extend XMLConfiguratoin with your own extra configuration.
>>>>
>>>> In short, you still haven’t described what you want the resultant behavior to be. You are still describing “How?” instead of “What?”.  In other words - something like - “We want to require that a specific logger is always logged at error and those logs are always routed to a file named xxxx, regardless of what other things the user might configure”.
>>>>
>>>> Ralph
>>>>
>>>>> On Dec 17, 2017, at 11:22 AM, Paladox <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>>>>>
>>>>> 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 GMT, Ralph Goers <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:  
>>>>>
>>>>> 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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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 (Enumeration<Logger> logger = LogManager.getCurrentLoggers(); logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);    }
>>>>>>     String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION));    } else {      PropertyConfigurator.configure(new URL(path));    }  }
>>>>>> in log4j2 i carn't find any good replacements. Setting setLevel results in null pointer same would be for setAllLevels. (Works in log4j1).
>>>>>> Then when i try to reload the properties file it just resets everything then loads the file. Thus if you used some java code it would be lost and you would have to restart your java application to get the appenders or anything added with java code.
>>>>>> In log4j1 you need PropertyConfigurator.configure which re added the log levels that were from the file without resetting anything.
>>>>>>   On Friday, 15 December 2017, 16:50:28 GMT, Paladox <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:  
>>>>>>
>>>>>> Hi, im wondering if i could have some help with migrating from log4j1 to log4j2 please?
>>>>>> Im trying to update gerrit to log4j2 but am stuck on some things. [1]
>>>>>> 1. How do i migrate from PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2 compatible please?
>>>>>> Im trying to migrate all the way without trying to use log4j1 compatible api log4j2. (Though im still pulling it in i am trying not to use it).
>>>>>> I found doing something like
>>>>>>     String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source = ConfigurationSource.fromResource(LOG_CONFIGURATION, null);      Configurator.initialize(null, source);    } else {      URL in = new URL(path);      Configurator.initialize((String) null, null, in.toURI());    }
>>>>>> could work but then it wont reload the configuation without restarting the configuation as new (ie gets rid of everything). which .reconfigure() does.
>>>>>> Im trying to reset log levels to null so that we can reload the configuation but reconfigure gets rid of everything thus causing problems if you used java to add appenders or anything else. see [2]
>>>>>> Also how would i migrate from using removeAllAppenders to log4j2 compatible code please?
>>>>>> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/  <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/><https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/ <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/>>
>>>>>> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java  <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java><https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>>>>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>>>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>

Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Paladox
 “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 changing programmatically? Just the log levels of Loggers? Are you wanting those changes re-applied after a reconfiguration?"
We had log level set to null so that when we reloaded the file it would add back the loggers. But it wouldn't get rid of any appenders which we set through java.

We are trying to reset log levels back to what they were set in the file without losing any appenders.
    On Tuesday, 19 December 2017, 23:35:05 GMT, Ralph Goers <[hidden email]> wrote:  
 
 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:
Re-read the configuration and create a brand new Configuration.
Start the new Configuration (starts the new Appenders).
Set the LoggerContext to point to the new Configuration.
Update all Loggers to use the new Configuration.
Stop the old Configuration.

This happens automatically if you have set monitorInterval to a non-zero value on a Configuration element in a config file. You can force it to happen by calling LoggerContext.reconfigure().

If you have made any programmatic changes to the configuration they will be lost during this process.  If you are “remembering the changes” you made programmatically and have captured them you can just reapply them after Log4j 2 reconfigures.

Again, what is the behavior you are looking for? What are you changing programmatically? Just the log levels of Loggers? Are you wanting those changes re-applied after a reconfiguration?

Ralph




> On Dec 19, 2017, at 2:28 PM, Paladox <[hidden email]> wrote:
>
> 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 set in the configuation file.
> In log4j2 it seems to not support a way like https://github.com/apache/log4j/blob/c5f4279081091e562c44bb753f6e52dc6be5fa52/src/main/java/org/apache/log4j/PropertyConfigurator.java#L120 
>
> "    Read configuration from a file. <b>The existing configuration is    not cleared nor reset.</b> If you require a different behavior,    then call {@link  LogManager#resetConfiguration    resetConfiguration} method before calling    <code>doConfigure</code>."
> Thats one of the reasons why we had to use null as it did not reset it (which we doint want anyways) we needed to remove the log level to prevent it for example writing tons of info if you have it set to DEBUG. But by re adding the file we got the loggers back to the default value we had them set at.
> Now in log4j2 there dosen't seem to be anything similar except from the one you pointed too but that reset everything.
>
>    On Tuesday, 19 December 2017, 21:11:26 GMT, Ralph Goers <[hidden email]> wrote: 
>
> 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 to add. I would then use Configurator.initialize(“file1, file2”) to combine the user’s configuration with yours.
>
> Ralph
>
>> On Dec 19, 2017, at 12:23 PM, Paladox <[hidden email]> wrote:
>>
>> 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 without causing a null pointer.
>>
>> I see there's ConfigurationBuilder as you pointed too but we use a mixture of java / using the properties files.
>>
>> So we add a appender with java but add ConsoleAppender through the properties file.
>>
>> Reading this https://github.com/apache/log4j/blob/c5f4279081091e562c44bb753f6e52dc6be5fa52/src/main/java/org/apache/log4j/PropertyConfigurator.java#L120 seems to say that it just reads the configuation but dosen't clear anything. I wonder would something like be able to be added to log4j2 please?
>>
>>
>>
>> On Sunday, 17 December 2017, 23:30:02 GMT, Ralph Goers <[hidden email]> wrote:
>>
>>
>> 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 and get it from there. So setting a Logger’s logging level to null basically said “look at your parent”.  When an application wants to log something it also obtains a Logger. So the Loggers used for logging and configuration were the same. In order to reconfigure, Log4j 1 would clear everything from the Loggers and then start adding configuration back to them as it processed the configuration. During the time that the Loggers are cleared and before configuration is added back events are ignored.
>>
>> Log4j 2 doesn’t work this way at all. When the configuration is read a set of LoggerConfig objects is created. These all contain the same information that is in the configuration file. When an application wants to log it gets a Logger. The Logger looks for a LoggerConfig with its name or, if one isn’t found, one of its ancestors. The Logger then is set with a reference to the LoggerConfig that provides its configuration and it copies that LoggerConfig’s logging level into it to improve performance. Thus, when you want to  change a logging level you need to locate the LoggerConfig for the Logger, update its logging level, and then call updateLoggers to cause all Loggers to reevaluate which LoggerConfig they should be using and what their current logging level is.
>>
>> There are several ways to deal with changes.
>> You add a listener to handle configuration changes. This would allow you to reinsert changes to the configuration.
>> You can create your own Configuration and combine it with the user’s configuration using a CompositeConfiguration. Your configuration can be created with a config file or via the ConfigurationBuilder.
>> You can extend XMLConfiguration and/or PropertiesConfiguration and add your own definitions to it.
>>
>> I am sure there are other ways this can all be done depending on what you are trying to achieve. If you modify the logging level of a LoggerConfig and then a reconfigure occurs Log4j will automatically handle resetting the configuration. You don’t have to do anything. If you want to reinsert changes to the user’s configuration then you have to use one of the techniques I noted above.
>>
>> Ralph
>>
>>
>>
>>
>>> On Dec 17, 2017, at 3:40 PM, Paladox <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>> "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 set loggers through java then reloading the file would not affect them. So i guess they wanted to make sure everything goes back to the way it was.
>>> More explementation, because we have a ssh command that can set log levels for either all or specific loggers we want to be able to remove the levels to put it back to how it was done when the application was started. So ie if we set debug on com.google. then that will be added to the loggers as
>>> com.google = DEBUG
>>> but when the application was started that was not in the loggers so we did not get any debug in the output.
>>> But we want to set it to the default by removing com.google as loggers in com.google have different levels. IE in the log4j2.properties file we have
>>> com.google.gerrit.sshd.GerritServerSession which is set to WARN
>>>
>>> but now because we did com.google @ debug com.google.gerrit.sshd.GerritServerSession will be debug and everything else under com.google class path that uses loggers.
>>> But users would not know every logger under com.google so they wouldn't be able to put them all back to the default so we set the log level to null and reloaded the file without loosing any java appenders. But with log4j2 it seems to restart as new.
>>>    On Sunday, 17 December 2017, 22:25:28 GMT, Ralph Goers <[hidden email] <mailto:[hidden email]>> wrote: 
>>>
>>> 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 use their own configuration but not why you want to add appenders and “other things” or what requirement you are trying to solve with them. What I need here is some sort of “user story definition” like - “As a user of Gerrit I need to be able to provide my own logging configuration while Gerrit makes sure that error conditions are always logged even if my configuration doesn’t specify it” or something like that. We can tell you how to implement something once we understand what you are really trying to achieve. You probably have done this before, but in case you haven’t done that before you can look at https://www.mountaingoatsoftware.com/agile/user-stories  <https://www.mountaingoatsoftware.com/agile/user-stories><https://www.mountaingoatsoftware.com/agile/user-stories <https://www.mountaingoatsoftware.com/agile/user-stories>>. Also, you might have a definition of what you want the experience for a user of Gerrit to be vs that of a developer. If so, tell me what they both are.
>>>
>>> Ralph
>>>
>>>> On Dec 17, 2017, at 1:58 PM, Paladox <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>>
>>>> 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 other things because we want users to customise the behavour through a config. For example some users want log4j to log with json instead of the pattern layout. Though if users want to modify it more then a config they use the system property to override the default log4j configuation file and use there own.
>>>>
>>>> On Sunday, 17 December 2017, 20:44:09 GMT, Ralph Goers <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>>
>>>> "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 property file” - what property file? The log4j 2 configuration file?  Why would you set the log sell to null before reloaded the configuration?
>>>>
>>>> “Without losing any appenders created with Java” - How are the appenders created with Java and why are they created with Java? You could use a composite configuration that adds your the “standard” configuration to what a user provides or you could extend XMLConfiguratoin with your own extra configuration.
>>>>
>>>> In short, you still haven’t described what you want the resultant behavior to be. You are still describing “How?” instead of “What?”.  In other words - something like - “We want to require that a specific logger is always logged at error and those logs are always routed to a file named xxxx, regardless of what other things the user might configure”.
>>>>
>>>> Ralph
>>>>
>>>>> On Dec 17, 2017, at 11:22 AM, Paladox <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>>>>>
>>>>> 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 GMT, Ralph Goers <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote: 
>>>>>
>>>>> 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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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 (Enumeration<Logger> logger = LogManager.getCurrentLoggers(); logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);    }
>>>>>>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION));    } else {      PropertyConfigurator.configure(new URL(path));    }  }
>>>>>> in log4j2 i carn't find any good replacements. Setting setLevel results in null pointer same would be for setAllLevels. (Works in log4j1).
>>>>>> Then when i try to reload the properties file it just resets everything then loads the file. Thus if you used some java code it would be lost and you would have to restart your java application to get the appenders or anything added with java code.
>>>>>> In log4j1 you need PropertyConfigurator.configure which re added the log levels that were from the file without resetting anything.
>>>>>>  On Friday, 15 December 2017, 16:50:28 GMT, Paladox <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote: 
>>>>>>
>>>>>> Hi, im wondering if i could have some help with migrating from log4j1 to log4j2 please?
>>>>>> Im trying to update gerrit to log4j2 but am stuck on some things. [1]
>>>>>> 1. How do i migrate from PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2 compatible please?
>>>>>> Im trying to migrate all the way without trying to use log4j1 compatible api log4j2. (Though im still pulling it in i am trying not to use it).
>>>>>> I found doing something like
>>>>>>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);    if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source = ConfigurationSource.fromResource(LOG_CONFIGURATION, null);      Configurator.initialize(null, source);    } else {      URL in = new URL(path);      Configurator.initialize((String) null, null, in.toURI());    }
>>>>>> could work but then it wont reload the configuation without restarting the configuation as new (ie gets rid of everything). which .reconfigure() does.
>>>>>> Im trying to reset log levels to null so that we can reload the configuation but reconfigure gets rid of everything thus causing problems if you used java to add appenders or anything else. see [2]
>>>>>> Also how would i migrate from using removeAllAppenders to log4j2 compatible code please?
>>>>>> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/  <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/><https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/ <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/>>
>>>>>> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java  <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java><https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java <https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>>>>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>>>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
 
Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Matt Sicker
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 swap it). You can specify an implementation of MergeStrategy via the
log4j2.mergeStrategy global property for more complex merging.

On 20 December 2017 at 05:52, Paladox <[hidden email]>
wrote:

>  “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 changing
> programmatically? Just the log levels of Loggers? Are you wanting those
> changes re-applied after a reconfiguration?"
> We had log level set to null so that when we reloaded the file it would
> add back the loggers. But it wouldn't get rid of any appenders which we set
> through java.
>
> We are trying to reset log levels back to what they were set in the file
> without losing any appenders.
>     On Tuesday, 19 December 2017, 23:35:05 GMT, Ralph Goers <
> [hidden email]> wrote:
>
>  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:
> Re-read the configuration and create a brand new Configuration.
> Start the new Configuration (starts the new Appenders).
> Set the LoggerContext to point to the new Configuration.
> Update all Loggers to use the new Configuration.
> Stop the old Configuration.
>
> This happens automatically if you have set monitorInterval to a non-zero
> value on a Configuration element in a config file. You can force it to
> happen by calling LoggerContext.reconfigure().
>
> If you have made any programmatic changes to the configuration they will
> be lost during this process.  If you are “remembering the changes” you made
> programmatically and have captured them you can just reapply them after
> Log4j 2 reconfigures.
>
> Again, what is the behavior you are looking for? What are you changing
> programmatically? Just the log levels of Loggers? Are you wanting those
> changes re-applied after a reconfiguration?
>
> Ralph
>
>
>
>
> > On Dec 19, 2017, at 2:28 PM, Paladox <[hidden email]>
> wrote:
> >
> > 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 set in the
> configuation file.
> > In log4j2 it seems to not support a way like https://github.com/apache/
> log4j/blob/c5f4279081091e562c44bb753f6e52dc6be5fa52/src/main/java/org/
> apache/log4j/PropertyConfigurator.java#L120
> >
> > "    Read configuration from a file. <b>The existing configuration is
> not cleared nor reset.</b> If you require a different behavior,    then
> call {@link  LogManager#resetConfiguration    resetConfiguration} method
> before calling    <code>doConfigure</code>."
> > Thats one of the reasons why we had to use null as it did not reset it
> (which we doint want anyways) we needed to remove the log level to prevent
> it for example writing tons of info if you have it set to DEBUG. But by re
> adding the file we got the loggers back to the default value we had them
> set at.
> > Now in log4j2 there dosen't seem to be anything similar except from the
> one you pointed too but that reset everything.
> >
> >    On Tuesday, 19 December 2017, 21:11:26 GMT, Ralph Goers <
> [hidden email]> wrote:
> >
> > 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 to add. I would
> then use Configurator.initialize(“file1, file2”) to combine the user’s
> configuration with yours.
> >
> > Ralph
> >
> >> On Dec 19, 2017, at 12:23 PM, Paladox <[hidden email]>
> wrote:
> >>
> >> 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 without causing a null pointer.
> >>
> >> I see there's ConfigurationBuilder as you pointed too but we use a
> mixture of java / using the properties files.
> >>
> >> So we add a appender with java but add ConsoleAppender through the
> properties file.
> >>
> >> Reading this https://github.com/apache/log4j/blob/
> c5f4279081091e562c44bb753f6e52dc6be5fa52/src/main/java/org/apache/log4j/
> PropertyConfigurator.java#L120 seems to say that it just reads the
> configuation but dosen't clear anything. I wonder would something like be
> able to be added to log4j2 please?
> >>
> >>
> >>
> >> On Sunday, 17 December 2017, 23:30:02 GMT, Ralph Goers <
> [hidden email]> wrote:
> >>
> >>
> >> 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
> and get it from there. So setting a Logger’s logging level to null
> basically said “look at your parent”.  When an application wants to log
> something it also obtains a Logger. So the Loggers used for logging and
> configuration were the same. In order to reconfigure, Log4j 1 would clear
> everything from the Loggers and then start adding configuration back to
> them as it processed the configuration. During the time that the Loggers
> are cleared and before configuration is added back events are ignored.
> >>
> >> Log4j 2 doesn’t work this way at all. When the configuration is read a
> set of LoggerConfig objects is created. These all contain the same
> information that is in the configuration file. When an application wants to
> log it gets a Logger. The Logger looks for a LoggerConfig with its name or,
> if one isn’t found, one of its ancestors. The Logger then is set with a
> reference to the LoggerConfig that provides its configuration and it copies
> that LoggerConfig’s logging level into it to improve performance. Thus,
> when you want to  change a logging level you need to locate the
> LoggerConfig for the Logger, update its logging level, and then call
> updateLoggers to cause all Loggers to reevaluate which LoggerConfig they
> should be using and what their current logging level is.
> >>
> >> There are several ways to deal with changes.
> >> You add a listener to handle configuration changes. This would allow
> you to reinsert changes to the configuration.
> >> You can create your own Configuration and combine it with the user’s
> configuration using a CompositeConfiguration. Your configuration can be
> created with a config file or via the ConfigurationBuilder.
> >> You can extend XMLConfiguration and/or PropertiesConfiguration and add
> your own definitions to it.
> >>
> >> I am sure there are other ways this can all be done depending on what
> you are trying to achieve. If you modify the logging level of a
> LoggerConfig and then a reconfigure occurs Log4j will automatically handle
> resetting the configuration. You don’t have to do anything. If you want to
> reinsert changes to the user’s configuration then you have to use one of
> the techniques I noted above.
> >>
> >> Ralph
> >>
> >>
> >>
> >>
> >>> On Dec 17, 2017, at 3:40 PM, Paladox <[hidden email]
> <mailto:[hidden email]>> wrote:
> >>>
> >>> "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 set loggers through java
> then reloading the file would not affect them. So i guess they wanted to
> make sure everything goes back to the way it was.
> >>> More explementation, because we have a ssh command that can set log
> levels for either all or specific loggers we want to be able to remove the
> levels to put it back to how it was done when the application was started.
> So ie if we set debug on com.google. then that will be added to the loggers
> as
> >>> com.google = DEBUG
> >>> but when the application was started that was not in the loggers so we
> did not get any debug in the output.
> >>> But we want to set it to the default by removing com.google as loggers
> in com.google have different levels. IE in the log4j2.properties file we
> have
> >>> com.google.gerrit.sshd.GerritServerSession which is set to WARN
> >>>
> >>> but now because we did com.google @ debug com.google.gerrit.sshd.GerritServerSession
> will be debug and everything else under com.google class path that uses
> loggers.
> >>> But users would not know every logger under com.google so they
> wouldn't be able to put them all back to the default so we set the log
> level to null and reloaded the file without loosing any java appenders. But
> with log4j2 it seems to restart as new.
> >>>    On Sunday, 17 December 2017, 22:25:28 GMT, Ralph Goers <
> [hidden email] <mailto:[hidden email]>> wrote:
> >>>
> >>> 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 use their own configuration but not why you want to add appenders
> and “other things” or what requirement you are trying to solve with them.
> What I need here is some sort of “user story definition” like - “As a user
> of Gerrit I need to be able to provide my own logging configuration while
> Gerrit makes sure that error conditions are always logged even if my
> configuration doesn’t specify it” or something like that. We can tell you
> how to implement something once we understand what you are really trying to
> achieve. You probably have done this before, but in case you haven’t done
> that before you can look at https://www.mountaingoatsoftware.com/
> agile/user-stories  <https://www.mountaingoatsoftware.com/
> agile/user-stories><https://www.mountaingoatsoftware.com/
> agile/user-stories <https://www.mountaingoatsoftware.com/
> agile/user-stories>>. Also, you might have a definition of what you want
> the experience for a user of Gerrit to be vs that of a developer. If so,
> tell me what they both are.
> >>>
> >>> Ralph
> >>>
> >>>> On Dec 17, 2017, at 1:58 PM, Paladox <[hidden email]
> <mailto:[hidden email]>> wrote:
> >>>>
> >>>>
> >>>> 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 other
> things because we want users to customise the behavour through a config.
> For example some users want log4j to log with json instead of the pattern
> layout. Though if users want to modify it more then a config they use the
> system property to override the default log4j configuation file and use
> there own.
> >>>>
> >>>> On Sunday, 17 December 2017, 20:44:09 GMT, Ralph Goers <
> [hidden email] <mailto:[hidden email]>> wrote:
> >>>>
> >>>>
> >>>> "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 property file” - what property file? The log4j 2
> configuration file?  Why would you set the log sell to null before reloaded
> the configuration?
> >>>>
> >>>> “Without losing any appenders created with Java” - How are the
> appenders created with Java and why are they created with Java? You could
> use a composite configuration that adds your the “standard” configuration
> to what a user provides or you could extend XMLConfiguratoin with your own
> extra configuration.
> >>>>
> >>>> In short, you still haven’t described what you want the resultant
> behavior to be. You are still describing “How?” instead of “What?”.  In
> other words - something like - “We want to require that a specific logger
> is always logged at error and those logs are always routed to a file named
> xxxx, regardless of what other things the user might configure”.
> >>>>
> >>>> Ralph
> >>>>
> >>>>> On Dec 17, 2017, at 11:22 AM, Paladox <[hidden email]
> <mailto:[hidden email]> <mailto:thomasmulhall410@
> yahoo.com.INVALID <mailto:[hidden email]>>> wrote:
> >>>>>
> >>>>> 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 GMT, Ralph Goers <
> [hidden email] <mailto:[hidden email]> <mailto:
> [hidden email] <mailto:[hidden email]>>> wrote:
> >>>>>
> >>>>> 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 <[hidden email]
> <mailto:[hidden email]> <mailto:thomasmulhall410@
> yahoo.com.INVALID <mailto:[hidden email]>>> 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
> (Enumeration<Logger> logger = LogManager.getCurrentLoggers();
> logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);
>   }
> >>>>>>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);
> if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.
> configure(Loader.getResource(LOG_CONFIGURATION));    } else {
> PropertyConfigurator.configure(new URL(path));    }  }
> >>>>>> in log4j2 i carn't find any good replacements. Setting setLevel
> results in null pointer same would be for setAllLevels. (Works in log4j1).
> >>>>>> Then when i try to reload the properties file it just resets
> everything then loads the file. Thus if you used some java code it would be
> lost and you would have to restart your java application to get the
> appenders or anything added with java code.
> >>>>>> In log4j1 you need PropertyConfigurator.configure which re added
> the log levels that were from the file without resetting anything.
> >>>>>>  On Friday, 15 December 2017, 16:50:28 GMT, Paladox <
> [hidden email] <mailto:thomasmulhall410@
> yahoo.com.INVALID> <mailto:[hidden email] <mailto:
> [hidden email]>>> wrote:
> >>>>>>
> >>>>>> Hi, im wondering if i could have some help with migrating from
> log4j1 to log4j2 please?
> >>>>>> Im trying to update gerrit to log4j2 but am stuck on some things.
> [1]
> >>>>>> 1. How do i migrate from PropertyConfigurator.
> configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2
> compatible please?
> >>>>>> Im trying to migrate all the way without trying to use log4j1
> compatible api log4j2. (Though im still pulling it in i am trying not to
> use it).
> >>>>>> I found doing something like
> >>>>>>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);
> if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source =
> ConfigurationSource.fromResource(LOG_CONFIGURATION, null);
> Configurator.initialize(null, source);    } else {      URL in = new
> URL(path);      Configurator.initialize((String) null, null,
> in.toURI());    }
> >>>>>> could work but then it wont reload the configuation without
> restarting the configuation as new (ie gets rid of everything). which
> .reconfigure() does.
> >>>>>> Im trying to reset log levels to null so that we can reload the
> configuation but reconfigure gets rid of everything thus causing problems
> if you used java to add appenders or anything else. see [2]
> >>>>>> Also how would i migrate from using removeAllAppenders to log4j2
> compatible code please?
> >>>>>> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/  <
> https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/><
> https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/ <
> https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/>>
> >>>>>> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/
> 142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
> <https://gerrit-review.googlesource.com/#/c/gerrit/+/
> 142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
> ><https://gerrit-review.googlesource.com/#/c/gerrit/+/
> 142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
> <https://gerrit-review.googlesource.com/#/c/gerrit/+/
> 142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
> >>
> >>>>>
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------------
> ---------
> >>>>> To unsubscribe, e-mail: [hidden email]
> <mailto:[hidden email]> <mailto:log4j-user-
> [hidden email] <mailto:log4j-user-
> [hidden email]>>
> >>>>> For additional commands, e-mail: [hidden email]
> <mailto:[hidden email]> <mailto:log4j-user-help@
> logging.apache.org <mailto:[hidden email]>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [hidden email]
> <mailto:[hidden email]> <mailto:log4j-user-
> [hidden email] <mailto:log4j-user-
> [hidden email]>>
> >>>> For additional commands, e-mail: [hidden email]
> <mailto:[hidden email]> <mailto:log4j-user-help@
> logging.apache.org <mailto:[hidden email]>>
>
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Paladox
 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 <[hidden email]> wrote:  
 
 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 swap it). You can specify an implementation of MergeStrategy via the
log4j2.mergeStrategy global property for more complex merging.

On 20 December 2017 at 05:52, Paladox <[hidden email]>
wrote:

>  “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 changing
> programmatically? Just the log levels of Loggers? Are you wanting those
> changes re-applied after a reconfiguration?"
> We had log level set to null so that when we reloaded the file it would
> add back the loggers. But it wouldn't get rid of any appenders which we set
> through java.
>
> We are trying to reset log levels back to what they were set in the file
> without losing any appenders.
>    On Tuesday, 19 December 2017, 23:35:05 GMT, Ralph Goers <
> [hidden email]> wrote:
>
>  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:
> Re-read the configuration and create a brand new Configuration.
> Start the new Configuration (starts the new Appenders).
> Set the LoggerContext to point to the new Configuration.
> Update all Loggers to use the new Configuration.
> Stop the old Configuration.
>
> This happens automatically if you have set monitorInterval to a non-zero
> value on a Configuration element in a config file. You can force it to
> happen by calling LoggerContext.reconfigure().
>
> If you have made any programmatic changes to the configuration they will
> be lost during this process.  If you are “remembering the changes” you made
> programmatically and have captured them you can just reapply them after
> Log4j 2 reconfigures.
>
> Again, what is the behavior you are looking for? What are you changing
> programmatically? Just the log levels of Loggers? Are you wanting those
> changes re-applied after a reconfiguration?
>
> Ralph
>
>
>
>
> > On Dec 19, 2017, at 2:28 PM, Paladox <[hidden email]>
> wrote:
> >
> > 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 set in the
> configuation file.
> > In log4j2 it seems to not support a way like https://github.com/apache/
> log4j/blob/c5f4279081091e562c44bb753f6e52dc6be5fa52/src/main/java/org/
> apache/log4j/PropertyConfigurator.java#L120
> >
> > "    Read configuration from a file. <b>The existing configuration is
> not cleared nor reset.</b> If you require a different behavior,    then
> call {@link  LogManager#resetConfiguration    resetConfiguration} method
> before calling    <code>doConfigure</code>."
> > Thats one of the reasons why we had to use null as it did not reset it
> (which we doint want anyways) we needed to remove the log level to prevent
> it for example writing tons of info if you have it set to DEBUG. But by re
> adding the file we got the loggers back to the default value we had them
> set at.
> > Now in log4j2 there dosen't seem to be anything similar except from the
> one you pointed too but that reset everything.
> >
> >    On Tuesday, 19 December 2017, 21:11:26 GMT, Ralph Goers <
> [hidden email]> wrote:
> >
> > 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 to add. I would
> then use Configurator.initialize(“file1, file2”) to combine the user’s
> configuration with yours.
> >
> > Ralph
> >
> >> On Dec 19, 2017, at 12:23 PM, Paladox <[hidden email]>
> wrote:
> >>
> >> 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 without causing a null pointer.
> >>
> >> I see there's ConfigurationBuilder as you pointed too but we use a
> mixture of java / using the properties files.
> >>
> >> So we add a appender with java but add ConsoleAppender through the
> properties file.
> >>
> >> Reading this https://github.com/apache/log4j/blob/
> c5f4279081091e562c44bb753f6e52dc6be5fa52/src/main/java/org/apache/log4j/
> PropertyConfigurator.java#L120 seems to say that it just reads the
> configuation but dosen't clear anything. I wonder would something like be
> able to be added to log4j2 please?
> >>
> >>
> >>
> >> On Sunday, 17 December 2017, 23:30:02 GMT, Ralph Goers <
> [hidden email]> wrote:
> >>
> >>
> >> 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
> and get it from there. So setting a Logger’s logging level to null
> basically said “look at your parent”.  When an application wants to log
> something it also obtains a Logger. So the Loggers used for logging and
> configuration were the same. In order to reconfigure, Log4j 1 would clear
> everything from the Loggers and then start adding configuration back to
> them as it processed the configuration. During the time that the Loggers
> are cleared and before configuration is added back events are ignored.
> >>
> >> Log4j 2 doesn’t work this way at all. When the configuration is read a
> set of LoggerConfig objects is created. These all contain the same
> information that is in the configuration file. When an application wants to
> log it gets a Logger. The Logger looks for a LoggerConfig with its name or,
> if one isn’t found, one of its ancestors. The Logger then is set with a
> reference to the LoggerConfig that provides its configuration and it copies
> that LoggerConfig’s logging level into it to improve performance. Thus,
> when you want to  change a logging level you need to locate the
> LoggerConfig for the Logger, update its logging level, and then call
> updateLoggers to cause all Loggers to reevaluate which LoggerConfig they
> should be using and what their current logging level is.
> >>
> >> There are several ways to deal with changes.
> >> You add a listener to handle configuration changes. This would allow
> you to reinsert changes to the configuration.
> >> You can create your own Configuration and combine it with the user’s
> configuration using a CompositeConfiguration. Your configuration can be
> created with a config file or via the ConfigurationBuilder.
> >> You can extend XMLConfiguration and/or PropertiesConfiguration and add
> your own definitions to it.
> >>
> >> I am sure there are other ways this can all be done depending on what
> you are trying to achieve. If you modify the logging level of a
> LoggerConfig and then a reconfigure occurs Log4j will automatically handle
> resetting the configuration. You don’t have to do anything. If you want to
> reinsert changes to the user’s configuration then you have to use one of
> the techniques I noted above.
> >>
> >> Ralph
> >>
> >>
> >>
> >>
> >>> On Dec 17, 2017, at 3:40 PM, Paladox <[hidden email]
> <mailto:[hidden email]>> wrote:
> >>>
> >>> "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 set loggers through java
> then reloading the file would not affect them. So i guess they wanted to
> make sure everything goes back to the way it was.
> >>> More explementation, because we have a ssh command that can set log
> levels for either all or specific loggers we want to be able to remove the
> levels to put it back to how it was done when the application was started.
> So ie if we set debug on com.google. then that will be added to the loggers
> as
> >>> com.google = DEBUG
> >>> but when the application was started that was not in the loggers so we
> did not get any debug in the output.
> >>> But we want to set it to the default by removing com.google as loggers
> in com.google have different levels. IE in the log4j2.properties file we
> have
> >>> com.google.gerrit.sshd.GerritServerSession which is set to WARN
> >>>
> >>> but now because we did com.google @ debug com.google.gerrit.sshd.GerritServerSession
> will be debug and everything else under com.google class path that uses
> loggers.
> >>> But users would not know every logger under com.google so they
> wouldn't be able to put them all back to the default so we set the log
> level to null and reloaded the file without loosing any java appenders. But
> with log4j2 it seems to restart as new.
> >>>    On Sunday, 17 December 2017, 22:25:28 GMT, Ralph Goers <
> [hidden email] <mailto:[hidden email]>> wrote:
> >>>
> >>> 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 use their own configuration but not why you want to add appenders
> and “other things” or what requirement you are trying to solve with them.
> What I need here is some sort of “user story definition” like - “As a user
> of Gerrit I need to be able to provide my own logging configuration while
> Gerrit makes sure that error conditions are always logged even if my
> configuration doesn’t specify it” or something like that. We can tell you
> how to implement something once we understand what you are really trying to
> achieve. You probably have done this before, but in case you haven’t done
> that before you can look at https://www.mountaingoatsoftware.com/
> agile/user-stories  <https://www.mountaingoatsoftware.com/
> agile/user-stories><https://www.mountaingoatsoftware.com/
> agile/user-stories <https://www.mountaingoatsoftware.com/
> agile/user-stories>>. Also, you might have a definition of what you want
> the experience for a user of Gerrit to be vs that of a developer. If so,
> tell me what they both are.
> >>>
> >>> Ralph
> >>>
> >>>> On Dec 17, 2017, at 1:58 PM, Paladox <[hidden email]
> <mailto:[hidden email]>> wrote:
> >>>>
> >>>>
> >>>> 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 other
> things because we want users to customise the behavour through a config.
> For example some users want log4j to log with json instead of the pattern
> layout. Though if users want to modify it more then a config they use the
> system property to override the default log4j configuation file and use
> there own.
> >>>>
> >>>> On Sunday, 17 December 2017, 20:44:09 GMT, Ralph Goers <
> [hidden email] <mailto:[hidden email]>> wrote:
> >>>>
> >>>>
> >>>> "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 property file” - what property file? The log4j 2
> configuration file?  Why would you set the log sell to null before reloaded
> the configuration?
> >>>>
> >>>> “Without losing any appenders created with Java” - How are the
> appenders created with Java and why are they created with Java? You could
> use a composite configuration that adds your the “standard” configuration
> to what a user provides or you could extend XMLConfiguratoin with your own
> extra configuration.
> >>>>
> >>>> In short, you still haven’t described what you want the resultant
> behavior to be. You are still describing “How?” instead of “What?”.  In
> other words - something like - “We want to require that a specific logger
> is always logged at error and those logs are always routed to a file named
> xxxx, regardless of what other things the user might configure”.
> >>>>
> >>>> Ralph
> >>>>
> >>>>> On Dec 17, 2017, at 11:22 AM, Paladox <[hidden email]
> <mailto:[hidden email]> <mailto:thomasmulhall410@
> yahoo.com.INVALID <mailto:[hidden email]>>> wrote:
> >>>>>
> >>>>> 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 GMT, Ralph Goers <
> [hidden email] <mailto:[hidden email]> <mailto:
> [hidden email] <mailto:[hidden email]>>> wrote:
> >>>>>
> >>>>> 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 <[hidden email]
> <mailto:[hidden email]> <mailto:thomasmulhall410@
> yahoo.com.INVALID <mailto:[hidden email]>>> 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
> (Enumeration<Logger> logger = LogManager.getCurrentLoggers();
> logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);
>  }
> >>>>>>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);
> if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.
> configure(Loader.getResource(LOG_CONFIGURATION));    } else {
> PropertyConfigurator.configure(new URL(path));    }  }
> >>>>>> in log4j2 i carn't find any good replacements. Setting setLevel
> results in null pointer same would be for setAllLevels. (Works in log4j1).
> >>>>>> Then when i try to reload the properties file it just resets
> everything then loads the file. Thus if you used some java code it would be
> lost and you would have to restart your java application to get the
> appenders or anything added with java code.
> >>>>>> In log4j1 you need PropertyConfigurator.configure which re added
> the log levels that were from the file without resetting anything.
> >>>>>>  On Friday, 15 December 2017, 16:50:28 GMT, Paladox <
> [hidden email] <mailto:thomasmulhall410@
> yahoo.com.INVALID> <mailto:[hidden email] <mailto:
> [hidden email]>>> wrote:
> >>>>>>
> >>>>>> Hi, im wondering if i could have some help with migrating from
> log4j1 to log4j2 please?
> >>>>>> Im trying to update gerrit to log4j2 but am stuck on some things.
> [1]
> >>>>>> 1. How do i migrate from PropertyConfigurator.
> configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2
> compatible please?
> >>>>>> Im trying to migrate all the way without trying to use log4j1
> compatible api log4j2. (Though im still pulling it in i am trying not to
> use it).
> >>>>>> I found doing something like
> >>>>>>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);
> if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source =
> ConfigurationSource.fromResource(LOG_CONFIGURATION, null);
> Configurator.initialize(null, source);    } else {      URL in = new
> URL(path);      Configurator.initialize((String) null, null,
> in.toURI());    }
> >>>>>> could work but then it wont reload the configuation without
> restarting the configuation as new (ie gets rid of everything). which
> .reconfigure() does.
> >>>>>> Im trying to reset log levels to null so that we can reload the
> configuation but reconfigure gets rid of everything thus causing problems
> if you used java to add appenders or anything else. see [2]
> >>>>>> Also how would i migrate from using removeAllAppenders to log4j2
> compatible code please?
> >>>>>> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/  <
> https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/><
> https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/ <
> https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/>>
> >>>>>> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/
> 142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
> <https://gerrit-review.googlesource.com/#/c/gerrit/+/
> 142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
> ><https://gerrit-review.googlesource.com/#/c/gerrit/+/
> 142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
> <https://gerrit-review.googlesource.com/#/c/gerrit/+/
> 142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
> >>
> >>>>>
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------------
> ---------
> >>>>> To unsubscribe, e-mail: [hidden email]
> <mailto:[hidden email]> <mailto:log4j-user-
> [hidden email] <mailto:log4j-user-
> [hidden email]>>
> >>>>> For additional commands, e-mail: [hidden email]
> <mailto:[hidden email]> <mailto:log4j-user-help@
> logging.apache.org <mailto:[hidden email]>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [hidden email]
> <mailto:[hidden email]> <mailto:log4j-user-
> [hidden email] <mailto:log4j-user-
> [hidden email]>>
> >>>> For additional commands, e-mail: [hidden email]
> <mailto:[hidden email]> <mailto:log4j-user-help@
> logging.apache.org <mailto:[hidden email]>>
>
>



--
Matt Sicker <[hidden email]>  
Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Ralph Goers
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 the configuration file?

What we are suggesting is that you keep track of the changes you are making programmatically after the original configuration was loaded. When a reconfiguration occurs you then supply a configuration created with ConfigurationBuilder that reapplies all the changes you made. Although even then you might be overriding something that was changed in the configuration file that the user really wanted.

Ralph

> On Dec 21, 2017, at 7:29 AM, Paladox <[hidden email]> wrote:
>
> 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 <[hidden email]> wrote:  
>
> 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 swap it). You can specify an implementation of MergeStrategy via the
> log4j2.mergeStrategy global property for more complex merging.
>
> On 20 December 2017 at 05:52, Paladox <[hidden email]>
> wrote:
>
>>   “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 changing
>> programmatically? Just the log levels of Loggers? Are you wanting those
>> changes re-applied after a reconfiguration?"
>> We had log level set to null so that when we reloaded the file it would
>> add back the loggers. But it wouldn't get rid of any appenders which we set
>> through java.
>>
>> We are trying to reset log levels back to what they were set in the file
>> without losing any appenders.
>>     On Tuesday, 19 December 2017, 23:35:05 GMT, Ralph Goers <
>> [hidden email]> wrote:
>>
>>   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:
>> Re-read the configuration and create a brand new Configuration.
>> Start the new Configuration (starts the new Appenders).
>> Set the LoggerContext to point to the new Configuration.
>> Update all Loggers to use the new Configuration.
>> Stop the old Configuration.
>>
>> This happens automatically if you have set monitorInterval to a non-zero
>> value on a Configuration element in a config file. You can force it to
>> happen by calling LoggerContext.reconfigure().
>>
>> If you have made any programmatic changes to the configuration they will
>> be lost during this process.  If you are “remembering the changes” you made
>> programmatically and have captured them you can just reapply them after
>> Log4j 2 reconfigures.
>>
>> Again, what is the behavior you are looking for? What are you changing
>> programmatically? Just the log levels of Loggers? Are you wanting those
>> changes re-applied after a reconfiguration?
>>
>> Ralph
>>
>>
>>
>>
>>> On Dec 19, 2017, at 2:28 PM, Paladox <[hidden email]>
>> wrote:
>>>
>>> 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 set in the
>> configuation file.
>>> In log4j2 it seems to not support a way like https://github.com/apache/
>> log4j/blob/c5f4279081091e562c44bb753f6e52dc6be5fa52/src/main/java/org/
>> apache/log4j/PropertyConfigurator.java#L120
>>>
>>> "    Read configuration from a file. <b>The existing configuration is
>> not cleared nor reset.</b> If you require a different behavior,    then
>> call {@link  LogManager#resetConfiguration    resetConfiguration} method
>> before calling    <code>doConfigure</code>."
>>> Thats one of the reasons why we had to use null as it did not reset it
>> (which we doint want anyways) we needed to remove the log level to prevent
>> it for example writing tons of info if you have it set to DEBUG. But by re
>> adding the file we got the loggers back to the default value we had them
>> set at.
>>> Now in log4j2 there dosen't seem to be anything similar except from the
>> one you pointed too but that reset everything.
>>>
>>>     On Tuesday, 19 December 2017, 21:11:26 GMT, Ralph Goers <
>> [hidden email]> wrote:
>>>
>>> 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 to add. I would
>> then use Configurator.initialize(“file1, file2”) to combine the user’s
>> configuration with yours.
>>>
>>> Ralph
>>>
>>>> On Dec 19, 2017, at 12:23 PM, Paladox <[hidden email]>
>> wrote:
>>>>
>>>> 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 without causing a null pointer.
>>>>
>>>> I see there's ConfigurationBuilder as you pointed too but we use a
>> mixture of java / using the properties files.
>>>>
>>>> So we add a appender with java but add ConsoleAppender through the
>> properties file.
>>>>
>>>> Reading this https://github.com/apache/log4j/blob/
>> c5f4279081091e562c44bb753f6e52dc6be5fa52/src/main/java/org/apache/log4j/
>> PropertyConfigurator.java#L120 seems to say that it just reads the
>> configuation but dosen't clear anything. I wonder would something like be
>> able to be added to log4j2 please?
>>>>
>>>>
>>>>
>>>> On Sunday, 17 December 2017, 23:30:02 GMT, Ralph Goers <
>> [hidden email]> wrote:
>>>>
>>>>
>>>> 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
>> and get it from there. So setting a Logger’s logging level to null
>> basically said “look at your parent”.  When an application wants to log
>> something it also obtains a Logger. So the Loggers used for logging and
>> configuration were the same. In order to reconfigure, Log4j 1 would clear
>> everything from the Loggers and then start adding configuration back to
>> them as it processed the configuration. During the time that the Loggers
>> are cleared and before configuration is added back events are ignored.
>>>>
>>>> Log4j 2 doesn’t work this way at all. When the configuration is read a
>> set of LoggerConfig objects is created. These all contain the same
>> information that is in the configuration file. When an application wants to
>> log it gets a Logger. The Logger looks for a LoggerConfig with its name or,
>> if one isn’t found, one of its ancestors. The Logger then is set with a
>> reference to the LoggerConfig that provides its configuration and it copies
>> that LoggerConfig’s logging level into it to improve performance. Thus,
>> when you want to  change a logging level you need to locate the
>> LoggerConfig for the Logger, update its logging level, and then call
>> updateLoggers to cause all Loggers to reevaluate which LoggerConfig they
>> should be using and what their current logging level is.
>>>>
>>>> There are several ways to deal with changes.
>>>> You add a listener to handle configuration changes. This would allow
>> you to reinsert changes to the configuration.
>>>> You can create your own Configuration and combine it with the user’s
>> configuration using a CompositeConfiguration. Your configuration can be
>> created with a config file or via the ConfigurationBuilder.
>>>> You can extend XMLConfiguration and/or PropertiesConfiguration and add
>> your own definitions to it.
>>>>
>>>> I am sure there are other ways this can all be done depending on what
>> you are trying to achieve. If you modify the logging level of a
>> LoggerConfig and then a reconfigure occurs Log4j will automatically handle
>> resetting the configuration. You don’t have to do anything. If you want to
>> reinsert changes to the user’s configuration then you have to use one of
>> the techniques I noted above.
>>>>
>>>> Ralph
>>>>
>>>>
>>>>
>>>>
>>>>> On Dec 17, 2017, at 3:40 PM, Paladox <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>>>>
>>>>> "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 set loggers through java
>> then reloading the file would not affect them. So i guess they wanted to
>> make sure everything goes back to the way it was.
>>>>> More explementation, because we have a ssh command that can set log
>> levels for either all or specific loggers we want to be able to remove the
>> levels to put it back to how it was done when the application was started.
>> So ie if we set debug on com.google. then that will be added to the loggers
>> as
>>>>> com.google = DEBUG
>>>>> but when the application was started that was not in the loggers so we
>> did not get any debug in the output.
>>>>> But we want to set it to the default by removing com.google as loggers
>> in com.google have different levels. IE in the log4j2.properties file we
>> have
>>>>> com.google.gerrit.sshd.GerritServerSession which is set to WARN
>>>>>
>>>>> but now because we did com.google @ debug com.google.gerrit.sshd.GerritServerSession
>> will be debug and everything else under com.google class path that uses
>> loggers.
>>>>> But users would not know every logger under com.google so they
>> wouldn't be able to put them all back to the default so we set the log
>> level to null and reloaded the file without loosing any java appenders. But
>> with log4j2 it seems to restart as new.
>>>>>     On Sunday, 17 December 2017, 22:25:28 GMT, Ralph Goers <
>> [hidden email] <mailto:[hidden email]>> wrote:
>>>>>
>>>>> 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 use their own configuration but not why you want to add appenders
>> and “other things” or what requirement you are trying to solve with them.
>> What I need here is some sort of “user story definition” like - “As a user
>> of Gerrit I need to be able to provide my own logging configuration while
>> Gerrit makes sure that error conditions are always logged even if my
>> configuration doesn’t specify it” or something like that. We can tell you
>> how to implement something once we understand what you are really trying to
>> achieve. You probably have done this before, but in case you haven’t done
>> that before you can look at https://www.mountaingoatsoftware.com/
>> agile/user-stories  <https://www.mountaingoatsoftware.com/
>> agile/user-stories><https://www.mountaingoatsoftware.com/
>> agile/user-stories <https://www.mountaingoatsoftware.com/
>> agile/user-stories>>. Also, you might have a definition of what you want
>> the experience for a user of Gerrit to be vs that of a developer. If so,
>> tell me what they both are.
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Dec 17, 2017, at 1:58 PM, Paladox <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>>
>>>>>> 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 other
>> things because we want users to customise the behavour through a config.
>> For example some users want log4j to log with json instead of the pattern
>> layout. Though if users want to modify it more then a config they use the
>> system property to override the default log4j configuation file and use
>> there own.
>>>>>>
>>>>>> On Sunday, 17 December 2017, 20:44:09 GMT, Ralph Goers <
>> [hidden email] <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>>
>>>>>> "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 property file” - what property file? The log4j 2
>> configuration file?  Why would you set the log sell to null before reloaded
>> the configuration?
>>>>>>
>>>>>> “Without losing any appenders created with Java” - How are the
>> appenders created with Java and why are they created with Java? You could
>> use a composite configuration that adds your the “standard” configuration
>> to what a user provides or you could extend XMLConfiguratoin with your own
>> extra configuration.
>>>>>>
>>>>>> In short, you still haven’t described what you want the resultant
>> behavior to be. You are still describing “How?” instead of “What?”.  In
>> other words - something like - “We want to require that a specific logger
>> is always logged at error and those logs are always routed to a file named
>> xxxx, regardless of what other things the user might configure”.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On Dec 17, 2017, at 11:22 AM, Paladox <[hidden email]
>> <mailto:[hidden email]> <mailto:thomasmulhall410@
>> yahoo.com.INVALID <mailto:[hidden email]>>> wrote:
>>>>>>>
>>>>>>> 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 GMT, Ralph Goers <
>> [hidden email] <mailto:[hidden email]> <mailto:
>> [hidden email] <mailto:[hidden email]>>> wrote:
>>>>>>>
>>>>>>> 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 <[hidden email]
>> <mailto:[hidden email]> <mailto:thomasmulhall410@
>> yahoo.com.INVALID <mailto:[hidden email]>>> 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
>> (Enumeration<Logger> logger = LogManager.getCurrentLoggers();
>> logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);
>>   }
>>>>>>>>     String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);
>> if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.
>> configure(Loader.getResource(LOG_CONFIGURATION));    } else {
>> PropertyConfigurator.configure(new URL(path));    }  }
>>>>>>>> in log4j2 i carn't find any good replacements. Setting setLevel
>> results in null pointer same would be for setAllLevels. (Works in log4j1).
>>>>>>>> Then when i try to reload the properties file it just resets
>> everything then loads the file. Thus if you used some java code it would be
>> lost and you would have to restart your java application to get the
>> appenders or anything added with java code.
>>>>>>>> In log4j1 you need PropertyConfigurator.configure which re added
>> the log levels that were from the file without resetting anything.
>>>>>>>>   On Friday, 15 December 2017, 16:50:28 GMT, Paladox <
>> [hidden email] <mailto:thomasmulhall410@
>> yahoo.com.INVALID> <mailto:[hidden email] <mailto:
>> [hidden email]>>> wrote:
>>>>>>>>
>>>>>>>> Hi, im wondering if i could have some help with migrating from
>> log4j1 to log4j2 please?
>>>>>>>> Im trying to update gerrit to log4j2 but am stuck on some things.
>> [1]
>>>>>>>> 1. How do i migrate from PropertyConfigurator.
>> configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2
>> compatible please?
>>>>>>>> Im trying to migrate all the way without trying to use log4j1
>> compatible api log4j2. (Though im still pulling it in i am trying not to
>> use it).
>>>>>>>> I found doing something like
>>>>>>>>     String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);
>> if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source =
>> ConfigurationSource.fromResource(LOG_CONFIGURATION, null);
>> Configurator.initialize(null, source);    } else {      URL in = new
>> URL(path);      Configurator.initialize((String) null, null,
>> in.toURI());    }
>>>>>>>> could work but then it wont reload the configuation without
>> restarting the configuation as new (ie gets rid of everything). which
>> .reconfigure() does.
>>>>>>>> Im trying to reset log levels to null so that we can reload the
>> configuation but reconfigure gets rid of everything thus causing problems
>> if you used java to add appenders or anything else. see [2]
>>>>>>>> Also how would i migrate from using removeAllAppenders to log4j2
>> compatible code please?
>>>>>>>> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/  <
>> https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/><
>> https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/ <
>> https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/>>
>>>>>>>> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/
>> 142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
>> <https://gerrit-review.googlesource.com/#/c/gerrit/+/
>> 142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
>>> <https://gerrit-review.googlesource.com/#/c/gerrit/+/
>> 142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
>> <https://gerrit-review.googlesource.com/#/c/gerrit/+/
>> 142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>> ---------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>> <mailto:[hidden email]> <mailto:log4j-user-
>> [hidden email] <mailto:log4j-user-
>> [hidden email]>>
>>>>>>> For additional commands, e-mail: [hidden email]
>> <mailto:[hidden email]> <mailto:log4j-user-help@
>> logging.apache.org <mailto:[hidden email]>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>> <mailto:[hidden email]> <mailto:log4j-user-
>> [hidden email] <mailto:log4j-user-
>> [hidden email]>>
>>>>>> For additional commands, e-mail: [hidden email]
>> <mailto:[hidden email]> <mailto:log4j-user-help@
>> logging.apache.org <mailto:[hidden email]>>
>>
>>
>
>
>
> --
> Matt Sicker <[hidden email]>  



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Migrating from log4j1 to log4j2

Paladox
 I think i found a way to do this. Without reloading a file or using any reconfigure methods.
I can use for example
    ConfigurationBuilder<BuiltConfiguration> builder = ConfigurationBuilderFactory.newConfigurationBuilder();    builder.add(builder.newLogger("org.apache.mina", Level.WARN));    builder.build();
But one problem i am having is when i set the log level to null, it seems to remove something like

$ ssh -p 29418 admin@localhost gerrit logging ls-level

: INFO

I presume ": INFO" is the root logger?
Im wondering how do i get the loggers but doint change anything to do with root logger?
And how do i remove loggers so i can re add them with the builder please?
    On Thursday, 21 December 2017, 15:10:35 GMT, Ralph Goers <[hidden email]> wrote:  
 
 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 the configuration file?

What we are suggesting is that you keep track of the changes you are making programmatically after the original configuration was loaded. When a reconfiguration occurs you then supply a configuration created with ConfigurationBuilder that reapplies all the changes you made. Although even then you might be overriding something that was changed in the configuration file that the user really wanted.

Ralph

> On Dec 21, 2017, at 7:29 AM, Paladox <[hidden email]> wrote:
>
> 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 <[hidden email]> wrote: 
>
> 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 swap it). You can specify an implementation of MergeStrategy via the
> log4j2.mergeStrategy global property for more complex merging.
>
> On 20 December 2017 at 05:52, Paladox <[hidden email]>
> wrote:
>
>>  “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 changing
>> programmatically? Just the log levels of Loggers? Are you wanting those
>> changes re-applied after a reconfiguration?"
>> We had log level set to null so that when we reloaded the file it would
>> add back the loggers. But it wouldn't get rid of any appenders which we set
>> through java.
>>
>> We are trying to reset log levels back to what they were set in the file
>> without losing any appenders.
>>    On Tuesday, 19 December 2017, 23:35:05 GMT, Ralph Goers <
>> [hidden email]> wrote:
>>
>>  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:
>> Re-read the configuration and create a brand new Configuration.
>> Start the new Configuration (starts the new Appenders).
>> Set the LoggerContext to point to the new Configuration.
>> Update all Loggers to use the new Configuration.
>> Stop the old Configuration.
>>
>> This happens automatically if you have set monitorInterval to a non-zero
>> value on a Configuration element in a config file. You can force it to
>> happen by calling LoggerContext.reconfigure().
>>
>> If you have made any programmatic changes to the configuration they will
>> be lost during this process.  If you are “remembering the changes” you made
>> programmatically and have captured them you can just reapply them after
>> Log4j 2 reconfigures.
>>
>> Again, what is the behavior you are looking for? What are you changing
>> programmatically? Just the log levels of Loggers? Are you wanting those
>> changes re-applied after a reconfiguration?
>>
>> Ralph
>>
>>
>>
>>
>>> On Dec 19, 2017, at 2:28 PM, Paladox <[hidden email]>
>> wrote:
>>>
>>> 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 set in the
>> configuation file.
>>> In log4j2 it seems to not support a way like https://github.com/apache/
>> log4j/blob/c5f4279081091e562c44bb753f6e52dc6be5fa52/src/main/java/org/
>> apache/log4j/PropertyConfigurator.java#L120
>>>
>>> "    Read configuration from a file. <b>The existing configuration is
>> not cleared nor reset.</b> If you require a different behavior,    then
>> call {@link  LogManager#resetConfiguration    resetConfiguration} method
>> before calling    <code>doConfigure</code>."
>>> Thats one of the reasons why we had to use null as it did not reset it
>> (which we doint want anyways) we needed to remove the log level to prevent
>> it for example writing tons of info if you have it set to DEBUG. But by re
>> adding the file we got the loggers back to the default value we had them
>> set at.
>>> Now in log4j2 there dosen't seem to be anything similar except from the
>> one you pointed too but that reset everything.
>>>
>>>    On Tuesday, 19 December 2017, 21:11:26 GMT, Ralph Goers <
>> [hidden email]> wrote:
>>>
>>> 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 to add. I would
>> then use Configurator.initialize(“file1, file2”) to combine the user’s
>> configuration with yours.
>>>
>>> Ralph
>>>
>>>> On Dec 19, 2017, at 12:23 PM, Paladox <[hidden email]>
>> wrote:
>>>>
>>>> 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 without causing a null pointer.
>>>>
>>>> I see there's ConfigurationBuilder as you pointed too but we use a
>> mixture of java / using the properties files.
>>>>
>>>> So we add a appender with java but add ConsoleAppender through the
>> properties file.
>>>>
>>>> Reading this https://github.com/apache/log4j/blob/
>> c5f4279081091e562c44bb753f6e52dc6be5fa52/src/main/java/org/apache/log4j/
>> PropertyConfigurator.java#L120 seems to say that it just reads the
>> configuation but dosen't clear anything. I wonder would something like be
>> able to be added to log4j2 please?
>>>>
>>>>
>>>>
>>>> On Sunday, 17 December 2017, 23:30:02 GMT, Ralph Goers <
>> [hidden email]> wrote:
>>>>
>>>>
>>>> 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
>> and get it from there. So setting a Logger’s logging level to null
>> basically said “look at your parent”.  When an application wants to log
>> something it also obtains a Logger. So the Loggers used for logging and
>> configuration were the same. In order to reconfigure, Log4j 1 would clear
>> everything from the Loggers and then start adding configuration back to
>> them as it processed the configuration. During the time that the Loggers
>> are cleared and before configuration is added back events are ignored.
>>>>
>>>> Log4j 2 doesn’t work this way at all. When the configuration is read a
>> set of LoggerConfig objects is created. These all contain the same
>> information that is in the configuration file. When an application wants to
>> log it gets a Logger. The Logger looks for a LoggerConfig with its name or,
>> if one isn’t found, one of its ancestors. The Logger then is set with a
>> reference to the LoggerConfig that provides its configuration and it copies
>> that LoggerConfig’s logging level into it to improve performance. Thus,
>> when you want to  change a logging level you need to locate the
>> LoggerConfig for the Logger, update its logging level, and then call
>> updateLoggers to cause all Loggers to reevaluate which LoggerConfig they
>> should be using and what their current logging level is.
>>>>
>>>> There are several ways to deal with changes.
>>>> You add a listener to handle configuration changes. This would allow
>> you to reinsert changes to the configuration.
>>>> You can create your own Configuration and combine it with the user’s
>> configuration using a CompositeConfiguration. Your configuration can be
>> created with a config file or via the ConfigurationBuilder.
>>>> You can extend XMLConfiguration and/or PropertiesConfiguration and add
>> your own definitions to it.
>>>>
>>>> I am sure there are other ways this can all be done depending on what
>> you are trying to achieve. If you modify the logging level of a
>> LoggerConfig and then a reconfigure occurs Log4j will automatically handle
>> resetting the configuration. You don’t have to do anything. If you want to
>> reinsert changes to the user’s configuration then you have to use one of
>> the techniques I noted above.
>>>>
>>>> Ralph
>>>>
>>>>
>>>>
>>>>
>>>>> On Dec 17, 2017, at 3:40 PM, Paladox <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>>>>
>>>>> "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 set loggers through java
>> then reloading the file would not affect them. So i guess they wanted to
>> make sure everything goes back to the way it was.
>>>>> More explementation, because we have a ssh command that can set log
>> levels for either all or specific loggers we want to be able to remove the
>> levels to put it back to how it was done when the application was started.
>> So ie if we set debug on com.google. then that will be added to the loggers
>> as
>>>>> com.google = DEBUG
>>>>> but when the application was started that was not in the loggers so we
>> did not get any debug in the output.
>>>>> But we want to set it to the default by removing com.google as loggers
>> in com.google have different levels. IE in the log4j2.properties file we
>> have
>>>>> com.google.gerrit.sshd.GerritServerSession which is set to WARN
>>>>>
>>>>> but now because we did com.google @ debug com.google.gerrit.sshd.GerritServerSession
>> will be debug and everything else under com.google class path that uses
>> loggers.
>>>>> But users would not know every logger under com.google so they
>> wouldn't be able to put them all back to the default so we set the log
>> level to null and reloaded the file without loosing any java appenders. But
>> with log4j2 it seems to restart as new.
>>>>>    On Sunday, 17 December 2017, 22:25:28 GMT, Ralph Goers <
>> [hidden email] <mailto:[hidden email]>> wrote:
>>>>>
>>>>> 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 use their own configuration but not why you want to add appenders
>> and “other things” or what requirement you are trying to solve with them.
>> What I need here is some sort of “user story definition” like - “As a user
>> of Gerrit I need to be able to provide my own logging configuration while
>> Gerrit makes sure that error conditions are always logged even if my
>> configuration doesn’t specify it” or something like that. We can tell you
>> how to implement something once we understand what you are really trying to
>> achieve. You probably have done this before, but in case you haven’t done
>> that before you can look at https://www.mountaingoatsoftware.com/
>> agile/user-stories  <https://www.mountaingoatsoftware.com/
>> agile/user-stories><https://www.mountaingoatsoftware.com/
>> agile/user-stories <https://www.mountaingoatsoftware.com/
>> agile/user-stories>>. Also, you might have a definition of what you want
>> the experience for a user of Gerrit to be vs that of a developer. If so,
>> tell me what they both are.
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Dec 17, 2017, at 1:58 PM, Paladox <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>>
>>>>>> 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 other
>> things because we want users to customise the behavour through a config.
>> For example some users want log4j to log with json instead of the pattern
>> layout. Though if users want to modify it more then a config they use the
>> system property to override the default log4j configuation file and use
>> there own.
>>>>>>
>>>>>> On Sunday, 17 December 2017, 20:44:09 GMT, Ralph Goers <
>> [hidden email] <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>>
>>>>>> "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 property file” - what property file? The log4j 2
>> configuration file?  Why would you set the log sell to null before reloaded
>> the configuration?
>>>>>>
>>>>>> “Without losing any appenders created with Java” - How are the
>> appenders created with Java and why are they created with Java? You could
>> use a composite configuration that adds your the “standard” configuration
>> to what a user provides or you could extend XMLConfiguratoin with your own
>> extra configuration.
>>>>>>
>>>>>> In short, you still haven’t described what you want the resultant
>> behavior to be. You are still describing “How?” instead of “What?”.  In
>> other words - something like - “We want to require that a specific logger
>> is always logged at error and those logs are always routed to a file named
>> xxxx, regardless of what other things the user might configure”.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On Dec 17, 2017, at 11:22 AM, Paladox <[hidden email]
>> <mailto:[hidden email]> <mailto:thomasmulhall410@
>> yahoo.com.INVALID <mailto:[hidden email]>>> wrote:
>>>>>>>
>>>>>>> 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 GMT, Ralph Goers <
>> [hidden email] <mailto:[hidden email]> <mailto:
>> [hidden email] <mailto:[hidden email]>>> wrote:
>>>>>>>
>>>>>>> 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 <[hidden email]
>> <mailto:[hidden email]> <mailto:thomasmulhall410@
>> yahoo.com.INVALID <mailto:[hidden email]>>> 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
>> (Enumeration<Logger> logger = LogManager.getCurrentLoggers();
>> logger.hasMoreElements(); ) {      logger.nextElement().setLevel(null);
>>  }
>>>>>>>>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);
>> if (Strings.isNullOrEmpty(path)) {      PropertyConfigurator.
>> configure(Loader.getResource(LOG_CONFIGURATION));    } else {
>> PropertyConfigurator.configure(new URL(path));    }  }
>>>>>>>> in log4j2 i carn't find any good replacements. Setting setLevel
>> results in null pointer same would be for setAllLevels. (Works in log4j1).
>>>>>>>> Then when i try to reload the properties file it just resets
>> everything then loads the file. Thus if you used some java code it would be
>> lost and you would have to restart your java application to get the
>> appenders or anything added with java code.
>>>>>>>> In log4j1 you need PropertyConfigurator.configure which re added
>> the log levels that were from the file without resetting anything.
>>>>>>>>  On Friday, 15 December 2017, 16:50:28 GMT, Paladox <
>> [hidden email] <mailto:thomasmulhall410@
>> yahoo.com.INVALID> <mailto:[hidden email] <mailto:
>> [hidden email]>>> wrote:
>>>>>>>>
>>>>>>>> Hi, im wondering if i could have some help with migrating from
>> log4j1 to log4j2 please?
>>>>>>>> Im trying to update gerrit to log4j2 but am stuck on some things.
>> [1]
>>>>>>>> 1. How do i migrate from PropertyConfigurator.
>> configure(Loader.getResource(LOG_CONFIGURATION)); to something log4j2
>> compatible please?
>>>>>>>> Im trying to migrate all the way without trying to use log4j1
>> compatible api log4j2. (Though im still pulling it in i am trying not to
>> use it).
>>>>>>>> I found doing something like
>>>>>>>>    String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);
>> if (Strings.isNullOrEmpty(path)) {      ConfigurationSource source =
>> ConfigurationSource.fromResource(LOG_CONFIGURATION, null);
>> Configurator.initialize(null, source);    } else {      URL in = new
>> URL(path);      Configurator.initialize((String) null, null,
>> in.toURI());    }
>>>>>>>> could work but then it wont reload the configuation without
>> restarting the configuation as new (ie gets rid of everything). which
>> .reconfigure() does.
>>>>>>>> Im trying to reset log levels to null so that we can reload the
>> configuation but reconfigure gets rid of everything thus causing problems
>> if you used java to add appenders or anything else. see [2]
>>>>>>>> Also how would i migrate from using removeAllAppenders to log4j2
>> compatible code please?
>>>>>>>> [1] https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/  <
>> https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/><
>> https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/ <
>> https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/>>
>>>>>>>> [2] https://gerrit-review.googlesource.com/#/c/gerrit/+/
>> 142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
>> <https://gerrit-review.googlesource.com/#/c/gerrit/+/
>> 142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
>>> <https://gerrit-review.googlesource.com/#/c/gerrit/+/
>> 142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
>> <https://gerrit-review.googlesource.com/#/c/gerrit/+/
>> 142811/46/java/com/google/gerrit/sshd/commands/SetLoggingLevelCommand.java
>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>> ---------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>> <mailto:[hidden email]> <mailto:log4j-user-
>> [hidden email] <mailto:log4j-user-
>> [hidden email]>>
>>>>>>> For additional commands, e-mail: [hidden email]
>> <mailto:[hidden email]> <mailto:log4j-user-help@
>> logging.apache.org <mailto:[hidden email]>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>> <mailto:[hidden email]> <mailto:log4j-user-
>> [hidden email] <mailto:log4j-user-
>> [hidden email]>>
>>>>>> For additional commands, e-mail: [hidden email]
>> <mailto:[hidden email]> <mailto:log4j-user-help@
>> logging.apache.org <mailto:[hidden email]>>
>>
>>
>
>
>
> --
> Matt Sicker <[hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]