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<http://www.manning.com/bauer3/> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>> Spring Batch in Action <http://www.manning.com/templier/> >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >> >> >> > > > -- > Matt Sicker <[email protected]> > > > -- Matt Sicker <[email protected]>
