a) As I’ve said I would prefer not to introduce 3rd party jars as required dependencies b) The scheduler doesn’t need to persist the schedule.
In this case simply using the java.util.Timer class feels to me like the correct “scheduler” to use and just wrap it to include an Executor. So I don’t think leveraging a third-party scheduler makes sense here. Ralph On May 21, 2014, at 9:33 AM, Gary Gregory <[email protected]> wrote: > We embed Quartz at work for scheduling. Instead of inventing our own, perhaps > we could make this pluggable with a really "simple" default that is our own. > > Surely there are already other schedulers in the Apache lands. > > Gary > > > On Wed, May 21, 2014 at 11:31 AM, Remko Popma <[email protected]> wrote: > 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] > > > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory
