Mailing-List: contact issues-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
Date: Sun, 4 Aug 2013 14:47:49 +0000 (UTC)
From: "Amichai Rothman (JIRA)" <jira@apache.org>
To: issues@karaf.apache.org
Message-ID: <JIRA.12514782.1311164489249.166463.1375627669674@arcas>
In-Reply-To: <JIRA.12514782.1311164489249@arcas>
References: <JIRA.12514782.1311164489249@arcas>
Subject: [jira] [Commented] (KARAF-751) Provide a Timer Service in Karaf
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/KARAF-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13728898#comment-13728898 ] 

Amichai Rothman commented on KARAF-751:
---------------------------------------

I'd like to raise a few points for thought:

- the discussion of whether to install SCR by default in karaf is a good one, but perhaps it should be taken to the mailing list or a separate enhancement request, since it is related but not required by the scheduler, and has larger scope that might interest others.

- if the intention is to add a karaf-branded built-in scheduler service, whose current implementation happens to be based on the sling scheduler, we'd want to avoid exposing sling/quarz specifics to the users, which means moving/extending/wrapping the public interfaces, modifying the code to allow the commands/webconsole to access some internal data which is currently unexposed, maybe removing dependency on sling threadpools (or wrapping that too), and converting the SCR annotations to blueprint or a raw BundleActivator if SCR won't be installed by default. The point being that it's not only about SCR, but maintaining a set of patches and featuers for proper karaf integration, one of which might be avoiding SCR.

- it's possible we'll be able to push some of these patches upstream if they are interested (using raw OSGi API instead of SCR, exposing an admin-ish interface for commands, etc.)

- if the intention is to use the sling scheduler 'as-is', i.e. just supplying the upstream bundle with no special karaf integration, then we can just close this issue with a comment recommending sling scheduler to whomever needs a scheduler (and they can install SCR too if needed). I don't see the advantages of installing it by default in this case.

- Sling's scheduler is quite a small package with just a handful of classes or so (have a look!), so it may be ok to just use it as a starting point but let it diverge and maintain the karaf module independently and let it grow with the karaf-specific requirements and features, without worrying about upstream maintenance, dependencies etc.

While everyone's comments above make sense, they focus mostly on the SCR part and I'm not sure which of these paths for the whole package you're voting for :-)

                
> Provide a Timer Service in Karaf
> --------------------------------
>
>                 Key: KARAF-751
>                 URL: https://issues.apache.org/jira/browse/KARAF-751
>             Project: Karaf
>          Issue Type: New Feature
>          Components: karaf-osgi
>    Affects Versions: 3.0.0
>            Reporter: Ioannis Canellos
>            Assignee: Ioannis Canellos
>             Fix For: 3.1.0
>
>         Attachments: Scheduler_20130430.patch, Scheduler_20130802.patch
>
>
> In many cases there is need to have recurring tasks run for a period of time.
> It would be great if Karaf provided some short of a TimerService that would allow the user to easily schedule task execution.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira