geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: GBeans representing separately persistent data
Date Mon, 12 Jun 2006 01:49:55 GMT

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.



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="">
>    <environment xmlns="">
>        <moduleId>
>            <artifactId>TestJobs</artifactId>
>        </moduleId>
>    </environment>
>    <job>
>        <job-name>Frequent Job</job-name>
>        <job-class></job-class>
>        <cron-expression>0/15 * * * * ?</cron-expression>
>    </job>
>    <job>
>        <job-name>Uncommon Job</job-name>
>        <job-class></job-class>
>        <cron-expression>0 10 10 * * ?</cron-expression>
>    </job>
> </jobs>
> 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