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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
