I can see how that would solve one or more issues that keep coming up with the RollingAppender. I hope that it may also make it easier to break down the rollover logic into smaller pieces that can be unit tested easier, something that I've been meaning to work on.
The only drawback (if this even is a drawback) I can think of is that we would always be running a background thread. At the moment Log4J only starts a background thread when Async Loggers are used, or potentially multiple threads for every AsyncAppender that is configured. Perhaps we can start by creating the thread unconditionally and later enhance to only create/start the Executor if necessary: when a RollingAppender or a monitoringInterval is configured. I can't think of anything else, sounds like a good idea to me. On Wed, May 21, 2014 at 11:52 PM, Ralph Goers <[email protected]>wrote: > I am thinking that I am going to add a Scheduler class. It will expose a > schedule method that accepts a Runnable as a parameter along with the > initial time and frequency. The schedule method would schedule a Timer > Task that passes the Runnable to an Executor when the time expires. > > I would then use this service to check for configuration changes and file > rollovers instead of the way it is currently done, which requires log > events to trigger them. > > Thoughts? > > Ralph > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
