Spring / SpringBoot integration

[pnowy]

Hi Gustav,

first of all nice work!

Did you consider to prepare separate module (ie. db-scheduler-spring) which provide seamless integration with Spring/Spring Boot?

I was thinking about that a little bit and I think that kind of option could help library gain more popularity. From my perspective what needs to be done to do that:

• prepare Spring Boot autostarter which creates the table and initialize all required beans
• provide the option to to declare task to execute as Spring managed beans so executed task will be retrieved from context and run (in order to that task should implement specific task interface)
• the cron jobs support would be also good for that (but I've seen task for it)

Are you open to that integration? What do you think about that?

[kagkarlsson]

Hi!

Sure I think that sounds like a good idea provided it does not require too many changes to the core db-scheduler code. I have so far tried to avoid a multi-module project, but this might require it, unless we maintain it in a separate project db-scheduler-addons (or something like that)

[kagkarlsson]

Is this something you would be willing to contribute to?

[pnowy]

Yes, that's my plan but I was thinking about separate module for spring - not something like addons. From my perspective it works quite good. I have similar project and using there that approach: https://github.com/pnowy/NativeCriteria

I have some core and spring if someone wants to use direct integration (but I'm also not a big fan of multimodules projects but less than 5 it's ok for me).

[kagkarlsson]

Yeah multi-module is probably the best option. Slighty painful to have to go for a multi-module project structure (increased complexity), but I see no way around it if we want to offer different "flavors" of the lib..

[kagkarlsson]

So either

db-scheduler/
    db-scheduler-core/
    db-scheduler-spring/

or

db-scheduler/
    core/
    spring/

[pnowy]

I would prefer first option.

The official spring project (https://github.com/spring-projects/spring-framework) has that library part on module name like spring-something so I think db-scheduler-core, etc. will be ok (I always trying to copy patterns from good and popular projects).

[kagkarlsson]

You make a good point :). Not super-happy with the core part, so maybe like guava

db-scheduler/
    db-scheduler/       (for better main-dependency naming)
    db-scheduler-spring/

[kagkarlsson]

Anyway, that can be tuned later. Would be super-happy for contributions!

[kagkarlsson]

Will probably work on cron and prometheus-metrics for a time myself.

[pnowy]

Personally I would use db-scheduler-core to indicate that this is most important part of app but it's always personal preference 😄

[cash1981]

Great idea. Would like to see this happen myself. If there is something I can help with, then I can contribute.

[kagkarlsson]

If someone could post some code-example for this would look that would be helpful :). I am unfortunately not very familiar with Spring Boot..

[pnowy]

@kagkarlsson I will try to prepare some kind of initial PR but I had very busy March so I hope that on April I will find a time. My plan is to prepare typical autostarter for Spring Boot - similar like other libraries using it (you are adding single dependency and everything works out-of-the-box).

[kagkarlsson]

Ok, great!

[pnowy]

@kagkarlsson I was looking on the Spring Boot integration / tested it and I have some questions / issues to discuss about the vision of that integration.

Regarding my plan:

• the Scheduler object will be created by specific factory bean which read the application properties and setup the scheduler according to available scheduler configuration options and will be exposed as Scheduler global bean available in app context
• I prepared the liquibase migration but I assume that won't be a part of auto-configuration, users are using different tools to schema migration and I think the best option is keep it out of the auto-configuration (and they could always add liquibase migration or sql script to their specific schema migration tool if they want to)

The main area to discuss is about task registration. According to the code and documentation I see currently there is no option to register task dynamically after scheduler configuration (they need to be pointed during schedule on create method) - is that correct?

Because I was thinking to prepare the scheduler bean and after that user could inject it somewhere and add additional task configuration (task registrations, etc.). Of course there is an option to provide that configurations by some kind of Supplier/Provider bean which should be prepared before scheduler init by the user but I think user should have an option to register/deregister the tasks with fully initialized scheduler. Is it available - did I miss some part of API?

Second option which I consider are some kind of tasks defined as spring beans (except manual registration which could be second option). The Spring users often want to have the option to inject into tasks other beans/components and have context support so we could define some kind of interfaces (and/or abstract classes) where user could implement it (like VoidExecutionHandler, DeadExecutionHandler, etc.) and during context initialization we could scan the context for that kind of beans, retrieve them and register the tasks for them (with annotation support for scheduling: cron, fixed delay, etc. ). The case is that during execution we will need to retrieve these beans from context and run specific methods on them (in order to execute the real beans on the spring context like Quartz which has Job interface for it) so probably we will need some kind of proxy task which deal with it and will be a bridge between spring context and scheduler.

What do you think about those ideas? @cash1981 if you have any other suggestion it would be great if you could put them here also.

@kagkarlsson another question - is there an option of task history? I mean when I register one time task I've noticed that task disappear from scheduler table. Is there a way to keep them after execution but with some executed marker or move them to some kind of history table? Thanks

[kagkarlsson]

Initial thought. If possible I would like to avoid having to support dynamic register/deregister of tasks (just to avoid some complexity). So ideally, all tasks are available when the Scheduler is created. Having them as spring beans makes sense as you say, because the often have dependencies.

Also a good idea to have some lightweight annotations where you simply annotate actual execution-handler (for example VoidExecutionHandler) as you say (@RecurringTask(name = "send-emails", cron="...."))

I have chosen not to support history of executions mostly because I wanted a single database-table that should not get bloated over time. It is possible to create hooks that write the execution to another table on completion, but it would have to go into another module, or at least be an opt-in option

[evenh]

I've started the module restructuring at my fork. Hopefully I'll be able to start working on the integration itself now and then during the summer @pnowy. Let me know if you're interested in committer access!

[pnowy]

@evenh -sure - please add my. I will take a look at my free time and will try to help.

[evenh]

Check your inbox @pnowy :-)

[pnowy]

Received. Thx!

[kagkarlsson]

Part of this issue was implemented by PR #63. We decided not to implement the annotation-variants for now (@RecurringTask(name = .., cron = ...) etc), because I am not sure they are actually needed. If there is demand for it, please raise another issue and we'll discuss it :)

[kagkarlsson]

Released in 6.0. Closing.