|
From: Mark P. <Mar...@Co...> - 2003-09-12 13:19:20
|
Hi, You might want to check out Doug Lea's Scheduler in his util.concurrent package for a base implementation, maybe wrapped to be more JavaBean friendly. The J2EE timer service in JBoss might be a good place to look as well.... Services are typically singletons, so going to an ApplicationContext/BeanFactory to get a reference to it should be sufficient I would think. BTW, I am following up on Jurgen's advice regarding service lifecycles, modifying my implementation. The scheduler could be an out of the box service, since it should probably only start after all beans have been wired. - Mark > Rod Johnson wrote: >> Yes I think this could be useful. I could envisage uses for it. > > I will study Spring coding and design standards and > come back with more details. > > >> I don't quite understand the "integration with the context" you propose. >> Couldn't the scheduler be a BeanFactoryAware bean in a context, and its >> setBeanFactory() method give it access to whatever other beans it needs >> and >> also kick off its timer/whatever? >> >> Of course it could be configured by its JavaBean properties. > > Yes. But there is also a case where you want to schedule events > from your code. There are three ways to achieve this: > > 1) Explicit configuration, create a scheduler and then give > its reference to every bean that needs it. > > 2) Have the scheduler as a shared object; other beans have to > be ApplicationContext aware, and use a call to sharedObject() > to retrieve the scheduler reference. > > 3) Add getScheduler() method to ApplicationContext. I actually > don't like this approach. I only mentioned it because it is > a possibility. > > From my point of view, 1 and 2 are acceptable options. The third > option would lead to a fat app. context, and I don't see real > benefit there. > > Maybe Spring should define certain names (with or without > a namespace) to be reserved for certain services, e.g. > "service.scheduler". People will certainly do this > themselves, perhaps if we do it on a framework level we > can have greater "portability". > > -- > ModSecurity (http://www.modsecurity.org) > [ Open source IDS for Web applications ] > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |