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:[EMAIL PROTECTED] Behalf Of Leo Lima > Sent: Thursday, October 05, 2006 2:46 PM > To: [email protected] > Subject: [SPAM (Bayesain Analysis)] - Re: Enhanced FileAppender - > Bayesian Filter detected spam > > > > "Curt Arnold" <[EMAIL PROTECTED]> escreveu na mensagem > news:[EMAIL PROTECTED] > >>> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
