logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: Enhanced FileAppender
Date Fri, 06 Oct 2006 02:38:54 GMT

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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message