ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: Using Sling's Scheduler?
Date Thu, 18 Feb 2010 19:46:39 GMT
The "lightweight API" from ACE's point of view could be just the whiteboard pattern:
 - register a Runnable
 - add one or more properties that describe to the scheduler when to invoke the Runnable

I would also prefer the lightweight implementation to be inside ACE for the moment, and to
treat the API we decide on as an "extended" compendium service (in other words, something
we can share amongst OSGi projects).

Greetings, Marcel

On Feb 18, 2010, at 12:42 , Toni Menzel wrote:

> Yep, would like to see a joint effort here as well.
> Just looked at the sling implementation, which is indeed quite
> heavyweight (1mb) but also capable (quartz included).
> After breaking the sling scheduler into api + quatz scheduler (at
> least) it should be simple to provide a third thin implementation that
> comes from ace and does not use quartz (and others).
> Biggest question is if we want to keep the lightweight impl inside ace or not.
> This is mostly because inside ace its much easier to change+adjust
> while things are in development for ace committers.
> Toni
> On Thu, Feb 18, 2010 at 10:40 AM, Carsten Ziegeler <> wrote:
>> Marcel Offermans wrote:
>>> On Feb 18, 2010, at 9:29 , Carsten Ziegeler wrote:
>>>> I just noticed that ACE has its own scheduler. What about using Sling's
>>>> scheduler service instead (this would reduce our code base a little
>>>> bit). The sling scheduler service is a bundle without any other
>>>> dependencies.
>>>> It uses the whiteboard pattern to schedule Runnable services either by a
>>>> cron definition or periodically - so it should be similar to what we
>>>> have in ACE.
>>>> Some basic docs are here:
>>> The ACE scheduler is indeed similar to the one in Sling, so technically it should
be quite easy to replace it, and I would be very much in favor of trying to merge the efforts
(same goes for the ServiceMix scheduler, which Jean-Baptiste suggested, but which I did not
yet look at).
>>> I have two concerns though:
>>> 1) for the target, as part of our management agent, we want a very very lightweight
scheduler, so I would like to settle on an API that can be implemented as lightweight as our
current scheduler.
>>> 2) we need to be able to run this lightweight scheduler on the minimum OSGi execution
environment, because we want our management agent to drop in to any OSGi container (not only
Java 5 SE ones).
>>> So my proposal would be:
>>> a) try to come up with a common scheduler API
>>> b) implement a lightweight version for the target, with minimum EE
>>> c) use the Sling or ServiceMix version on the server (assuming that gives us
additional features that actually add value)
>> Ok, I see your concerns and agree that the sling scheduler is not the
>> best solution for the target then :)
>> What about using the sling scheduler "api" for server and target and we
>> add a lightweight implementation to Sling. We can then use the same
>> "api" and deploy the full version on the server and the light on the target.
>> WDYT?
>> Carsten
>> --
>> Carsten Ziegeler
> -- 
> Toni Menzel
> Independent Software Developer
> Professional Profile:
>     - New Energy for OSS Communities - Open
> Participation Software.

View raw message