logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 43010] New: - in setFile() if FileAppender can't open the file, then the fileName parameter is reset
Date Wed, 01 Aug 2007 16:24:54 GMT
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: log4j-dev@logging.apache.org
        ReportedBy: oded@taboola.com


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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message