Enviado.
El 18/02/2010, a las 21:19, Mari <[email protected]> escribió:
Dear Toni. I leve in Argentina, i Dont speak english, please remove
me your Mail list. Thanks! Mari.
Enviado.
El 18/02/2010, a las 15:46, Marcel Offermans <[email protected]
> escribió:
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 <[email protected]
> 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
[email protected]
--
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
[email protected]
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
