ScheduledTaskRegistrar to provide all scheduled tasks with getScheduledTasks() [SPR-16424]

[spring-projects-issues]

Daniel Moses opened SPR-16424 and commented

ScheduledTaskRegistrar.getScheduledTasks() only gives a set of all tasks that were registered before bean creation (it gets populated afterPropertiesSet). The following methods don't keep the scheduled task set up to date: addCronTask, scheduleCronTask, etc.

This easily tested by creating a simple spring boot with actuator application and the following configuration/properties. (spring-boot 2.0.0.M7)

@Configuration
@EnableScheduling
public class TaskConfig implements SchedulingConfigurer {
public void runTask() {}
@Override
public void configureTasks(ScheduledTaskRegistrar taskRegistrar) {
taskRegistrar.scheduleCronTask(new CronTask(this::runTask, "0 0/1 * * * ?"));
}
}

properties:

management.endpoint.scheduledtasks.enabled=true
management.endpoints.web.expose=info,status,scheduledtasks

Also of concern is that the list of tasks are not filtered if they were canceled.

---

Affects: 5.0.2

Issue Links:

• Provide read access to the scheduled tasks at runtime [SPR-15982] #20532 Provide read access to the scheduled tasks at runtime

[spring-projects-issues]

Juergen Hoeller commented

In turns out that this works as designed: ScheduledTaskRegistrar.getScheduledTasks() is only meant to expose locally registered tasks, as managed by the lifecycle of the registrar instance itself, also to be cancelled on shutdown of the registrar.

The add* methods are local properties of the registrar and don't have any effect after afterPropertiesSet. And the schedule* methods return an independent ScheduledTask, leaving its lifecycle - and also its exposure through ScheduledTaskHolder.getScheduledTasks() - up to the caller. For SchedulingConfigurer purposes, you'll typically just want to call the add* methods, unless you're prepared to manage the lifecycle of specific tasks in a custom fashion.

A design note: ScheduledTaskRegistrar unfortunately serves several purposes, making its API design a bit convoluted. Being a user-definable registrar component but also a backend to ScheduledAnnotationBeanPostProcessor leaves some subtle semantics up to be discovered.