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