Hi!
See https://issues.apache.org/jira/browse/KARAF-751 for the details...
Regards,
Lukas
--
View this message in context:
http://karaf.922171.n3.nabble.com/Task-scheduler-in-Karaf-tp4028481p4028537.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
in context:
http://karaf.922171.n3.nabble.com/Task-scheduler-in-Karaf-tp4028481p4028537.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
More than a year ago Ioannis Canellos posted that he added a rudimentary
scheduler as a new module to trunk. (See
http://karaf.922171.n3.nabble.com/Introducing-a-task-scheduler-in-Karaf-td3185322.html
for details)
In the following discussion some people suggested to use Quartz
-scheduler-in-Karaf-td3185322.html
for details)
In the following discussion some people suggested to use Quartz and/or the
scheduler implementation from Apache Sling (which already uses Quartz). As
the Apache Sling implementation only implements support for SCR and not
Blueprint it's unfortunately
scheduler as a new module to trunk. (See
http://karaf.922171.n3.nabble.com/Introducing-a-task-scheduler-in-Karaf-td3185322.html
for details)
In the following discussion some people suggested to use Quartz
and/or the
scheduler implementation from Apache Sling (which already uses
Quartz
-Ursprüngliche Nachricht-
Von: j...@nanthrax.net [mailto:j...@nanthrax.net]
Gesendet: Mittwoch, 24. April 2013 15:18
An: dev@karaf.apache.org
Betreff: Re: Task scheduler in Karaf
Hi,
The scheduler provided by Ioannis has been included in 3.0.0.RC1.
Before the 3.0.0.GA release (or 3.1.0
As we are marching towards 3.0.0 release and we haven't done anything about
it (its still in primitive state) maybe its a good idea to remove it from
trunk and maybe put it in the sandbox or something.
What do you think?
--
*Ioannis Canellos*
*
FuseSource http://fusesource.com
**
Blog:
Rescheduling it for 3.1.0 would be acceptable.
As to removing the code from trunk, would it make the most sense to
temporally retreat it, then bring it back into the 3.1.0 branch once
created?
Jamie
On Wed, Dec 7, 2011 at 11:25 AM, Ioannis Canellos ioca...@gmail.com wrote:
As we are marching
Yes, I was thinking something like this.
--
*Ioannis Canellos*
*
FuseSource http://fusesource.com
**
Blog: http://iocanel.blogspot.com
**
Apache Karaf http://karaf.apache.org/ Committer PMC
Apache Camel http://camel.apache.org/ Committer
Apache ServiceMix http://servicemix.apache.org/
I'm not sure if it's really worth to use quartz here. Still I think we
shouldn't start implementing things before there is actually a use case for
it (at least I'm happy right now with the classical timer support :)).
Quartz can also work with the new Java 6 scheduling interface -- we can
upgrade
Ok.
What then I think a couple of commands on top of the sling service
would do the trick. The extender part can be added on top of that
too, but that's a different area imho.
On Mon, Jul 25, 2011 at 16:08, Ioannis Canellos ioca...@gmail.com wrote:
I guess the part I'm still missing is the
On Wed, Jul 20, 2011 at 4:00 PM, Ioannis Canellos ioca...@gmail.com wrote:
I am glad that I see so much interest in it.
It would make sense to use quartz instead of Java Timer mostly due to the
fact that quartz supports thread pooling while timers don't. So, I think
that it would be a good
The JDK Timer is kinda @deprecated in favor of the
ScheduledExecutorService in Java5+.
The latter supports thread pooling.
Thanks Claus for bringing this up. For me this is enough. If you think that
we should still use quartz to take advantage of features like persistence,
clustering etc,
Well, honestly, I'm not sure it's really worth the pain if the goal is
simply to avoid using
Executors.newSingleThreadScheduledExecutor().schedule(runnable,
delay, TimeUnit.MILLISECONDS)
If there's a need to manage recurrent tasks, we need to have a full
featured engine for that and have a
Do you think that it worths using quartz instead?
On Friday, July 22, 2011, Guillaume Nodet gno...@gmail.com wrote:
Well, honestly, I'm not sure it's really worth the pain if the goal is
simply to avoid using
Executors.newSingleThreadScheduledExecutor().schedule(runnable,
delay,
Hi,
I added a new module to Karaf. The purpose of this module is to provide
means for scheduling tasks through the osgi service registry.
The scheduler module registers a ServiceListener that listens for services
of the java.lang.Runnable interface that also have 2 service properties that
are
I've not looked at it but I believe apache sling has a scheduling service
that wraps quartz already.
Would it worth while extracting that to a common service both karaf and
sling could share?
Mark
-- Sent from an Android.
On 21/07/2011 12:49 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote:
Hi
Pardon me for piping in (I know just enough to be dangerous ;), but was
there any reinventing of the wheel in your commit, Ioannis, that could
be avoided by closer integration with the Quartz Scheduler (already
Apache-licensed and famous: http://www.quartz-scheduler.org/)--not just
the
Hi Ioannis,
This is an excellent idea and could be very helpful for pure java
project requiring scheduler like Quartz on Karaf platform. As
Camel/ActiveMQ already uses Quartz like plenty of Java projects, that
will be a very nice feature to deploy jobs on the platform.
Regards,
Charles
I am glad that I see so much interest in it.
It would make sense to use quartz instead of Java Timer mostly due to the
fact that quartz supports thread pooling while timers don't. So, I think
that it would be a good idea to replace Timers with Quartz.
@Glenn: No problem with peeping. We actually
20 matches
Mail list logo
