Manuel Jordan opened SPR-16852 and commented
The following is not critical, but
I have:
@Configuration
@EnableScheduling
public class SchedulingConfig implements SchedulingConfigurer {
private static final Logger logger = LoggerFactory.getLogger(SchedulingConfig.class.getSimpleName());
@Override
public void configureTasks(ScheduledTaskRegistrar taskRegistrar) {
taskRegistrar.setScheduler(taskScheduler());
}
@Bean(destroyMethod="shutdown")
public TaskScheduler taskScheduler() {
logger.info("taskScheduler method executed ...");
ThreadPoolTaskScheduler threadPoolTaskScheduler = new ThreadPoolTaskScheduler();
threadPoolTaskScheduler.setPoolSize(4);
threadPoolTaskScheduler.setThreadNamePrefix("scheduler-");
return threadPoolTaskScheduler;
}
}
When SchedulingConfig is scanned only for the RootApplicationContext (and known that the ServletApplicationContext must be able to use/access the RootApplicationContext beans) my @Components working with @Schedule in the ServletApplicationContext does not work.
The current solution is scan SchedulingConfig from the ServletApplicationContext
Thus seems mandatory scans twice this SchedulingConfig from the RootApplicationContext (consider a batch process where web is not involved) and ServletApplicationContext (consider Websocket, sending messages to a JMS destination, working SimpMessagingTemplate )
It is similar than (prior when to be fixed of course):
I am assuming this situation would be the same or reflected for a @Configuration class working with @EnableAsync
Affects: 4.3.17, 5.0.5
Issue Links:
Referenced from: commits b39ce80, 5935b7a
Backported to: 4.3.18
Manuel Jordan opened SPR-16852 and commented
The following is not critical, but
I have:
When
SchedulingConfigis scanned only for theRootApplicationContext(and known that theServletApplicationContextmust be able to use/access theRootApplicationContextbeans) my@Componentsworking with@Schedulein theServletApplicationContextdoes not work.The current solution is scan
SchedulingConfigfrom theServletApplicationContextThus seems mandatory scans twice this
SchedulingConfigfrom theRootApplicationContext(consider a batch process where web is not involved) andServletApplicationContext(considerWebsocket, sending messages to aJMSdestination, workingSimpMessagingTemplate)It is similar than (prior when to be fixed of course):
I am assuming this situation would be the same or reflected for a
@Configurationclass working with@EnableAsyncAffects: 4.3.17, 5.0.5
Issue Links:
@EnableAspectJAutoProxyneeds to be redeclared for each application contextReferenced from: commits b39ce80, 5935b7a
Backported to: 4.3.18