Hi Byron,
Thanks for the suggestion! I have added a corresponding "jobFactory" bean
property to SchedulerFactoryBean, since this is definitely worth explicit
exposure.
The only reason why we haven't added this before is that the JobFactory
interface has not been introduced before Quartz 1.5, hence constitutes a
Quartz 1.5+ dependency - which makes SchedulerFactoryBean unable to work
with Quartz 1.3/1.4, just because of the pure presence of the JobFactory
interface in the method signatures.
It is certainly feasible for Spring 2.0 to require Quartz 1.5 or higher (in
contrast to Spring 1.2), hence I've nevertheless introduced this JobFactory
support right away - to be available in the upcoming Spring 2.0 RC4.
Furthermore, I also consider adding a SpringBeanJobFactory, as direct
equivalent of Spring's QuartzJobBean - injecting bean properties from the
JobDataMap or SchedulerContextMap. This would be more capable than Quartz's
own PropertySettingJobFactory, in particular through supporting the
SchedulerContextMap as well.
Juergen
_____
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Byron Saltysiak
Sent: Wednesday, August 16, 2006 10:00 PM
To: spr...@li...
Subject: [Springframework-developer] Quartz and injecting JobFactory
Hi all.
This is in regards to the Quartz integration support in
org.springframework.scheduling.quartz
<http://static.springframework.org/spring/docs/1.2.x/api/org/springframework
/scheduling/quartz/package-summary.html>
I could not find a way (in 1.2.x or CVS HEAD) to use the
SchedulerFactoryBean to inject my own implementation of a JobFactory into
Schedulers that it creates. Is anyone working on this? If not let me know if
you want me to contribute either of the solutions below.
Solution 1:
I solved the problem at first by extending ScheduleFactoryBean, adding this
field and overriding createScheduler to set the the jobFactory field on
every Scheduler created after the super method completes. This is the only
field like this (one to be set on every Scheduler created) so this seems
like a reasonable solution.
The spring config then looks like:
<bean id="scheduler" class="com.xyz.JobFactorySchedulerFactoryBean">
<property name="jobFactory" ref="jobFactory" />
</bean>
<bean id="jobFactory" class="com.xyz.DbJobFactory" />
Solution 2:
This solution plans for similar fields being added in the future to
Scheduler (although it doesn't look like Quartz 1.6 will have any based on
the repository). The idea is to create a mostly unimplemented prototype
Scheduler that has all fields set that future Schedulers from the
SchedulerFactory should have. This requires an additional object but seems
nicer than adding fields to the SchedulerFactory that it doesn't actually
use.
createScheduler is again overridden so that super is called first and then
fields from the prototype are copied into each Scheduler that the
SchedulerFactory creates. The benefit of this solution is that the prototype
could hold multiple fields to copy and the SchedulerFactoryBean can remain
blissfully unaware when new fields of this type are added.
The spring config looks like:
<bean id="scheduler" class="com.xyz.PrototypeSchedulerFactoryBean">
<property name="prototype" ref="prototypeSchedule" />
</bean>
<bean id="jobFactory" class="com.xyz.DbJobFactory" />
<bean id="prototypeSchedule" class="com.xyz.SchedulerPrototype">
<property name="jobFactory" ref="jobFactory" />
</bean>
--
Byron
http://byron.saltysiak.com
|
