Thanks. I might give that a try. If it works like I think it does it would be null if you aren’t in a JEE container but contain an instance of one otherwise.
Ralph On May 21, 2014, at 11:25 AM, Matt Sicker <[email protected]> wrote: > Looks like the equivalent JEE one would be ManagedScheduledExecutorService, > though it looks like the only way to get an instance of one would be through > @Resource injection. I can't find anything else in the docs. > > > On 21 May 2014 12:52, Ralph Goers <[email protected]> wrote: > You don’t want to use TimerTask directly as those tasks are supposed to > finish as fast as possible as they all run on one thread. Actually > Executors.newScheduledThreadPool looks exactly like what I would want to use > (except, I guess, when running in a JEE container). > > Ralph > > On May 21, 2014, at 9:56 AM, Matt Sicker <[email protected]> wrote: > >> So couldn't you just use java.util.Timer with java.util.TimerTask? Or are >> you thinking more along the lines of Executors.newScheduledThreadPool? >> >> >> On 21 May 2014 11:51, Ralph Goers <[email protected]> wrote: >> I definitely don’t want to be dependent on JEE for a timer service. >> Ralph >> >> >> On May 21, 2014, at 9:40 AM, Paul Benedict <[email protected]> wrote: >> >>> You may want to provide a standard Java EE solution using the Timer service: >>> http://docs.oracle.com/javaee/6/tutorial/doc/bnboy.html >>> >>> >>> Cheers, >>> Paul >>> >>> >>> On Wed, May 21, 2014 at 11: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 >>> >> >> >> >> >> -- >> Matt Sicker <[email protected]> > > > > > -- > Matt Sicker <[email protected]>
