This is a regression in 5.3.13 caused by https://github.com/spring-projects/spring-framework/pull/27560. It was originally reported as a Spring Boot issue.

Comment From: 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?

Comment From: 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.

Comment From: 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.

Comment From: wxz0107

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

Comment From: smpshehan

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

Comment From: 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

Comment From: 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.

Comment From: 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.

Comment From: 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.

Comment From: wsdng

I've got it running now. I still have the jobStore properties isClustered and driverDelegateClass in place but removed the jobStore.class.

The thing that confused me in the first place was the Quartz documentation for clustering: "Clustering currently only works with the JDBC-Jobstore (JobStoreTX or JobStoreCMT)". I did not recognize that LocalDataSourceJobStore was a class provided by spring as a replacement for JobStoreTX and JobStoreCMT. Thank you for the clarification.

Comment From: dmytro-dobrovolskyi

Spent a lot of time on this... Apparently, if you want @QuartzDataSource to work you need to make your other dataSource (if you have one) as @Primary which is kinda implied in javadoc but it is not clear that you really have to mark it as primary.

Comment From: jeoningu

I modified the QuartzConfiguration file and it works normally. Why is that?

  1. remove @EnableAutoConfiguration, @QuartzDataSource
  2. change the quartzDataSource method name to aa and set it to @Bean (name="aa")

It's my opinion! 1. DataSource objects are registered as spring beans even without @EnableAutoConfiguration

  1. Even if there is no @QuartzDataSource and the spring bean name is not quartzDataSource, by some internal action Quartz JobStore finds the dataSource spring bean and makes a db connection

If my opinion is correct, can you explain the inner action of number 2 in detail?