TaskSchedulingAutoConfiguration prevents discovery of ScheduledExecutorService

[lukas-krecan-lt]

We are using DelegatingSecurityContextExecutorService to handle security annotatons in our scheduled tasks. It used to work before upgrading to Spring Boot 2.1.0 since ScheduledAnnotationBeanPostProcessor uses ScheduledExecutorService if it can not find any bean of type TaskScheduler.

TaskSchedulingAutoConfiguration introduced in 2.1.0 creates a default TaskScheduler if there is none, which makes ScheduledAnnotationBeanPostProcessor ignore our ScheduledExecutorService.

    @Bean
    // Ignored since Spring Boot 2.1.0
    public ScheduledExecutorService scheduler() {
        SecurityContext securityContext = SecurityContextHolder.createEmptyContext();
        securityContext.setAuthentication(new AuthenticatedUser(loggedInUser, "root"));

        ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(10);

        return new DelegatingSecurityContextScheduledExecutorService(scheduledExecutorService, securityContext);
    }

[lukas-krecan]

Seems to be related #15038

[philwebb]

You might be able to use a SchedulingConfigurer to set the scheduler directly.

[philwebb]

@rwinch Does Spring Security offer a DelegatingSecurityContextTaskScheduler, or is there a recommended approach for this?

[wilkinsona]

org.springframework.security.scheduling.DelegatingSecurityContextSchedulingTaskExecutor, perhaps?

[lukas-krecan-lt]

The workaround is to wrap ScheduledExecutorService to ConcurrentTaskScheduler

[lukas-krecan-lt]

There is lot of workarounds, it just makes migrating to 2.1.0 harder. Is it a documented intentional change?

[philwebb]

@lukas-krecan-lt, no, It's an unintended consequence of providing an auto-configured TaskScheduler bean. Generally, that feature seems useful so we just need to give some more consideration to this combination of features.

[philwebb]

@wilkinsona

org.springframework.security.scheduling.DelegatingSecurityContextSchedulingTaskExecutor, perhaps?

It seems like TaskScheduler is intentionally different from a SchedulingTaskExecutor. The javadoc has:

This interface is separate from {@link SchedulingTaskExecutor} since it usually represents for a different kind of backend, i.e. a thread pool with different characteristics and capabilities. Implementations may implement both interfaces if they can handle both kinds of execution characteristics.

[snicoll]

ScheduledAnnotationBeanPostProcessor uses ScheduledExecutorService if it can not find any bean of type TaskScheduler.

Thanks, I missed that case. It looks like we could backoff completely if a ScheduledExecutorService bean exists to let the framework bootstrap code use that supported code path. This doesn't sound too bad considering none of of the configuration properties would apply for that case then.

[snicoll]

Gave that a bit more thoughts.

This is a fallback code in Spring Framework that attempts to provide the best possible option given what's available in the context. I think we should try to align to that as much as we can if that's possible.

We should be able to detect a ScheduledExecutorService in the context and react to that but that poses some problem:

1. If we let the auto-configuration kick-in, we have a situation where pooling properties are ignored because we provide an executor rather than configuring one. There is no notion of specifying an executor on the builder either (as it's a either-or proposition that could be confusing)
2. If we back-off, which sounds like the logical thing to do based on 1. then anything down the road that expects a TaskScheduler will have to replicate this logic.

Right now there isn't any so it may not be so bad.

There is lot of workarounds, it just makes migrating to 2.1.0 harder.

@lukas-krecan-lt ignoring the fact we missed this one and that makes the upgrade harder, I don't understand how adding 3 lines of config to expose a TaskScheduler is "a lot of workarounds".

Having said that, I wonder if the Spring Security wrapper isn't generally useful and we shouldn't consider using that when Spring Security is at play. This can be done in the form of a customizer if we manage to expose the proper API on the builder.

[lukas-krecan-lt]

Sorry, I meant that there is lot of options how to write a workaround. Adding 3 line config is easy once you know what's wrong. It took me some time to figure out that there is a new autoconfiguration etc. I am afraid that I am not the only one who uses ScheduledExecutorService to configure task scheduling.

[rwinch]

Having said that, I wonder if the Spring Security wrapper isn't generally useful and we shouldn't consider using that when Spring Security is at play. This can be done in the form of a customizer if we manage to expose the proper API on the builder.

I'm not sure that Boot can provide a wrapper without knowledge of what user should be leveraged. I think it is better to recommend users customize it themselves.

[lukas-krecan-lt]

In theory TaskSchedulingAutoConfiguration could wrap existing ScheduledExecutorService into ConcurrentTaskScheduler but I see that TaskSchedulerBuilder is built around ThreadPoolTaskScheduler so it looks like a dead end too.