geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: GBeans representing separately persistent data
Date Mon, 12 Jun 2006 01:41:49 GMT
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

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


<jobs xmlns="">
    <environment xmlns="">
        <job-name>Frequent Job</job-name>
        <cron-expression>0/15 * * * * ?</cron-expression>
        <job-name>Uncommon Job</job-name>
        <cron-expression>0 10 10 * * ?</cron-expression>

On 6/11/06, Jeff Genender <> 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 <> 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
> >>
> >>

View raw message