Hi Paul, > Hi Rob, > > Does the LogManager.resetConfiguration method not satisfy your > requirements?
I was unaware of this function, but after looking at it I don't think it will meet my needs. But maybe it will after a few things are clarified. LogManager.resetConfiguration only calls repositorySelector.getLoggerRepository().resetConfiguration(); repositorySelector.getLoggerRepository() returns a LoggerRepository, and according the the Log4j javadocs there is only one class that implements that interface. That class is org.apache.log4j.Hierarchy. The javadoc for resetConfiguration() says: ** begin javadoc quote ** Reset all values contained in this hierarchy instance to their default. This removes all appenders from all categories, sets the level of all non-root categories to null, sets their additivity flag to true and sets the level of the root logger to DEBUG. Moreover, message disabling is set its default "off" value. Existing categories are not removed. They are just reset. This method should be used sparingly and with care as it will block all logging until it is completed. ** end javadoc quote ** I have two concerns/problems with this. 1) It blocks all logging which effectively will block all threads in the (web) application while this is done. Hopefully this executes quickly so the negative effects are minimized. (Any idea how quick?) Does reloading a config file also block all logging? The book says it's threadsafe, but doesn't indicate if it blocks or not. 2) After calling this method log4j is effectively "not configured". i.e. it is in the same state it is in when you start log4j, but have not yet configured it. Log4j usually complains at this point about not being configured. This is not good. Or is log4j in a different state where it will not complain about not being configured? 3) Log messages may be lost in the time between the reset call, and the next call to load a configuration. While not critical in most situations, it would be good to avoid this. Both #2 & #3 above of course assume that log4j either does not re-do it's "automatic" initialization search after it is reset, or does and fails because the configuration is actually in another location which the search does not look for. Will log4j re-do it's initialization search after it is reset? If log4j does re-do it's initialization search, and succeeds because everything is as it should be, will any log messages be lost? i.e log4j blocks to do the reset, remains blocked while re-initializing, and then writes out the log data, or does it block to reset, unblock and while the app attempts to log the log4j framework simultaneously re-initializes, but some log messages are lost. Thanks for your help. Later Rob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
