I've reviewed the log4j code. It doesn't do anything to prevent the rolling file moving as the current working directory was changed, but I was unable to make a problem occur by changing the current working directory using System.setProperty("user.dir"). It may be that doesn't change the processes current working directory or that relative paths are always resolved based on the working dir at the time of VM start. I've made a comment in the bug report for the RollingFileAppender (http://issues.apache.org/jira/browse/LOGCXX-52) migration to address the issue.

I've raised the issue on the log4j mailing list. It will take some time to figure out how to approach the problem so that compatibility with existing configuration files is maintained, but relative to the configuration file paths can be supported.


On Mar 9, 2005, at 1:30 PM, aBESUS wrote:

Hello Curt,

CA> The log4cxx 0.9.7 DailyRollingFileAppender has been removed and will be
CA> replaced with a port of the log4j 1.3
CA> org.apache.log4j.rolling.RollingFileAppender. Do you know if log4j
CA> exhibits the same behavior (if not, I'll check)?


No, i don't know enything about log4j 1.3
org.apache.log4j.rolling.RollingFileAppender behaviour.

CA> In a perfect world, the path would be relative to the configuration
CA> file, not the current working directory. However, I'm know that log4j
CA> doesn't do that.


And that would be beautiful :)

Thanks for your answer,

Seba


---------------------------------------------------------------------- Najlepsze MOTO w sieci! >>> http://link.interia.pl/f1862




Reply via email to