DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=43010>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43010 Summary: in setFile() if FileAppender can't open the file, then the fileName parameter is reset Product: Log4j Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Appender AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] FileAppender.setFile() calls reset() to close existing file, which also clobbers the fileName parameter. Its ok - because setFile() have received it as an argument, and it sets this.fileName back when it exists cleanly. The problem is that if setFile() fails to open the file then it throws an exception - w/o setting the fileName back, so that if someone then tries to look at the appender and understand what the problem is, then getFile() returns null. In my use case, I have a framework which allows its users to define arbitrary log4j configurations, and after the configuration is setup (in a specific stage of the framework initialization) the framework examines the log4j setup and "fixes" relative file paths to an absolute path where the user is allowed to create files (a directory which is installation dependent). Currently this works only if the application can start by opening a file in a certain location and then after the framework fiddles with the file name, it will be closed and reopened (which is of course not optimal). Regardless to the above use case, I think it would be a good idea not to lose the fileName even if an exception occurs during activateOptions() - and I will attach a patch with a simple fix in a minute. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
