Oops - yes, wrong list - thanks for forwarding it on to the proper one
Peter.

I guess my biggest point about the Quartz implementation of our
SessionValidationScheduler interface is that it offers nothing more than the
ExecutorService implementation - no difference in features or functionality,
so the dependency seems unnecessary.

I mean, if we were to implement, say, a 'cron' String property the Quartz
implementation to allow cron scheduling, which Quartz supports and
ExecutorService does not, then that might provide a more fine-grained
control of when the validation occurs.  But as it stands now, we don't have
that implemented, nor has anyone requested such capability.

I guess my vote is to remove the Quartz version (and any quartz
dependencies) until someone requests a 'cron-ish' capability, and then if
that is the case, we implement it then.

Or we could just leave it in too ;)  I was just trying to do a little
'spring cleaning' so to speak.  Does anyone else have a feeling one way or
the other?  Its not that big of a deal to me either way.

On Fri, Jul 25, 2008 at 2:15 AM, Peter Ledbrook <[EMAIL PROTECTED]>
wrote:

> Wrong list?
>
> Anyway, I'm not sure it's worth removing if it's a configurable
> option. From a Grails perspective, it's so easy to install the Quartz
> plugin that it's actually a reasonable option for users. I'm not
> saying that anyone *would* use it, but it would be there. Then again,
> I don't think it matters a whole lot :) So if you want to remove it,
> I'm fine with that too.
>
> Cheers,
>
> Peter
>
> 2008/7/24 Les Hazlewood <[EMAIL PROTECTED]>:
> > We have an optional dependency on Quartz at the moment for proactive
> session
> > validation when using our enterprise Sessions.
> >
> > Naturally our SessionValidationScheduler is an interface, and we have a
> > QuartzSessionValidationScheduler.
> >
> > But I recently (about 3 months ago?) added an
> > ExecutorServiceSessionValidationScheduler which uses the JDK's built-in
> > ExecutorService to validate sessions at a user-defined interval.  This is
> > our default implementation used in our code for automatic startup.
> >
> > This makes the Quartz implementation sort of an orphan at the moment - we
> > don't use it in our code or in any of our sample apps.   It is
> essentially
> > only there if an end-user explicitly configures a
> > QuartzSessionValidationScheduler, and I honestly don't think anyone does
> > that.  Almost any session validation configuration is done through
> > convenience passthrough properties (setValidationEnabled,
> > setValidationInterval, etc).
> >
> > Any objections of me removing it (and the quartz.jar dependencies) from
> the
> > project?
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

Reply via email to