Consider making ScheduleRecurringOnStartup and ScheduleOnceOnStartup public

[hw-knowit]

In my Spring Boot project I have tasks that are classes inheriting from a shared BaseTask class. One of these tasks may be either run just once or run on a schedule and so I want my BaseTask to be able to handle both (instead of having to create separate tasks that inherit from RecurringTask or OneTimeTask).

Additionally, I want to register a recurring instance of this task to run on startup using the @Bean annotation provided by the Spring Boot starter. However, for the scheduler to register this recurring task on startup the task needs an onStartup implementation. Looking at the implementation in RecurringTask I see that there is a ScheduleRecurringOnStartup helper class with a lot of logic that I would not want to implement and maintain myself. Why isn't this class public but only exposed through RecurringTask?

I realize that there are two possible workarounds: Inherit from RecurringTask or use Tasks.recurring. None of these map very cleanly to what I'm trying to achieve: I want my task to be able to work as both a OneTimeTask and a RecurringTask, and I don't want my task implementations to live in a lambda.

---

An approximation of my ideal setup:

class BaseTask(schedule: Schedule? = null) : AbstractTask(...), OnStartup {
    override fun onStartup(...) {
        if (schedule = null) return

        // Or instantiate in constructor. Could include handling for onStartup with non-recurring tasks.
        ScheduleRecurringOnStartup("recurring", null, schedule).apply(...)
    }
}

class Mytask(...) : BaseTask(...) {}

@Bean
fun myRecurringTask() = MyTask(Schedules.cron("*/10 * * * * ?"))

@Bean
fun myOneTimeTask() = MyTask() // Not run on startup, but is registered in scheduler

---

I suggest making these helpers public to be able to mimic OneTimeTask and RecurringTask cleanly with a class-based approach without having to (re-)implement advanced scheduling logic.

[kagkarlsson]

I agree that you should not duplicate that logic. Not sure what the best solution is though. What are you doing in the BaseTask that you do not want to duplicate?

[hw-knowit]

Extra logging / instrumentation / helper methods / default handling of whatever inherited from base task. One place to define task names and such for the AbstractTask constructor. In my app I have inverted the scheduling flow so that each task class can schedule itself which I vastly prefer as a usage pattern: MySuperTask.scheduleOrThrow(domainObjectThatDeterminesInstanceId, data, Duration.ofSeconds(10)). This is implemented in a shared superclass. All of my tasks use a recurrence scheme where the schedule is passed along with task data and the task reschedules itself as/if needed based on execution status.

I'm sure there are other examples of useful stuff to implement in a BaseTask. The only missing piece for me is graceful onStartup handling which I currently cannot support for BaseTask unless I implement it myself.

[hw-knowit]

Since OnStartup and ScheduleOnStartup are already public, it seems to me almost an oversight that ScheduleOnceOnStartup and ScheduleRecurringOnStartup aren't? I don't imagine I need anything more complicated than having those classes be public so I can implement OnStartup in BaseTask similar to the suggestion in my original post.

I might be able to figure out a schedule-once flow myself, but the handling of preexisting executions / disabled schedules and whatnot happening in the schedule-recurring flow I would rather not deal with.