Ok... So for deployment...I can choose to use the deployment config that you have offered, but, if I choose to add a job from obtaining the factory, retrieving the scheduler object, I can add to it myself with my own GUI? Same scheduler, etc?
Are you also testing that the job does not already exist? 99% of the Quartz installations change from the in-memory to a database. Just being thorough ;-) As long as its add-on, but does not pre-suppose accessing the same scheduler through the Quartz API, then I am ok with it. Thanks, Jeff Aaron Mulder wrote: > You've mistaken what I'm saying. > > You don't need to write a GBean to deploy a job. (The deployer > creates the GBean for you.) > > You just write your job class(es) like normal (just implement "Job" or > whatever), put them in a JAR, and then include a deployment plan with > the schedule for the jobs. There's an example plan below (note that > it can add dependencies to the classpath for your jobs like any other > plan can, in addition to listing the jobs to be scheduled). Then you > can deploy this JAR using our normal deployment tools, and your job is > scheduled. > > I'm not trying to replace existing Quartz tools. If you're going to > run a Quartz server to handle hundreds of jobs, then there's no need > for Geronimo, but even if you did run it in Geronimo, you'd use your > normal Quartz management tools. > > I'm more looking at the case of an application that needs to run a > daily import, daily export, and monthly report. Who wants to learn a > new set of admin tools just for that? Instead of fooling with > specialized tools, just put your job classes in a JAR and deploy that > JAR along with the rest of your application. Voila! Scheduled jobs. > If you update the jobs, you can redeploy them just like any other > code. > > Thanks, > Aaron > > <jobs xmlns="http://geronimo.apache.org/xml/ns/plugins/quartz-0.1";> > <environment xmlns="http://geronimo.apache.org/xml/ns/deployment-1.1";> > <moduleId> > <artifactId>TestJobs</artifactId> > </moduleId> > </environment> > <job> > <job-name>Frequent Job</job-name> > <job-class>org.gplugins.quartz.jobs.TestJob</job-class> > <cron-expression>0/15 * * * * ?</cron-expression> > </job> > <job> > <job-name>Uncommon Job</job-name> > <job-class>org.gplugins.quartz.jobs.AnotherJob</job-class> > <cron-expression>0 10 10 * * ?</cron-expression> > </job> > </jobs> > > > On 6/11/06, Jeff Genender <[EMAIL PROTECTED]> wrote: >> >> >> Aaron Mulder wrote: >> > I looked at the developerworks article. The GBean there is extremely >> > simple. It starts a Quartz scheduler, but has no code or methods to >> > configure it or do anything with it. I think it was more a >> > demonstration of how to write a GBean than anything else. >> > >> >> Thats exactly what it was for. However, my familiarity with Quartz is >> only why I am commenting here. >> >> > As for why I wanted to represent jobs as GBeans, it's so you can >> > deploy and manage them. That is, you can deploy a job, start it, stop >> > it, or undeploy it, as well as managing its schedule, executing it >> > immediately, querying the last time it ran and the next time it'll >> > run, etc. Since it's a unit that can be deployed and managed, it >> > seemed logical to represent it as a GBean. >> > >> > I guess the alternative you're suggesting is to expose the scheduler >> > as a GBean and if you want to do anything with jobs you have to >> > interact with the scheduler GBean and call methods on it. That would >> > work, but I don't think it's as nice in practice. For one thing, I'm >> > not sure how you'd get the job classes to the scheduler -- it seems >> > like you might need to alter the scheduler module to add more >> > dependencies every time you added new jobs -- at least if you were >> > using a database for job persistence. Also, if you want to add a job, >> > you need to write some kind of code to access the scheduler and add >> > the job, which seems a little onerous. >> > >> >> I am a little confused by your last 2 paragraphs. Yes, I am in complete >> support of exposing the scheduler as a GBean and possibly use the >> methods to add/remove/manage jobs as a secondary proposition. But this >> is for console purposes only. >> >> If you need access to the scheduler, why not expose it via JNDI, only >> using the GBean for lifecycle? This has been the way it has been done >> in the past when I have needed access to it when developing J2EE >> applications. If not JNDI, why not via JMX? This allows us to J2EEify >> it. Nevertheless, the Quartz scheduler access is a singleton in its own >> right. So that should be a consideration. This to me seems like the >> most simplest approach to allowing people to update/add/remove/manage >> their Jobs with the tools they are normally accustomed to, and for >> compatibility with their current codebase. Let Quartz do what it was >> made to do. >> >> >> > With the job-as-GBean approach, in contrast, you can pack your job >> > classes in a JAR with a plan that defines the schedule, and deploy >> > that using the normal Geronimo deployment tools. Then in addition to >> > convenient deployment, they each get their own class loader, and can >> > declare dependencies on other application modules (e.g. to get the >> > classes necessary to call a session bean). >> >> This makes things so much more complex. Asking users to have to write >> GBeans for Jobs is too much IMHO. Many people have written GUIs to add >> and manage jobs with Quartz (look at JIRA admin screens as they have as >> well). Enforcing our API on others is wrong, IMHO. I would keep things >> as simple and compatible as possible with the code others have written. >> They expect that Quartz is started and stopped in a J2EE server, and >> that they can access it through the singletons. >> >> Being that a scheduler is typically at the server level, I am not >> convinced separate classloaders is appropriate for a scheduler. >> >> I am completely open to the ideas you have presented, but I need a clear >> understanding of how users can leverage it w/o needed to e3xercise >> Geronimo specific code. >> >> Jeff >> > >> > Thanks, >> > Aaron >> > >> > On 6/11/06, David Jencks <[EMAIL PROTECTED]> wrote: >> >> >> >> On Jun 11, 2006, at 4:20 PM, Aaron Mulder wrote: >> >> >> >> > So I've been playing around with a Quartz integration plugin. My >> >> > first stab only supported an in-memory schedule, but Quartz also >> >> > supports storing to a database. Here's my issue with that. >> >> > >> >> > Right now I have a GBean representing a scheduled job. When you >> start >> >> > it, the job is scheduled. When you stop it, the job is deleted. >> >> > Therefore when you start the server, the scheduler is started and >> the >> >> > deployed jobs are started, and I guess they're effectively >> persistent >> >> > using config.xml as storage instead of using a DB. >> >> >> >> I've never used quartz but the idea of a job as a gbean seems odd to >> >> me. I would expect there would be one quartz gbean and everything >> >> you scheduled would be saved in a database. Can you provide a lot >> >> more detail about what the job gbean is like? So far I don't get it, >> >> it seems like extreme impedance mismatch. >> >> >> >> >> >> > >> >> > So let's say we let you store the job info to a database. What >> >> > happens to the job GBeans? You can take down the server, delete all >> >> > your jobs from config.xml, add some new jobs to the database, and >> >> > start the server again. So the GBeans can get totally out of sync >> >> > with the data they represent. >> >> > >> >> > I guess what would be most appropriate for this case would be some >> >> > kind of "transient GBean" that does not save to config.xml. So when >> >> > the scheduler starts it could create GBeans representing all the >> jobs, >> >> > which you could use to manage it, but changes to the GBeans would >> only >> >> > affect the Quartz database (not config.xml) and when you shut down >> >> > they'd all go away. Until next time you start up, and the scheduler >> >> > would recreate all the job GBeans again. What do you think? >> >> >> >> I don't get why these are "gbeans". I must be missing something >> >> important here. >> >> > >> >> > The alternative is to keep using GBeans as persistence, and just add >> >> > GBeans to represent calendars and triggers, which are the other two >> >> > fundamental types in Quartz. That certainly seems like the more >> >> > expedient path for now. >> >> >> >> I also don't understand why these other types would be gbeans >> >> either. I'd really appreciate more detail on this. This could well >> >> be the best model, but I don't see why yet :-) >> >> >> >> BTW I thought jeff already did a quartz integration, in a >> >> developerworks article, have you looked at what he did? >> >> >> >> thanks >> >> david jencks >> >> >> >> > >> >> > Thanks, >> >> > Aaron >> >> >> >> >>
