You raise a good point! This is a much better reason behind why I prefer to use Runnable, Callable<T>, etc., over Thread. This way you can use ManagedExecutors.managedTask(...) with the same classes.
On 21 May 2014 11:59, Paul Benedict <[email protected]> wrote: > As I am sure many of you already know, you don't want to create threads in > a container. You want to let the application server manage that. So I think > you guys should seriously consider supporting standard Java EE solutions > for those who are going to use this stuff in application servers. > > > Cheers, > Paul > > > On Wed, May 21, 2014 at 11: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]>
