Quartz 2.2.1整合Spring 4.3.8调用服务异常问题求助

Hey there, let's dig into the common pitfalls you might be hitting here—since you've already wired up Spring-Quartz integration via beans and added the QuartzInitializerListener in web.xml, but are running into issues when calling your REST services. Here are the most likely culprits and fixes:

The biggest red flag here is using both Spring's SchedulerFactoryBean and the QuartzInitializerListener from web.xml.

The listener spins up its own independent StdSchedulerFactory instance, while Spring's SchedulerFactoryBean manages a separate Quartz scheduler tied to your Spring context. This dual setup causes resource conflicts, prevents Spring-managed beans from being injected into Quartz jobs, and can destabilize your entire app (including REST service calls).

Fix:
Remove the QuartzInitializerListener entry from web.xml entirely. Let Spring handle Quartz initialization through SchedulerFactoryBean—it already encapsulates all the setup the listener does, plus integrates with your Spring context. Here's a robust example configuration:

@Bean
public SchedulerFactoryBean schedulerFactoryBean(DataSource dataSource, ApplicationContext appContext) {
    SchedulerFactoryBean scheduler = new SchedulerFactoryBean();
    scheduler.setDataSource(dataSource);
    
    // Enable Spring bean injection for Quartz jobs
    AutowiringSpringBeanJobFactory jobFactory = new AutowiringSpringBeanJobFactory();
    jobFactory.setApplicationContext(appContext);
    scheduler.setJobFactory(jobFactory);
    
    // Point to your Quartz properties file (if you have one)
    scheduler.setConfigLocation(new ClassPathResource("quartz.properties"));
    
    // Delay startup to let Spring finish initializing REST services first
    scheduler.setStartupDelay(5);
    return scheduler;
}

If your REST calls are failing with serialization errors, Quartz classes (like JobDetail or Trigger) might be accidentally getting picked up by Jackson's message converters. This happens if your Jersey configuration scans too broad a package range, or if Quartz beans leak into the request/response flow.

Fix:
Narrow down your Jersey resource scanning to only your REST controller packages, and configure Jackson to ignore Quartz-specific classes/fields:

@Bean
public ObjectMapper objectMapper() {
    ObjectMapper mapper = new ObjectMapper();
    // Ignore all classes under the Quartz package
    mapper.registerModule(new SimpleModule()
        .setMixInAnnotation(org.quartz.Job.class, IgnoreQuartzMixin.class));
    return mapper;
}

@JsonIgnoreType
abstract class IgnoreQuartzMixin {}

If your scheduled jobs depend on Spring-managed beans (like services or repositories), failing to wire them correctly can cause runtime NPEs that ripple through your app and break REST calls.

Fix:
Use the AutowiringSpringBeanJobFactory from the first example, or make your job class implement ApplicationContextAware to fetch beans directly:

public class MyScheduledJob implements Job, ApplicationContextAware {
    private static ApplicationContext springContext;
    private MyService myService;

    @Override
    public void execute(JobExecutionContext context) throws JobExecutionException {
        // Lazy-load the service if not already injected
        if (myService == null) {
            myService = springContext.getBean(MyService.class);
        }
        myService.runScheduledTask();
    }

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        springContext = applicationContext;
    }
}

If Quartz starts before Spring finishes initializing your REST services, you might see race conditions where jobs trigger before your API is ready, or Quartz can't access critical Spring beans.

Fix:
Add a startupDelay to your SchedulerFactoryBean (as shown in the first example) to give Spring time to deploy your Jersey endpoints and initialize all necessary beans before Quartz starts scheduling jobs.

内容的提问来源于stack exchange，提问作者MarcelloGarini