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 <thomasmulhall...@yahoo.com> 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 > <ralph.go...@dslextreme.com> 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 <thomasmulhall...@yahoo.com.INVALID > > <mailto:thomasmulhall...@yahoo.com.INVALID>> 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 > > <ralph.go...@dslextreme.com <mailto:ralph.go...@dslextreme.com>> 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 <thomasmulhall...@yahoo.com > >> <mailto:thomasmulhall...@yahoo.com>> 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 > >> <ralph.go...@dslextreme.com <mailto:ralph.go...@dslextreme.com>> 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 <thomasmulhall...@yahoo.com.INVALID > >>> <mailto:thomasmulhall...@yahoo.com.INVALID> > >>> <mailto:thomasmulhall...@yahoo.com.INVALID > >>> <mailto:thomasmulhall...@yahoo.com.INVALID>>> 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 > >>> <ralph.go...@dslextreme.com <mailto:ralph.go...@dslextreme.com> > >>> <mailto:ralph.go...@dslextreme.com <mailto:ralph.go...@dslextreme.com>>> > >>> 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 <thomasmulhall...@yahoo.com.INVALID > >>>> <mailto:thomasmulhall...@yahoo.com.INVALID> > >>>> <mailto:thomasmulhall...@yahoo.com.INVALID > >>>> <mailto:thomasmulhall...@yahoo.com.INVALID>>> 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 > >>>> <thomasmulhall...@yahoo.com.INVALID > >>>> <mailto:thomasmulhall...@yahoo.com.INVALID> > >>>> <mailto:thomasmulhall...@yahoo.com.INVALID > >>>> <mailto:thomasmulhall...@yahoo.com.INVALID>>> 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: log4j-user-unsubscr...@logging.apache.org > >>> <mailto:log4j-user-unsubscr...@logging.apache.org> > >>> <mailto:log4j-user-unsubscr...@logging.apache.org > >>> <mailto:log4j-user-unsubscr...@logging.apache.org>> > >>> For additional commands, e-mail: log4j-user-h...@logging.apache.org > >>> <mailto:log4j-user-h...@logging.apache.org> > >>> <mailto:log4j-user-h...@logging.apache.org > >>> <mailto:log4j-user-h...@logging.apache.org>> > >> > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > >> <mailto:log4j-user-unsubscr...@logging.apache.org> > >> <mailto:log4j-user-unsubscr...@logging.apache.org > >> <mailto:log4j-user-unsubscr...@logging.apache.org>> > >> For additional commands, e-mail: log4j-user-h...@logging.apache.org > >> <mailto:log4j-user-h...@logging.apache.org> > >> <mailto:log4j-user-h...@logging.apache.org > >> <mailto:log4j-user-h...@logging.apache.org>>
