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 Matt Munz <mm...@apelon.com> on 2002/01/08 15:02:13 UTC

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>


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

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


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

Posted by Matt Munz <mm...@apelon.com>.
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>