[spring-projects/spring-boot]TaskSchedulingAutoConfiguration 阻止发现 ScheduledExecutorService

我们用来DelegatingSecurityContextExecutorService处理计划任务中的安全注释。它在升级到 Spring Boot 2.1.0 之前可以工作，因为如果找不到任何类型的 bean 则ScheduledAnnotationBeanPostProcessor使用ScheduledExecutorServiceTaskScheduler.

TaskSchedulingAutoConfigurationTaskScheduler2.1.0 中引入的如果没有则创建默认值，这使得ScheduledAnnotationBeanPostProcessor忽略我们的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-lt

lukas-krecan

您也许可以使用 aSchedulingConfigurer直接设置调度程序。

philwebb

@rwinch Spring Security 是否提供了一个DelegatingSecurityContextTaskScheduler，或者是否有推荐的方法？

philwebb

org.springframework.security.scheduling.DelegatingSecurityContextSchedulingTaskExecutor，也许？

wilkinsona

解决方法是换行ScheduledExecutorService至ConcurrentTaskScheduler

lukas-krecan-lt

有很多解决方法，只是让迁移到 2.1.0 变得更加困难。这是有记录的有意更改吗？

lukas-krecan-lt

@lukas-krecan-lt，不，这是提供自动配置TaskSchedulerbean 的意外结果。一般来说，这个功能似乎很有用，所以我们只需要更多地考虑这个功能组合。

philwebb

@威尔金索纳

似乎TaskScheduler是故意与 a 不同SchedulingTaskExecutor。 javadoc 有：

philwebb

谢谢，我错过了那个案例。如果ScheduledExecutorService存在 bean 让框架引导代码使用受支持的代码路径，那么我们似乎可以完全退避。考虑到没有任何配置属性适用于这种情况，这听起来并不算太糟糕。

snicoll

再多考虑一下。

这是 Spring 框架中的后备代码，尝试根据上下文中可用的内容提供最佳可能的选项。我认为如果可能的话，我们应该尽可能地做到这一点。

我们应该能够ScheduledExecutorService在上下文中检测到 a 并对其做出反应，但这会带来一些问题：

如果我们让自动配置启动，就会出现池属性被忽略的情况，因为我们提供了一个执行器而不是配置一个。也没有在构建器上指定执行器的概念（因为这是一个可能令人困惑的非此即彼的命题）
如果我们退缩，这听起来像是基于 1 的合乎逻辑的事情，那么接下来任何需要 a 的事情TaskScheduler都必须复制这个逻辑。

现在还没有，所以情况可能没那么糟糕。

有很多解决方法，只是让迁移到 2.1.0 变得更加困难。

@lukas-krecan-lt 忽略了我们错过了这一事实，这使得升级变得更加困难，我不明白添加 3 行配置来公开 aTaskScheduler是“很多解决方法”。

话虽如此，我想知道 Spring Security 包装器是否通常没有用，并且当 Spring Security 发挥作用时我们不应该考虑使用它。如果我们设法在构建器上公开正确的 API，则可以通过定制器的形式完成此操作。

snicoll

抱歉，我的意思是有很多选择如何编写解决方法。一旦你知道出了什么问题，添加 3 行配置就很容易了。我花了一些时间才弄清楚有一个新的自动配置等。恐怕我不是唯一一个使用 ScheduledExecutorService 来配置任务调度的人。

lukas-krecan-lt

我不确定 Boot 是否可以在不知道应该利用哪些用户的情况下提供包装器。我觉得还是建议用户自己定制比较好。

rwinch

理论上TaskSchedulingAutoConfiguration可以将现有的包裹起来ScheduledExecutorService，ConcurrentTaskScheduler但我看到这TaskSchedulerBuilder是围绕它构建的，ThreadPoolTaskScheduler所以它看起来也像是一个死胡同。

lukas-krecan-lt

@lukas-krecan-lt 你能分享一下你为什么使用它而不是吗DelegatingSecurityContextSchedulingTaskExecutor？后者是安排支持所期望的标准合同，而前者是未找到的后备选项。我建议始终使用主要/主要用例。

这会起作用，但我不确定这是一个有效的解决方法。我认为这DelegatingSecurityContextSchedulingTaskExecutor就是你应该做的。

我想知道 a 的使用是否ScheduledExecutorService常见。当然，我们应该在 Spring Boot 中做一些事情，但我还不确定做什么。这已被标记为引起团队注意，因此我们将很快对此进行讨论。

snicoll

我继承了代码，所以我不太清楚，但我不认为有什么特殊原因。

也许发出一些警告并记录迁移说明中所需的更改将是足够好的解决方案。

lukas-krecan-lt

[spring-projects/spring-boot]TaskSchedulingAutoConfiguration 阻止发现 ScheduledExecutorService

回答

相关问题