@Schedule Annotation

[smillidge]

This annotation would invoke the annotated method using the ManagedScheduledExecutor schedule, scheduleAtFixedRate or scheduleAtFixed delay methods depending on configuration.

Name could be added as a parameter to the annotation to indicate the jndi name of the MSE to use.

If a trigger class is provided the schedule api with trigger would be used.

[aguibert]

I like the idea of having a @Schedule annotation because it will help close gaps between EJB and CDI.

I came up with a working prototype of what this might look like and here is what I came up with:

import javax.enterprise.event.Observes;
import org.aguibert.cdi.timers.Schedule; // proposed new annotation
// ...

public void doStuff(@Observes @Schedule(interval = 3, unit = TimeUnit.SECONDS) Instant now) {
    System.out.println("onSchedule a1  now=" + now);
}

Here is a link to the working code: https://github.com/aguibert/basic-liberty/blob/cdi-timers/src/main/java/org/aguibert/liberty/TestService.java

[codylerum]

Is the intent here to have parity with the EJB version the following would be possible?

public void doStuff(@Observes @Schedule(second = "30", minute = "15", hour = "9", dayOfWeek = "Mon", timezone = "MST7MDT", persistent = true) Instant now) {
...
}

[bmarwell]

Hi!
From a user perspective, it would be a little more convenient to have the schedule annotations at method level instead of the parameter. But having a parameter is not a bad idea, so maybe a second @ScheduledAt Annotation for the parameter?
Either way, thanks for this!

[tkburroughs]

Would we really want full parity with EJB, or perhaps just the more valuable parts. For example, what about:

• persistent? Would the objects that @Schedule may be applied to survive a server restart?
• TimerService? For EJB this provides a way to programmatically create them, but also a way to programmatically find an manage timers
• Multiple @Schedule on a single method? Should each be able to pass a different unique application provided parameter like EJB?
• What exactly would be the scope and lifecycle of the timer? @aguibert prototype above would result in timers per JAX-RS endpoint, so one of those per application lifecycle. If these could be applied to other @ManagedBean types, then would new timers be created every time a new instance of the bean was injected into something? If the bean lifecycle ended, then I assume the timer would need to be automatically destroyed.

[njr-11]

* persistent?  Would the objects that `@Schedule` may be applied to survive a server restart?

If this gets added to Concurrency, I would not recommend trying to accomplish persistent/transactional scheduling in the very first release of it.

[smillidge]

I wouldn't add persistent. This can actually be built on top of the CronTrigger concrete implementation being proposed.

[njr-11]

We could consider allowing a cron-based schedule be specified on the existing Asynchronous annotation, which would provide a convenient way to chain dependent actions to the completion of what is being scheduled.

For example,

@Asynchronous(runAt = @Schedule("0 3 * * MON-FRI America/Chicago"))
CompletionStage<Long> computeDuringOffPeakTimes(...) {
    ...
    if (done)
        return Asynchronous.Result.complete(value);
    else
        return null; // continue running at next scheduled time
}

with usage,

computeDuringOffPeakTimes(params).whenComplete(this::processResult);

Or if we wanted to separate out the cron terms to make them more explicit like EJB does,

@Asynchronous(runAt = @Schedule(hours = "3", daysOfWeek="MON-FRI", zone = "America/Chicago"))
CompletionStage<Long> computeDuringOffPeakTimes(...) {

This would allow for both repeating as well as single-execution scheduling with the simple rule that if you want the scheduled asynchronous method to keep running then leave the completion stage incomplete and return a null value from the method execution. If you instead want it to end, then complete the stage and/or return a non-null stage from the method execution.

[rmannibucau]

My 2cts is that using a non persistent trigger in cdi is plain java without challenge and it does not need an annotation which requires jakarta-config to override the never matching prod hardcoded config and that for other rare cases using a custom impl or quartz integrated with cdi works well so probably something to not copy from ejb.