A few months ago I wrote a couple of adapters to integrate Quartz.Net into Windsor. These were loose components that you had to register yourself and the configuration wasn't very friendly. So I decided to wrap them in a facility to make things
... [More]
cleaner and easier. This is what the facility provides: Some Windsor-managed Quartz entities: IJob / IStatefulJob ISchedulerListener IJobListener (both global and per-job) ITriggerListener (both global and per-trigger) IScheduler IJobFactory (although you probably won't use this...) Automatic FileScanJob registering IJobScheduler: a simpler IScheduler Automatic scheduler starting if the Startable facility is present (otherwise you'll have to call IScheduler.Start() manually) Here's what it doesn't support: These entities are NOT Windsor-managed (they are instantiated normally by Quartz instead) IThreadPool IJobStore ISchedulerPlugin All other interfaces and/or quartz entities Listeners declared in quartz_jobs.xml Trigger and job group names Note that it's up to you to register jobs with the appropriate lifestyle. Listeners can only have singleton lifestyle since they're injected in IScheduler which is itself a singleton. Here are the bits: Binaries Sample app (source code) [Less]
|
A few months ago I wrote a couple of adapters to integrate Quartz.Net into Windsor. These were loose components that you had to register yourself and the configuration wasn't very friendly. So I decided to wrap them in a facility to make things
... [More]
cleaner and easier. This is what the facility provides: Some Windsor-managed Quartz entities:
IJob / IStatefulJob
ISchedulerListener
IJobListener (both global and per-job)
ITriggerListener (both global and per-trigger)
IScheduler
IJobFactory (although you probably won't use this...) Automatic FileScanJob registering IJobScheduler: a simpler IScheduler Automatic scheduler starting if the Startable facility is present (otherwise you'll have to call IScheduler.Start() manually) Here's what it doesn't support: These entities are NOT Windsor-managed (they are instantiated normally by Quartz instead)
IThreadPool
IJobStore
ISchedulerPlugin All other interfaces and/or quartz entities Listeners declared in quartz_jobs.xml Trigger and job group names Note that it's up to you to register jobs with the appropriate lifestyle. Listeners can only have singleton lifestyle since they're injected in IScheduler which is itself a singleton. Here are the bits:
Binaries
Sample app (source code) [Less]
|
A few months ago I wrote a couple of adapters to integrate Quartz.Net into Windsor. These were loose components that you had to register yourself and the configuration wasn't very friendly. So I decided to wrap them in a facility to make things
... [More]
cleaner and easier. This is what the facility provides: Some Windsor-managed Quartz entities: IJob / IStatefulJob ISchedulerListener IJobListener (both global and per-job) ITriggerListener (both global and per-trigger) IScheduler IJobFactory (although you probably won't use this...) Automatic FileScanJob registering IJobScheduler: a simpler IScheduler Automatic scheduler starting if the Startable facility is present (otherwise you'll have to call IScheduler.Start() manually) Here's what it doesn't support: These entities are NOT Windsor-managed (they are instantiated normally by Quartz instead) IThreadPool IJobStore ISchedulerPlugin All other interfaces and/or quartz entities Listeners declared in quartz_jobs.xml Trigger and job group names Note that it's up to you to register jobs with the appropriate lifestyle. Listeners can only have singleton lifestyle since they're injected in IScheduler which is itself a singleton. Here are the bits: Binaries Sample app (source code) [Less]
|
A couple of months or so ago, I had to code some periodic maintenance jobs to be run in-process. So I was faced with the same options that Ayende had a year ago (except the out-of-process options). I finally decided on using Quartz.NET, since I
... [More]
needed the dynamic update capabilities (that is, it watches the config file for changes and re-schedules accordingly) which Castle.Components.Scheduler doesn't have yet as far as I know... (BTW Castle.Components.Scheduler is now part of the trunk). So I set to code the wrappers needed to make it play with Windsor, and the resulting code is here. There's a sample app that shows how to set up job and trigger listeners (both global and job-specific). The actual scheduling configuration is managed by Quartz.NET of course. In the sample I used the external quartz_jobs.xml config with the default RAMJobStore, but you could easily change that to a ADOJobStore or anything, just by setting the props dictionary on the QuartzNetScheduler component, that dictionary is passed as-is to Quartz.NET. Why did I write "basic" integration on the title? Well, I just needed the basic features of Quartz.NET, so I didn't even try to integrate stuff like clustering, remote servers, etc. I have no idea if those will work with my code. If anyone gives it a try, I'd love to hear about it :-) UPDATE 4/3/2009: I wrapped the components in a facility for easier usage and configuration. [Less]
|
A couple of months or so ago, I had to code some periodic maintenance jobs to be run in-process. So I was faced with the same options that Ayende had a year ago (except the out-of-process options). I finally decided on using Quartz.NET, since I
... [More]
needed the dynamic update capabilities (that is, it watches the config file for changes and re-schedules accordingly) which Castle.Components.Scheduler doesn't have yet as far as I know... (BTW Castle.Components.Scheduler is now part of the trunk). So I set to code the wrappers needed to make it play with Windsor, and the resulting code is here. There's a sample app that shows how to set up job and trigger listeners (both global and job-specific). The actual scheduling configuration is managed by Quartz.NET of course. In the sample I used the external quartz_jobs.xml config with the default RAMJobStore, but you could easily change that to a ADOJobStore or anything, just by setting the props dictionary on the QuartzNetScheduler component, that dictionary is passed as-is to Quartz.NET. Why did I write "basic" integration on the title? Well, I just needed the basic features of Quartz.NET, so I didn't even try to integrate stuff like clustering, remote servers, etc. I have no idea if those will work with my code. If anyone gives it a try, I'd love to hear about it :-) UPDATE 4/3/2009: I wrapped the components in a facility for easier usage and configuration. [Less]
|
A couple of months or so ago, I had to code some periodic maintenance jobs to be run in-process. So I was faced with the same options that Ayende had a year ago (except the out-of-process options). I finally decided on using Quartz.NET, since I
... [More]
needed the dynamic update capabilities (that is, it watches the config file for changes and re-schedules accordingly) which Castle.Components.Scheduler doesn't have yet as far as I know... (BTW Castle.Components.Scheduler is now part of the trunk). So I set to code the wrappers needed to make it play with Windsor, and the resulting code is here. There's a sample app that shows how to set up job and trigger listeners (both global and job-specific). The actual scheduling configuration is managed by Quartz.NET of course. In the sample I used the external quartz_jobs.xml config with the default RAMJobStore, but you could easily change that to a ADOJobStore or anything, just by setting the props dictionary on the QuartzNetScheduler component, that dictionary is passed as-is to Quartz.NET. Why did I write "basic" integration on the title? Well, I just needed the basic features of Quartz.NET, so I didn't even try to integrate stuff like clustering, remote servers, etc. I have no idea if those will work with my code. If anyone gives it a try, I'd love to hear about it :-) UPDATE 4/3/2009: I wrapped the components in a facility for easier usage and configuration. [Less]
|
