SchedulerFactoryBean no longer sets the job store's `DataSource` when the job store class has been customized

[wilkinsona]

This is a regression in 5.3.13 caused by #27560. It was originally reported as a Spring Boot issue.

[sbrannen]

I agree that this is a regression in terms of effective behavior for the use case described in the Spring Boot issue; however, if the user was previously specifying org.quartz.impl.jdbcjobstore.JobStoreTX and actually wanted to use the JobStoreTX then the application was not working as expected, since Spring previously overrode JobStoreTX with LocalDataSourceJobStore.

Thus, if the user wants to use JobStoreTX, they have to set the DataSource name. Whereas, if they are fine with using Spring's LocalDataSourceJobStore then they should never have specified JobStoreTX to begin with.

I'm not saying we will not revert that the change (that's currently undecided). Rather, I'm pointing out that the user configuration for an explicit job store type was previously (silently) ignored.

@jhoeller, thoughts?

[jhoeller]

From my perspective, let's put a corresponding note into the documentation.

Allowing for custom variants of LocalDataSourceJobStore, picking up the SchedulerFactoryBean-configured DataSource in a custom implementation, was a worthwhile enhancement there in #27560. A specified JobStoreTX does not make sense since it will effectively get overridden with LocalDataSourceJobStore, so such a property entry should get removed entirely or replaced with a org.springframework.scheduling.quartz.LocalDataSourceJobStore value. In other words, I'm not really seeing a valid scenario for the previous dead-entry behavior, whereas the new behavior allows for customizations in advanced scenarios.

[roma2341]

From my perspective, let's put a corresponding note into the documentation.

Allowing for custom variants of LocalDataSourceJobStore, picking up the SchedulerFactoryBean-configured DataSource in a custom implementation, was a worthwhile enhancement there in #27560. A specified JobStoreTX does not make sense since it will effectively get overridden with LocalDataSourceJobStore, so such a property entry should get removed entirely or replaced with a org.springframework.scheduling.quartz.LocalDataSourceJobStore value. In other words, I'm not really seeing a valid scenario for the previous dead-entry behavior, whereas the new behavior allows for customizations in advanced scenarios.

New behaviour is very confusing. I have updated spring-boot-starter-parent and couldn't run my project for several hours because "DataSource name not set" message appeared (And nothing that could help solve the issue). So, maybe this message should be more clear.

[wxz0107]

org.quartz.jobStore.class=org.springframework.scheduling.quartz.LocalDataSourceJobStore

[smpshehan]

@wxz0107 Will that fix the problem? Will it get the spring.datasource as the quartz data source?

[wxz0107]

@wxz0107 Will that fix the problem? Will it get the spring.datasource as the quartz data source?

yes，i use springboot 2.5.7， it work by this configuration

[smpshehan]

Oki, I upgraded to Springboot 2.6.1 and it was failing due to the same error.
So with org.quartz.jobStore.class=org.springframework.scheduling.quartz.LocalDataSourceJobStore
I can start up the springboot app successfully. Now I need to verify that it works as before. Thanks for your suggestion.

[wsdng]

I had the same problem when upgrading from Spring Boot 2.5.6 to 2.6.1.
Using LocalDataSourceJobStore is not an option because in my case the JobStore needs to be clustered.
I've been using the Annotation @QuartzDataSource to identify the dataSource.
When I got an error that the dataSource name is not set, I've added the name by setting property
"spring.quartz.properties.org.quartz.jobStore.dataSource"
This did not solve the problem, because now I got an Exception "There is no DataSource named '...'" although the dataSource bean had been instantiated at this point.
As I understand from the conversation above, there is a workaround to get things right. I would appreciate some more details on this.

[smpshehan]

I use it clustered too.
org.quartz.jobStore.class=org.springframework.scheduling.quartz.LocalDataSourceJobStore
Should take the current spring data source configuration as the jdbc jobStore. That is what I believe.