You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Jukka Zitting (JIRA)" <ji...@apache.org> on 2008/05/14 09:59:55 UTC
[jira] Commented: (SLING-446) Move Scheduling to commons
[ https://issues.apache.org/jira/browse/SLING-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596663#action_12596663 ]
Jukka Zitting commented on SLING-446:
-------------------------------------
Why is the scheduler bundle needed? Can't Sling use Quartz directly?
> Move Scheduling to commons
> --------------------------
>
> Key: SLING-446
> URL: https://issues.apache.org/jira/browse/SLING-446
> Project: Sling
> Issue Type: Task
> Components: Scheduler
> Affects Versions: 2.0.0
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Fix For: 2.0.0
>
>
> The scheduler is a common bundle which has no dependencies to Sling itself, so we should move it to commons.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SLING-446) Move Scheduling to commons
Posted by Carsten Ziegeler <cz...@apache.org>.
Jukka Zitting wrote:
> Hi,
>> It always makes sense to abstract things like the uses scheduling library;
>> this allows to change the implementation without breaking contracts.
>
> Or YAGNI, and adding the abstraction just introduces extra complexity
> and potential bugs.
This depends, creating an abstraction makes sense if you create a
framework providing special services - for long term solutions running
for years this makes sense (see Spring and their philosophy).
For implementations this might be yagni.
> Are there potential cases where Quartz wouldn't be
> appropriate for a Sling deployment?
You can't just use quartz by calling some methods, Quartz itself
requires some infrastructure like thread pooling or persistence stores
(which we don't use) etc. So it makes sense to keep this initial stuff
at a central place anyway. You definitly don't want that everyone who is
scheduling something, does this stuff on their own (and possibly
differently). This creates too many problems.
>
> I'm just looking at the scheduler code and all I'm seeing is wrapping
> around Quartz. If the purpose is to provide a nicer API for
> applications, shouldn't we be contributing that as an improvement to
> Quartz?
Sure, that's always an option.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [jira] Commented: (SLING-446) Move Scheduling to commons
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, May 14, 2008 at 11:04 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Jukka Zitting (JIRA) wrote:
> > Why is the scheduler bundle needed? Can't Sling use Quartz directly?
> >
> >
> The scheduler bundle makes scheduling tasks much simpler than directly
> using Quartz; it uses Quartz underneath but provides a simpler api and more
> important uses the whiteboard-pattern to schedule tasks. This allows you to
> write background components that have no dependency to Quartz and only an
> indirect dependency to the scheduler bundle.
ACK, thanks.
> It always makes sense to abstract things like the uses scheduling library;
> this allows to change the implementation without breaking contracts.
Or YAGNI, and adding the abstraction just introduces extra complexity
and potential bugs. Are there potential cases where Quartz wouldn't be
appropriate for a Sling deployment?
I'm just looking at the scheduler code and all I'm seeing is wrapping
around Quartz. If the purpose is to provide a nicer API for
applications, shouldn't we be contributing that as an improvement to
Quartz?
This is just a generic observation, no need to change things that already work.
BR,
Jukka Zitting
Re: [jira] Commented: (SLING-446) Move Scheduling to commons
Posted by Carsten Ziegeler <cz...@apache.org>.
Jukka Zitting (JIRA) wrote:
>
> Why is the scheduler bundle needed? Can't Sling use Quartz directly?
>
The scheduler bundle makes scheduling tasks much simpler than directly
using Quartz; it uses Quartz underneath but provides a simpler api and
more important uses the whiteboard-pattern to schedule tasks. This
allows you to write background components that have no dependency to
Quartz and only an indirect dependency to the scheduler bundle.
It always makes sense to abstract things like the uses scheduling
library; this allows to change the implementation without breaking
contracts.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org