Each instance of FileAppender or a derived class expects to have
exclusive access to its log file, however there is no way to assert
this in a portable manner, so it is up to the user not to configure
log4j in such a manner that two appenders write to the same file.
This is true whether they are two distinct FileAppenders in one
configuration file or duplicate FileAppenders caused by loading the
same configuration into different instances of log4j. It does appear
to "work" in many cases, but there is no way to make it reliable.
With RollingFileAppender and the like it becomes even more problematic
since not only do you have another appender writing to the same file,
you have the possibility that another file may attempt to rename the
file to which you are writing. Prior to log4j 1.2.15, there was no
check for rename failure which could have the result of losing
previously logged messages. In log4j 1.2.15, code was added that
reduces the damage when this occurs, but in no way should that be an
encouragement for that type of configuration.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
