[ot] Quartz ?

[Brent Putman]

On 3/12/15 11:29 AM, Tom Zeller wrote:
> Agree. My thinking was if we're going to do the work of replacing
> Timers, I would tend to reach for Quartz because it allows for more
> advanced scheduling, meaning "update metadata everyday at 6am and 6pm
> and if the job fails with a remote unavailable exception then
> reschedule an hour later and email somebody". And that's overkill and
> not really appropriate for things like replay detection.

That was my initial though too.  However in the vein of thinking
outside the box, it occurs to me that our whole notion of component
refreshing is sort of based on the constraints that Timer implicitly
imposes: execution on a fixed, repeating schedule, or a variation
thereof (schedule my own next refresh in X seconds).

Something like what you describe using a Quartz cron trigger might
actually be pretty useful to some people.  Rather than say "refresh
every 8 hours" like now, a more deterministic cron type of schedule
might be more natural for some people and/or use cases.

Along a different axis: It also occurs to me that our current notion is
that things that are "refreshable" generally refresh themselves
"internally" - they have a Timer instance and they schedule their own
maintenance tasks, or reloads, etc.  The alternative way is to do it 
"externally", where the jobs are defined elsewhere (e.g Quartz) and the
job simply calls the components external refresh() method or whatever. 
Quartz can already easily do that with a nice Spring bean config. 
There are design advantages and disadvantages either way.

Just some food for thought.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20150312/bde8c481/attachment.html