RE: create directories as well as files on first write with FileAppender

[Ceki Gülcü <ce...@qos.ch>]

Matt,


Matt,

Sorry for not responding earlier.

This functionality has been requested in the past. However, I think
intermediate directory creation should be optional and set to false by
default. Regards, Ceki

At 14:10 15.01.2002 -0500, you wrote:
>Hi again,
>
>  Could someone please respond to my prior email (included below)?  Due to
>the lack of response, I'm not sure what to do next.  I could make the
>changes and submit them by email, but if this functionality is not desired
>by the project, I'd rather not waste my time doing so ;)
>
>  - Matt
>
>-----Original Message-----
>From: Matt Munz [mailto:mmunz@apelon.com]
>Sent: Tuesday, January 08, 2002 9:02 AM
>To: Log4j Developers
>Subject: create directories as well as files on first write with
>FileAppender
>
>
>Hi all,
>
>  I'd like to bring the following thread to your attention.
>
>http://www.mail-archive.com/log4j-dev@jakarta.apache.org/msg00532.html
>
>  I'm currently subclassing FileAppender and overriding setFile() (as
>mentioned in the thread) to automatically create the directories implied by
>FileAppender.fileName if they do not already exist.  It would be helpful if
>this functionality were available in FileAppender.  This could be
>implemented with a property that could be on or off by default, such as
>createDirs.  Setting createDirs to true would then cause the FileAppender to
>write any directories that are needed to write the log file.
>
>  As to whether this is a proper function to provide to the user, I propose
>that if the file is created if it does not exist, then the directories
>should similarly be created if they also do not exist.  Why should there be
>a distinction between the path to the file and the file itself?  It seems to
>me that this (arbitrary?) distinction is an artifact of the native
>implementation of FileOutputStream.openAppend(), which, it seems to me,
>could easily have been implemented to write the directories also, if needed.
>
>  I am interested in hearing any counter-arguments.  Thanks for taking a
>look at this.  BTW, I'd be happy to implement the change and submit it via
>email if there aren't any objections.
>
>  - Matt
>
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>

--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>