>My current plan is to dummy up a new RFA (configuration points) and >write the XML doc for the configuration points and pass the result of >that out for review and comments. We must be explicit about the >semantics of the new configuration. We have already observed cases >where I have not correctly interrupted the meaning of Dominik was >suggesting. Once we agree on the configuration and semantics of that >configuration, things can go better. > >I am also thinking about not deriving from FileAppender as Curt >mentioned in the emails about the new RFA for log4j. I will have to >think about that more after we finalize the new design and I see the new >FileAppender with the Mutex locking etc. > >If we want to support Mutex locking in RFA(NG), then it might be best to >continue to derive from FileAppender and wrap all the rolling in the >Mutex. If we do not want to support that type of locking, then not >getting involved with FileAppender may make the code cleaner, but it >will increase the amount of code.
Thanks for the information. This means that today, specifically in the evening around 20°°, I'm going to try my best to come up with a "RollingFileAppenderNG" implementation that derives from FileAppender. Therefore the first layout of the RFA-NG will be much like the current RFA. We can still iterate over write&review cycles as often as it takes.
