Prior to this commit, only cron @Scheduled tasks can be disabled with the special cron expression value that indicates a disabled trigger: "-".

This commit enables this configuration to fixedDelay and fixedRate @Scheduled tasks.

Fixes gh-28073

Comment From: snicoll

@Leewei222 can you share how this is fixing #28073? The issue there is rather a disable switch in testing scenario. Your proposal would require to change the underlying annotation. Also - for fixedDelay and fixedRate looks quite strange to me.

Comment From: Leewei222

Hi @snicoll, thanks for the feedback.

The scheduled jobs are usually configured with property place holders. In some environments, we want to disable some of the schedulers. For cron scheduled job, this can easily be done by the following code 

@Scheduled(cron = "${cron}")
 public void scheduleTaskWithCron() {
     // do something
}

// application.properties
cron=-

However, this cannot work for fixedDelay and fixedRate scheduled tasks. I think there should be an easy way for us to disable them too! My proposal can disable them with the following code

@Scheduled(fixedDelayString= "${fixedDelay}")
 public void scheduleTaskWithFixedDelay() {
     // do something
}

@Scheduled(fixedRateString= "${fixedRate}")
public void scheduleTaskWithFixedRate() {
     // do something
}

// application.properties
fixedDelay=-
fixedRate=-

If - for fixedDelay and fixedRate doesn't make sense, what about using negative number?

Comment From: snicoll

OK that explains the use case. I don't think this actually fixes #28703, or at least not directly so let's discuss the merit of this one regardless.

If - for fixedDelay and fixedRate doesn't make sense, what about using negative number?

Both fixedDelay and fixedRate are actually numbers already with a convenience String-based attribute counter part. The default value for the long-based ones is already -1 to indicate that the value should not be taken into account. We can't unfortunately reuse this to signal something else.

If you want to disable some of the schedulers, I'd rather use a @Profile to prevent the scheduled bean to be exposed in the context at all. This should require some code refactoring but I believe this will for the better and more explicit than what you were suggesting.

Thanks for the PR, in any case!