Plugin for Quartz 2.1 library

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Plugin for Quartz 2.1 library

basejump (Josh)
I'd like to get some opinions on a plugin we put together for Quartz 2.1
it can be found here with the write up.
https://github.com/9ci/grails-quartz-kiss
A big question I have is will we run into trouble relying so heavily on closures inside of an external config.groovy

Would appreciate any input
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: [grails-user] Plugin for Quartz 2.1 library

pledbrook
> I'd like to get some opinions on a plugin we put together for Quartz 2.1
> it can be found here with the write up.
> https://github.com/9ci/grails-quartz-kiss
> A big question I have is will we run into trouble relying so heavily on closures inside of an external config.groovy
>
> Would appreciate any input

First, thanks for doing this and for producing some documentation to
work from! I think the idea of a separate Quartz 2 plugin is fine,
although we should probably update the descriptions of the two plugins
so it's clear what the differences are and which one users should go
with.

One thing I'm not particularly keen on is the creation and scheduling
of jobs via config. To my mind, a job is an artifact and should be
made available as such. Config.groovy should just be used for
configuration settings. Of course, many things could be considered as
configuration settings, but the current scheme doesn't seem right to
me.

On the general use of closures in Config.groovy or BuildConfig.groovy,
there are costs. In particular, you lose selective overriding of parts
of a configuration. For example, consider the logging DSL: you have to
override the whole log4j setting if you want to have a slightly
different configuration between one environment and another. That
said, a closure gives you the full power of a DSL.

Would it not be possible to use the declarative approach taken by the
original Quartz plugin?

Cheers,

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: [grails-user] Plugin for Quartz 2.1 library

Jean Barmash 1
To chime in.

For configuring schedules of jobs, I find it very convenient to have that ability in Config - allows me to externalize the config and tweak it on different servers appropriately. 

In fact, a convention I established for all my jobs in my project is the following - have a default cron expression in triggers in the job, but with a reference to config that can override that. 

    static triggers = {
        cron ( ConfigurationHolder.config.quartz.jobs.QueryJob?.cron ?: [name: 'queryJob', cronExpression: '0 0 1 * * ?'] )  // 1:00 am every day
    }

In External-Config.groovy that gets merged:

quartz.jobs.QueryJob.cron = [name: 'queryTrigger', cronExpression: '0 0 2 * * ?']  // 1:00 am every day

Also allows you to disable a job easily in the config (or effectively disable it by setting next execution time far in the future). 

This way I can tweak my schedule as needed.  Another plugin I found very useful is quartz-monitor - which allows you to kick off your or pause jobs manually - also very useful during testing. 
  http://grails.org/plugin/quartz-monitor

Thanks,

Jean

On Wed, Dec 14, 2011 at 8:31 AM, Peter Ledbrook <[hidden email]> wrote:
> I'd like to get some opinions on a plugin we put together for Quartz 2.1
> it can be found here with the write up.
> https://github.com/9ci/grails-quartz-kiss
> A big question I have is will we run into trouble relying so heavily on closures inside of an external config.groovy
>
> Would appreciate any input

First, thanks for doing this and for producing some documentation to
work from! I think the idea of a separate Quartz 2 plugin is fine,
although we should probably update the descriptions of the two plugins
so it's clear what the differences are and which one users should go
with.

One thing I'm not particularly keen on is the creation and scheduling
of jobs via config. To my mind, a job is an artifact and should be
made available as such. Config.groovy should just be used for
configuration settings. Of course, many things could be considered as
configuration settings, but the current scheme doesn't seem right to
me.

On the general use of closures in Config.groovy or BuildConfig.groovy,
there are costs. In particular, you lose selective overriding of parts
of a configuration. For example, consider the logging DSL: you have to
override the whole log4j setting if you want to have a slightly
different configuration between one environment and another. That
said, a closure gives you the full power of a DSL.

Would it not be possible to use the declarative approach taken by the
original Quartz plugin?

Cheers,

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email