> Howdy, > > >1) log4j 1.2.8 PropertyConfigurator & DOMConfigurator both have a small > bug > >in the void doConfigure(URL url, LoggerRepository repository) methods. > >They open a stream on the URL, but do not close it. This means the > file > >cannot be edited while the application is running because log4j has it > >locked. This is easy to fix by closing the stream when log4j has > finished > >reading it. > > Does this break configureAndWatch?
No, configureAndWatch only uses Strings which points to a file name. Thus it never uses the doConfigure that uses a URL. The code change I made simply closes the input stream from the URL exactly like the string version of doConfigure does. Infact, this fix is necessary to be able to edit the "default" initialization file that log4j uses, so a configureAndWatch could potentially be added to LogManager now to configure from the "default" initialization file, and then watch it for changes. > > >2) Added a new method to LogManager called refreshConfiguration(). > This > >method will call a newly modified Hierarchy.resetConfiguration. The > old > >signature was resetConfiguration() and the new one is > >resetConfiguration(boolean warnNoEmit). If the parameter is true, > log4j > >will emit a "Please initialize the log4j system properly." message if > any > >thread attempts to log before the configuration is reloaded. If false, > the > >message will never be output. The LogManager.refreshConfiguration() > will > >then re-load the configuration file that was used when the app first > >started. > > This seems like too big a change for a point release (e.g. 1.2.9), but > maybe we should consider it for 1.3. Comments? > > Yoav Shapira This is really a small change in that there isn't very many lines of code changed. Also with the exception of the signature change for the Heirarchy.resetConfiguration method no other method signatures were changed, and their functionality was in no way changed. Only this new method / capability was added. If backwards compatibility of the Heirarchy.resetConfiguration method signature is needed / desired a method with the original signature could be added, and then call the newly modified one with a value of true. This would then provide complete backwards compatibility with no changes to existing signatures while also providing new functionality. Their would only be one additional method in the LoggerRepository interface, but I doubt many people are implementing or extending that interface outside of log4j itself. Later Rob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
