logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Lima" <onl...@l3o.net>
Subject Re: Enhanced FileAppender
Date Thu, 05 Oct 2006 15:17:33 GMT

"Bender Heri" <HBender@Ergonomics.ch> escreveu na mensagem 
> 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.

That's too bad that you can't have more time for helping, but just adding to 
the discussion is already enough.

> 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.

I agree.

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

That's what KeyFileAppender does, and I think it's enought. But, sure, if 
I'd like to split the files on directories, I guess it would be no use? Or 
if we make the File name have special meaning like $X{mdc values}, that 
would be cool. Can it be done now?

> 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.

I don't know. Since I read that JEE doesn't allow user threads and I use 
log4j inside a JEE env, I'm paranoid about it. I think the GC on new file 
creation is good enough. No need to timeout, only limiting to max open 

> 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.


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

View raw message