On Oct 5, 2006, at 7:45 AM, Leo Lima wrote:
Well, in recurrent scheduling servers that open a log file per
schedule,
that would be totally necessary. I, for example, must use something
that has
append in it...
I was suggesting that there need not be an "append" attribute since
the use case for the append=false behavior is insufficient. Are you
saying it is essential that you have truncate behavior?
Headers and Footers are part of the layout, so you could not
prevent the
user from matching a MultiFileAppender with a layout with a
header or
footer. However, explicitly saying that you ignore them would be an
option, at least at first.
Let's say they're ignored, then.
At least not use a thread to manage it by default. Maybe an optional
parameter to specify a timer interval or an public method that an
interested user could add to a scheduler.
Fine by me. But I think the default should be a pool and the checks
should
be done when creating a new file descriptor...
If there is a closeAfter (open for suggestions on name) attribute,
that would need to be checked on each logging event. The idea is
that if you had a FileNamePolicy that returned a file name based on
the event time, that you could close the old day's log file 10
seconds into the new day and could tolerate a few out of sequence
time stamps (which can occur due to synchronization effects).
I did not mean that this is a must. I thought it is up to the
implementor of FileNameBuilder what she wants to do with the
configured filename. That's why I suggested to pass also the
calling appender as parameter to buildFileName().
5. I like the suggestion of Patrick that a user can force
the file closing
by a special log message at the end of a session.
I like the MDC 'close' message way. That could be done, yes.
If I get you right: You want to close the file dependent on the
presence (or absence) of a certain MDC value? I think it's better
to leave this also to the implementor of FileNameBuilder. If he
wants to work with MDC, ok. But he is still free for using any
other criterias as well.
I've mulled over having FileNamePolicy (calling it Policy instead of
builder is more consistent with o.a.l.rolling.TriggeringPolicy and
RollingPolicy) return some indication for file maintenance (like
close other files, close this file immediately after write, etc), but
it would either require two calls per event or an ugly signature
(like passing a StringBuffer instead of returning a String). In the
first iteration, I'm thinking it would be best to just start with
FileNamePolicy.getFileName(LoggingEvent event) and see how much that
can handle. I'm reluctant to add other parameters to the getFileName
method without a really compelling reason.
I could see having a "dir" attribute on MultiFileAppender so that
FileNamePolicy could return relative file paths. Maybe that would
cover the use cases where you wanted to inspect the appender.
On Oct 5, 2006, at 10:02 AM, Leo Lima wrote:
I went ahead and did change KeyFileAppender to add 3 getter methods
so I
could extend it and make a KeyPoolFileAppender (no, I'm not
creative...).
I did check for the 'Append' attribute, overwritting only if the
file hasn't
been visited yet. And I provided a simple working sample (that I
used to
validate). I don't know what to do next; if I publish it on my
website, on
bugzilla, or what?
I'm surprised that the mailing list didn't strip the attachments.
If it was your original code, you could have attached it to a bug
report and noted that it was intended as a contribution to the ASF.
Depending on the nature of the contribution, we may need to ask for a
Contributor's License Agreement (http://www.apache.org/licenses/
icla.txt). Since you code is a modification of someone else's code,
we'd likely need to have them contribute the original code to ASF and
then accept your modifications of that contribution.
Since dealing with all that is likely messier than the alternative,
what I'd suggest is let me get a sandbox project up and take a shot
at the problem without looking at your code. Then if there are
things in your code that you like better or use cases that we didn't
cover, we can possibly incorporate contributions based on your work.
I hope to have it up on Monday at the Hackathon. As I'm spending a
whole week in Austin doing things Apache, I'm pretty tied up at the
moment getting all sorts of other stuff in a reasonable state.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
