Here's another way to think of it. Quartz is a Job container, just like Tomcat is a Servlet container and OpenEJB is an EJB container.
Thanks, Aaron On 6/11/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
Why would you want Jobs based GBeans? This makes no sense to me. Those are innately Quartz objects in their own right. IMHO, everything does not need to be a GBean...especially when working with 3rd party components. I am personally against Jobs being GBeans... I would leave every thing underneath Quartz as "native" Quartz as possible. Just my .02. Jeff 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. > > 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? > > 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. > > Thanks, > Aaron
