|
From: Norm D. <nor...@va...> - 2006-02-06 18:41:33
|
I think in my current situation the "extending QuartzJobBean approach" would work fine but I'm sure at some point there will be a situation where it is not practical (legacy quartz job maybe). Norm Joris Kuipers wrote: > > > 2006/2/6, Norm Deane <nor...@va... > <mailto:nor...@va...>>: > > I've been wanting to dependency-inject my Quartz jobs for a while > now. It looks > like with the new JobFactory in Quartz 1.5 we could pull this off by > creating a > simple implementation (SpringBeanNameJobFactory?) that pulls Jobs > from the > ApplicationContext by bean name. > > Thoughts? If this sounds reasonable I'll create an issue in Jira and > time > permitting upload a patch. > > > You can also subclass Spring's QuartzJobBean and let your dependencies > be injected from Quartz's SchedulerContext or JobDataMap (the one merged > with the Trigger's, in Spring 2.0-M2). Not the same thing, but it > achieves the same goal and works out of the box today. > If your jobs are persisted, make sure you don't put the > ApplicationContext (directly or indirectly) in the Job's JobDetailMap, > but use the SchedulerContext for that. > See > http://static.springframework.org/spring/docs/2.0-m2/api/org/springframework/scheduling/quartz/QuartzJobBean.html > <http://static.springframework.org/spring/docs/2.0-m2/api/org/springframework/scheduling/quartz/QuartzJobBean.html> > for more info. > > Joris > |