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 Curt Arnold <ca...@apache.org> on 2005/03/03 23:37:16 UTC
Relative path names in FileAppenders
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
Re: Relative path names in FileAppenders
Posted by Jacob Kjome <ho...@visi.com>.
It seems to me that paths always ought to be specified absolutely,
otherwise one should expect the unexpected. If you want to work on this,
that's fine. I have no opinion. As long as it doesn't break current
behavior and it helps you out, go for it.
Jake
At 04:37 PM 3/3/2005 -0600, you wrote:
>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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org