ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toni Menzel <t...@okidokiteam.com>
Subject Re: Using Sling's Scheduler?
Date Thu, 18 Feb 2010 11:42:18 GMT
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 <cziegeler@apache.org> 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:
>>> http://sling.apache.org/site/scheduler-service-commons-scheduler.html
>>
>> 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
> cziegeler@apache.org
>



-- 
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
toni@okidokiteam.com
http://www.ops4j.org     - New Energy for OSS Communities - Open
Participation Software.

Mime
View raw message