Add endpoint for scheduled task information

[htynkn]

Some of our team projects are using many scheduled task, so we custom one endpoint to list four different type of scheduled tasks.

Not sure if there is what issue #8831 is looking for, but at least I think it's a good start if any one want to add more information in this endpoint.

This is a example response:

[philwebb]

This looks super nice. Thanks.

[wilkinsona]

Thank you, @htynkn.

Per #7648, when it becomes time to merge this, we should change the format of the response so that it returns a map rather than a list.

@htynkn No need to make that change now. I just wanted to make a note of it while I remembered. The Actuator is going to be reworked to support WebFlux in M3 so there may be other adjustments required once that's been done.

[snicoll]

Also, we don't have an explicit support for @EnableScheduling in Spring Boot but we do for Quartz so we need to figure out how to handle that situation.

[WispY]

If you switch interval and initialDelay to java.lang.Long, then you can avoid unnecessary zeroes in the response for CRON tasks.

Before:

[
    {
        "Type": "CRON",
        "Interval": 0,
        "InitialDelay": 0,
        "Name": "public void com.foo.Bar.update()",
        "Expression": "0 */5 * * * *",
        "Trigger": "CronSequenceGenerator: 0 */5 * * * *"
    }
]

After:

[
    {
        "Type": "CRON",
        "Name": "public void com.foo.Bar.update()",
        "Expression": "0 */5 * * * *",
        "Trigger": "CronSequenceGenerator: 0 */5 * * * *"
    }
]

[wilkinsona]

Thanks for the suggestion, @WispY. I think this will be taken care of when we rework the format of the response to return a map rather than an array. I imagine that we'll use the task types as keys and arrays of tasks of a particular type as the values.

[php-coder]

Looks like this comment is placed on the wrong method and should be on constructor.

[php-coder]

With so long method, usage of stream and map looks like of abusing such functionality IMHO.

[php-coder]

I suspect that it's impossible that the task is the IntervalTask and CronTask and TriggerTask at the same time. In this case, it's better to use if-else if-else if.

[php-coder]

This comment has details that is obvious and that can be changed in a future and will make this comment outdated. Also as a user who will read the API docs I don't need to know how many types here, because I can count them by myself.

[php-coder]

Returning Optional here didn't make the code simpler IMHO. For me, reading something like the following would be more readable

assertThat(fixedRateTask).isNotNull();
assertThat(fixedRateTask.getInterval()).isEqualTo(2000);
assertThat(fixedRateTask.getInitialDelay()).isEqualTo(0);

than we we have now:

assertThat(fixedRateTaskOptional.isPresent()).isTrue();
assertThat(fixedRateTaskOptional.get().getInterval()).isEqualTo(2000);
assertThat(fixedRateTaskOptional.get().getInitialDelay()).isEqualTo(0);

[php-coder]

NPE will be thrown here if runnable is null.

[wilkinsona]

Having looked a little more closely, I'm not keen on how the configurer is being used here. In addition to the callback not really being used as intended, there's also an ordering issue that means tasks may be missed. I've opened SPR-15982 to see if Spring Framework can provide a supported API for retrieving the registered tasks. I'll place this on hold until we see the outcome of that Framework issue.

[wilkinsona]

The proposed Framework changes are now targeted at 5.0.1. Pushing back to M6.

[wilkinsona]

The proposed Framework changes are now targeted at 5.0.2. Pushing back to RC1.

[wilkinsona]

Thanks for the PR. Unfortunately, with the changes to the endpoint infrastructure and the improvements coming in Spring Framework 5.0.2 for accessing scheduled tasks, this isn't the approach that we want to take to implement this. Thanks anyway.