@Target(value=TYPE) @Retention(value=RUNTIME) @Import(value=SchedulingConfiguration.class) @Documented public @interface EnableScheduling
<task:*> XML namespace. To be used
on @Configuration classes as follows:
@Configuration
@EnableScheduling
public class AppConfig {
// various @Bean definitions
}
This enables detection of @Scheduled annotations on any Spring-managed
bean in the container. For example, given a class MyTask
package com.myco.tasks;
public class MyTask {
@Scheduled(fixedRate=1000)
public void work() {
// task execution logic
}
}
the following configuration would ensure that MyTask.work() is called
once every 1000 ms:
@Configuration
@EnableScheduling
public class AppConfig {
@Bean
public MyTask task() {
return new MyTask();
}
}
Alternatively, if MyTask were annotated with @Component, the
following configuration would ensure that its @Scheduled method is
invoked at the desired interval:
@Configuration
@EnableScheduling
@ComponentScan(basePackages="com.myco.tasks")
public class AppConfig {
}
Methods annotated with @Scheduled may even be declared directly within
@Configuration classes:
@Configuration
@EnableScheduling
public class AppConfig {
@Scheduled(fixedRate=1000)
public void work() {
// task execution logic
}
}
By default, will be searching for an associated scheduler definition: either
a unique TaskScheduler bean in the context,
or a TaskScheduler bean named "taskScheduler" otherwise; the same lookup
will also be performed for a ScheduledExecutorService
bean. If neither of the two is resolvable, a local single-threaded default
scheduler will be created and used within the registrar.
When more control is desired, a @Configuration class may implement
SchedulingConfigurer. This allows access to the underlying
ScheduledTaskRegistrar instance. For example, the following example
demonstrates how to customize the Executor used to execute scheduled
tasks:
@Configuration
@EnableScheduling
public class AppConfig implements SchedulingConfigurer {
@Override
public void configureTasks(ScheduledTaskRegistrar taskRegistrar) {
taskRegistrar.setScheduler(taskExecutor());
}
@Bean(destroyMethod="shutdown")
public Executor taskExecutor() {
return Executors.newScheduledThreadPool(100);
}
}
Note in the example above the use of @Bean(destroyMethod="shutdown").
This ensures that the task executor is properly shut down when the Spring
application context itself is closed.
Implementing SchedulingConfigurer also allows for fine-grained
control over task registration via the ScheduledTaskRegistrar.
For example, the following configures the execution of a particular bean
method per a custom Trigger implementation:
@Configuration
@EnableScheduling
public class AppConfig implements SchedulingConfigurer {
@Override
public void configureTasks(ScheduledTaskRegistrar taskRegistrar) {
taskRegistrar.setScheduler(taskScheduler());
taskRegistrar.addTriggerTask(
new Runnable() {
public void run() {
myTask().work();
}
},
new CustomTrigger()
);
}
@Bean(destroyMethod="shutdown")
public Executor taskScheduler() {
return Executors.newScheduledThreadPool(42);
}
@Bean
public MyTask myTask() {
return new MyTask();
}
}
For reference, the example above can be compared to the following Spring XML configuration:
<beans>
<task:annotation-driven scheduler="taskScheduler"/>
<task:scheduler id="taskScheduler" pool-size="42"/>
<task:scheduled-tasks scheduler="taskScheduler">
<task:scheduled ref="myTask" method="work" fixed-rate="1000"/>
</task:scheduled-tasks>
<bean id="myTask" class="com.foo.MyTask"/>
</beans>
The examples are equivalent save that in XML a fixed-rate period is used
instead of a custom Trigger implementation; this is because the
task: namespace scheduled cannot easily expose such support. This is
but one demonstration how the code-based approach allows for maximum configurability
through direct access to actual componentry.
Note: @EnableScheduling applies to its local application context only,
allowing for selective scheduling of beans at different levels. Please redeclare
@EnableScheduling in each individual context, e.g. the common root web
application context and any separate DispatcherServlet application contexts,
if you need to apply its behavior at multiple levels.
Scheduled,
SchedulingConfiguration,
SchedulingConfigurer,
ScheduledTaskRegistrar,
Trigger,
ScheduledAnnotationBeanPostProcessor