Re: [jsecurity-dev] Remove Quartz integration?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [jsecurity-dev] Remove Quartz integration?

Alan D. Cabrera
Makes sense to me.  Make it an example or put it into the sandbox when  
the code base gets moved to ASF.


Regards,
Alan

On Jul 26, 2008, at 12:33 PM, Tamás Cservenák wrote:

> +1 for reducing dependencies on jsec-core :)
>
> You could move this code to "samples" or "extras", just like you have
> spring support, do not drop the code completely, only make it
> optional.
>
> ~t~
>
> On Sat, Jul 26, 2008 at 9:18 PM, Niklas Gustavsson <[hidden email]
> > wrote:
>> On Thu, Jul 24, 2008 at 9:22 PM, Les Hazlewood <[hidden email]>  
>> wrote:
>>> Any objections of me removing it (and the quartz.jar dependencies)  
>>> from the
>>> project?
>>
>> +1, remove it.
>>
>> /niklas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
>
> --
> Thanks,
> ~t~
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [jsecurity-dev] Remove Quartz integration?

Jeremy Haile
I don't think there's a good reason to leave Quartz in -  
ExecutorService works just fine for what we need and doesn't require  
an extra jar.

+1 for removing it.


On Jul 25, 2008, at 9:25 AM, Les Hazlewood wrote:

> 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  
> <[hidden email]>
> 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 <[hidden email]>:
>>> 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
>>
>>
>>

Loading...