logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Relative path names in FileAppenders
Date Thu, 03 Mar 2005 22:37:16 GMT
I had a report on log4cxx-user  
(http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4cxx- 
user@logging.apache.org&msgNo=784) from a user who was using  
RollingFileAppender in an application where the user was able to change  
the current working directory during the applications lifetime.  He  
observed that when a rollover occurred the new log file was located in  
the current working directory at the time of the rollover, so you could  
end up with log files scattered all over the place.

The previous log4cxx RollingFileAppender has already been removed from  
the CVS and I am planning to migrate the current CVS o.a.l.rolling  
package to log4cxx.  From reading the code, it appears that  
o.a.l.rolling would suffer from the same problem since it appears to  
always resolve filenames relative to the current working directory at  
the time of the evaluation.

I think, at least, the current working directory at the time of the  
call to activate/activateOptions should be used for subsequent  
evaluations of relative paths.  However, even that is not ideal since  
the expectation in XML is that relative paths are resolved relative to  
the document's location not the current working directory.  If the base  
for relative paths is changed, you could still specify a log file in  
the current working directory (at configuration evaluation) by  
specifying a path like "${user.dir}/cwd.log".

The options I see are:

1. Ignore the issue
2. Resolve RFA paths against current working directory (CWD) at time of  
call to activate/activateOptions
3. Resolve all relative paths against configuration file location (CWD  
for API calls or for locationless (memory stream, socket) config  
documents)
4. Resolve relative paths in new-namespace XML files against config  
location, resolve relative paths in old-namespace XML and property  
files against CWD at config time.
5. Provide an config file option to control base for resolution of  
relative paths.  This could possibly exploit the XML Base  
recommendation (http://www.w3.org/TR/2001/REC-xmlbase-20010627/).

The last three options would require some hacking of the  
configurator/component interaction to provide the appropriate base  
filespec.  It appears that the setter methods for path related  
properties are defined as String, not File, so there is not an obvious  
hint to the configuator to apply path resolution.  It might be best to  
introduce a new interface (o.a.l.spi.FileResolver?) that the  
configurator could use to inform a component of the current base for  
relative paths.  Components that don't care would not have to implement  
the interface.

My current preference is probably options 5 using a base attribute on  
the configuration and appender elements.  So you could have something  
like:


<!--  all paths are relative to the user's home directory unless  
overriden   -->
<configuration xmlns="http://logging.apache.org" base="${user.home}">
</configuation>


<!--  all paths are relative to the configuration file   -->
<configuration xmlns="http://logging.apache.org">
</configuation>

<!--  all paths are relative to the current working directory   -->
<configuration xmlns="http://logging.apache.org" base="${user.dir}">
</configuation>


Old namespace XML documents and property files could be defaulted to  
using the current working directory if desired for compatibility.

Any thoughts or comments?


---------------------------------------------------------------------
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