You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by bu...@apache.org on 2007/08/01 18:24:54 UTC
DO NOT REPLY [Bug 43010] New: - in setFile() if FileAppender can't open the file, then the fileName parameter is reset
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
DO NOT REPLY [Bug 43010] - in setFile() if FileAppender can't open the file, then the fileName parameter is reset
Posted by bu...@apache.org.
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
carnold@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
------- Additional Comments From carnold@apache.org 2007-08-22 20:24 -------
Seems a bit too risky to change at this point in log4j 1.2.
--
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
DO NOT REPLY [Bug 43010] - in setFile() if FileAppender can't open the file, then the fileName parameter is reset
Posted by bu...@apache.org.
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
------- Additional Comments From carnold@apache.org 2007-09-05 20:20 -------
As such a frequently extended class in the framework, any change in behavior has a potential to have
unexpected consequences.
log4j 1.3 has been abandoned. The next maintenance release will be 1.2.16, the next major release is
2.0, there is no anticipated minor release.
There was an effort to create a MultiFileAppender which could handle multiple open files for use cases
such as different file for each thread, etc, but also could be more robust for rolling files, etc since it did
not need to close the existing file before attempting to create the new file. It may be that your use case
would fit that model better. MFA is still in the sandbox and has been dormant for a while, but it really
should be revisited and likely integrated into the extras companion.
--
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
DO NOT REPLY [Bug 43010] - in setFile() if FileAppender can't open the file, then the fileName parameter is reset
Posted by bu...@apache.org.
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
------- Additional Comments From oded@taboola.com 2007-08-01 09:26 -------
Created an attachment (id=20580)
--> (http://issues.apache.org/bugzilla/attachment.cgi?id=20580&action=view)
Patch to attempt to solve the above problem
This patch tries to solve the problem described above by simply moving the
setting of this.fileName to immediately after calling reset() so that at all
times fileName is set to a valid value.
--
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
DO NOT REPLY [Bug 43010] - in setFile() if FileAppender can't open the file, then the fileName parameter is reset
Posted by bu...@apache.org.
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
------- Additional Comments From oded@taboola.com 2007-08-28 12:08 -------
Why too risky ? Do you think there are some applications that depend on this
behavior ?
Do you think that the current behavior of FileAppender is correct or not correct
? If its the latter, will this behavior change in the next minor release (1.3?)
--
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