Replying to myself :)
I built a very simple test program to see how things would work. Here it is:
public class TestLog4jReset {
private static Logger myLogger = Logger.getLogger(TestLog4jReset.class);
public static void main(String[] args) {
myLogger.debug("Before reset");
LogManager.resetConfiguration();
myLogger.debug("After reset");
PropertyConfigurator.configure("config/log4j.properties");
myLogger.debug("After reconfig");
}
}
The output from it is this:
0 [main] DEBUG TestLog4jReset - Before reset
log4j:WARN No appenders could be found for logger (TestLog4jReset).
log4j:WARN Please initialize the log4j system properly.
10 [main] DEBUG TestLog4jReset - After reconfig
Log4j is configured by it's automatic initialization procedure by searching on it's
classpath for log4j.properties. The classpath includes the config folder, and that is
where it finds the file.
As you can see, calling resetConfiguration() sets log4j back to it's initial setup of
not being configured at all, but does not automatically attempt to reload it's
configuration. Instead it complains about not being configured.
The log message between reset & configure is lost. After calling configure log4j
properly logs messages again. Perhaps a new method could be added to log4j that will
reset & re-initialize in one step.. preferably not losing any messages. I'll look
into it more.
Later
Rob
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
