Quartz and xml configurations.

[JeanNiBee]

Hi

I'm wondering, how can I modify (or add) scheduled events to my quartz jobs given that they are configured by the XYZ-spring-servlet.xml file.

In general I would just modify the XML File that hosts the configurations and then reload the webapp so it reads the changes and applies them.

But manual modifications are so passe, I'd like to wrap a UI on top of this.

Question: Is there any way I can changes parameters programmatically so they are available on the next iteration of the job WITHOUT a reload of the app?

Again I'm thinking that I could:
1. Modify the xml file programmatically (so the changes will persist a system restart).
2. do a "getBean()" on the job / timer I want to modify and set some properties that represent the new scheduler settings.
3. Sit back and watch the system run with the given new properties.

I'm sure it's not THAT simple... but I have been proven wrong before on this forum.

Thanks.

[Developer Dude]

This is essentially what I want to do, except I don't want to wrap a UI on top of changing the XML file - I just want to allow some kind of UI to push a button to reload the XML context file for the schedule beans (which are in a separate XML file from all other app context files).

Right now, I am changing the XML file, then using Tomcat to restart the app/servlet, which is okay, but seems like a lot of brute force if there were some fairly straight-forward logic I could add to my app to trigger a reload. This isn't a big deal as we don't change the config that often - maybe once a month, but it seems inelegant if there were a simple way to do it without restarting the servlet. OTOH, I don't want to bother with a lot of persistence logic just to make this a *little* cleaner than it is now.

I have a status page (JSP) that displays the jobs and their statuses, I don't think it would take much to add a simple button that would signal the page controller to in turn somehow cause the Scheduler or Scheduler factory to reload/restart. Naturally this would not be done in the middle of running jobs.

This seems to be a clue, but I am not sure yet:

http://forum.springsource.org/showthread.php?t=34727

I am searching the forum and have read a few dozen related threads, but I thought I would ask first:

a) Is this something that will require a lot of futzing around to get working?

b) Is this something that isn't practical because of how Spring loads contexts? I seem to recall similar questions about dynamic reloading of a general Spring context not really being practical or feasible.

c) Or is there something staring me straight in the face that I am missing? Like a real simple example somewhere?

Thanks in advance.

[chudak]

The question is do you want the changes to persist past application restarts? Or just within the current execution?

You can easily manipulate your jobs programmatically (even ones that got scheduled via your spring config) but if the changes would get nuked on the next restart if you have your quartz config set to overwrite jobs on restart.

[Developer Dude]

The question is do you want the changes to persist past application restarts? Or just within the current execution?

You can easily manipulate your jobs programmatically (even ones that got scheduled via your spring config) but if the changes would get nuked on the next restart if you have your quartz config set to overwrite jobs on restart.

I want them to persist, but like I said I don't want to go to the bother of a UI to allow a user to manipulate the jobs - manually changing the XML is fine for now (the only people who change these at this point is developers).

My workflow would be:

1) Manually change (with a text editor) the XML file where the jobs, triggers and scheduler factory are defined.

2) Press a button in the status page which then causes the app/servlet to reload the XML configuration.

I know that is not that much different from restarting the app via the Tomcat management web page, but it *seems* cleaner to me. Just seems crude to totally reload the app, *AND* besides that, I lose some internal state (the status of previous jobs I have run, which are held in memory by a job listener for the benefit of the status page) - which I just now remembered was the more compelling reason for me to not restart the app/servlet. It would be nice to keep that state around so that we aren't losing it just because I changed the config.

Eventually, I would like to have or write a nice front end for Quartz to manage its jobs with a persisting data store/etc., if something like Spring Batch doesn't (or won't in the future) already provide that, but right now there isn't enough of a business case for it for my use. I know Quartz has/had a UI, but it wasn't maintained and doesn't work with the current version of Quartz (the last time I looked) - but this is all beside the point.