Make customization of TaskExecutor possible

[kilink]

I have a use case where I would like to customize the TaskExecutor that is used by the SimpleMessageListenerContainer. I would simply like to set a task decorator that is used to set up and tear down some context.

Unfortunately, SimpleMessageListenerContainer only allows overriding the TaskExecutor wholesale. I'd prefer not to do this, because as you can see in the createDefaultTaskExecutor method, there are some implementation specific customizations (core pool size, max pool size, queue size, thread name prefix). I'd ideally like to retain these defaults, without having to replicate this logic in my code. The specific configuration that are performed also rely on the SimpleMessageListenerContainer having been initialized (spinningThreads is calculated based on the number of registered queues).

My only workaround now is to have a BeanPostProcessor that customizes the SimpleMessageListenerContainer's TaskExecutor after initialization, but this relies on reflection.

A couple of solutions:

1. Make getTaskExecutor public; right now it is protected. This would at least allow me to post-process the bean and customize the TaskExecutor without resorting to reflection.
2. Follow a pattern more like TaskExecutorBuilder that allows for customization; allowing me to add something like TaskExecutorCustomizers that are run during creation of the default TaskExecutor.

[n00bi14]

Hi @kilink , i have encapsulated the logic into a builder class. Would this commit solve your problem?

https://github.com/spring-cloud/spring-cloud-aws/commit/eb08f5fdc870c18ea2922c8f1b83a6478a4e73a9

[kilink]

Hi @kilink , i have encapsulated the logic into a builder class. Would this commit solve your problem?

eb08f5f

Something like this could work, although I don't see a method for setting a TaskDecorator on your TaskExecutorBuilder. More importantly though I do not think in its current form it will solve the issue, as there's still the bootstrapping problem that SimpleMessageListenerContainer must be initialized before spinningThreads can be correctly calculated. Perhaps building the ThreadPoolTaskExecutor as is done currently in createDefaultTaskExecutor and then running some configured customizers on it before calling afterPropertiesSet() would work better?

Or going with your approach, I think the builder would need a flag essentially saying "please apply the defaults after initializing", e.g. all the stuff in your fromMessageListenerContainer method. SimpleMessageListenerContainer would need a setter for the TaskExecutorBuilder then instead of the TaskExecutor itself.