logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bender Heri" <HBen...@Ergonomics.ch>
Subject Re: Enhanced FileAppender
Date Thu, 05 Oct 2006 13:35:01 GMT
Hi

great that now a real discussion about my proposal is launched and you, Curt, want to setup
a new project for it. But I am sorry that I have nearly no time for helping. I see my contribution
to log4j in helping people on the user list.

I like most of what you elaborated by now.

Some remarks:

1. If the problem with the append property could be solved I see no problems why not implementing
the enhancement in FileAppender itself. Consideration: If the value of append is true there
is no problem with the new solution. If it is false, the user wants to override the file at
every app start. The new solution has in my opinion no use case to set the append property
to false. So we could implement it like this:
  - if the FileNameBuilder is configured, append is always true
  - if the FileNameBuilder is not configured, append behaves in the old way. 

2. The method buildFileName() should have both parameters: the calling appender and the log
event

3. The configured file name can be used as base when building the concrete filename

4. Why afraid of Thread for implementing the internal file garbage collector? But it's also
OK to execute the GC whenever a new file should be opened.

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.

Heri



> -----Original Message-----
> From: news [mailto:news@sea.gmane.org]On Behalf Of Leo Lima
> Sent: Thursday, October 05, 2006 2:46 PM
> To: log4j-dev@logging.apache.org
> Subject: [SPAM (Bayesain Analysis)] - Re: Enhanced FileAppender -
> Bayesian Filter detected spam
> 
> 
> 
> "Curt Arnold" <carnold@apache.org> escreveu na mensagem 
> news:7178CB84-543A-4166-B93C-04F8EA01006A@apache.org...
> >>> Opening or reopening a log file will append to the file.
> >>
> >> That should be the case only if the log file was closed 
> due timeout  or 
> >> max
> >> open limit reached; because that would then mimic the behavior of
> >> FileAppender; the Append parameter being false, the file 
> is  overwritten 
> >> on
> >> first open...
> >
> > If there is an append attribute, then it would need to 
> follow the  pattern 
> > that you suggest.  However, I'm not sure that their is a  
> strong enough 
> > use case to support an "append" attribute.  Obviously,  if 
> you extend from 
> > FileAppender you would have one and would have to  figure 
> out what it 
> > means.  Supporting the "append" semantics that you  
> described would, like 
> > header and footer, require that you capture the  name of 
> every file ever 
> > opened during the application lifetime.
> 
> 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...
> 
> >
> > 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...
> 
> I'll try and extend the KeyFileAppender to include the pool I 
> mentioned and 
> see how it goes, as a side personal project. I really need a 
> quick solution 
> for max open files problem.
> 
> Regards,
> Leo. 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message