Open strelchm opened 4 months ago
I can see your pain, but not sure what the solution should be 🤔
You can try @Lazy
annotation when injecting SchedulerClient into your service
If I understand correctly, the problem is this:
ratingService -> scheduler -> tasks -> ... -> ratingService
^
What are these dependencies for?
Why can't it be done like this:
ratingService -> scheduler
someBackgroundWorker -> tasks -> ... -> ratingService
[ v ] I am running the latest version [ v ] I checked the documentation and found no answer [ v ] I checked to make sure that this issue has not already been filed
Probably the symptoms of problem were decribed in this issue but no problem details were discovered
Expected Behavior
No problems in case when task calling service is task creating service. The app starts well
Current Behavior
I have rating service (ratingService) in Spring boot app. This ratingService has method update, that updates the statistic of one user (adding some points). But in the end of this method I need to create task that will recalculate the places of all users according to new rating points of user that have been added (long recalculating of fat table). The new task (recalculateRatingJobTask) calls rating service, but the other method - updateAll. In ratingService the SchedulerClient is injected, in recalculateRatingJobTask the ratingService is injected With default autoconfiguration I get circular reference:
Problem: The problem is connected with com.github.kagkarlsson.scheduler.boot.autoconfigure.DbSchedulerAutoConfiguration. The constructor of bean
contains collection of all tasks that are injected. To avoid the problem and not divide rating service we need to create our own configuration:
in our case we need all features of autoconfiguration and we avoid circular reference with this. But what if the new version of db-scheduler will have changes in this autoconfiguration - we have to change it
What if DbSchedulerAutoConfiguration will be divided to different classes (may be customizers) - in that way we'll have possibility of flexible configuration. Now in other app we have several places of such problem and we decide to divide service classes instead of creating own configuration. And now this is the cause of missunderstandable classes
Steps to Reproduce
Context