Служба Spring executor с компонентами Request scope не работает - PullRequest
0 голосов
/ 16 ноября 2018

Этот вопрос был задан, но мы не можем заставить решение работать.


У нас есть класс для использования в качестве класса пользовательских данных.Мы сделали это в bean-объекте запроса под конфигурацией пружины.

    @Bean
    @Scope(value = WebApplicationContext.SCOPE_REQUEST, proxyMode = ScopedProxyMode.TARGET_CLASS)
    public UserContext userContext() {
        return new UserContext();
    }

Конфигурация нашего исполнителя -

@Override
@Bean
public AsyncTaskExecutor getAsyncExecutor() {
    ThreadPoolTaskExecutor poolExecutor = new ThreadPoolTaskExecutor();
    poolExecutor.setTaskDecorator(new ContextCopyingDecorator());
    poolExecutor.initialize();
    return poolExecutor;
}

И декоратор задач -

public class ContextCopyingDecorator implements TaskDecorator {
private static final Logger logger = LoggerFactory.getLogger(ContextCopyingDecorator.class);

@Nonnull
@Override
public Runnable decorate(@Nonnull Runnable runnable) {
    logger.info("Decorating context: ");

    RequestAttributes context =
            RequestContextHolder.currentRequestAttributes();
    Map<String, String> contextMap = MDC.getCopyOfContextMap();

    return () -> {
        try {
            RequestContextHolder.setRequestAttributes(context);
            RequestContextHolder.setRequestAttributes(context, true);
            MDC.setContextMap(contextMap);

            logger.info("Context: {}", context);
            logger.info("MDC: {}", contextMap);
            runnable.run();
        } finally {
            MDC.clear();
            RequestContextHolder.resetRequestAttributes();
        }
    };
}

}

Но значения внутри userContext продолжают поступать null, как только выполнение переходит в другой поток.Мы попробовали несколько подходов, таких как InheritableThreadLocal, чтобы ввести настроенный сеанс inherited-scope и декоратор задач, как описано выше, но пока безуспешно.

Есть ли способ передать эти данные?Мы что-то упустили?Потому что, в конце концов, нам, возможно, придется использовать ThreadLocal для решения этой проблемы, что не очень хорошее решение, как говорят разные посты.

...