Hi,
Currently, task executors only accept single TaskDecorator instance.
When there are multiple TaskDecorator beans to apply, I need to write such composite decorator for now. It would be helpful if it comes from spring.
Thanks,
Comment From: snicoll
TaskExecutionAutoConfiguration can accept multiple of TaskDecorator beans
Thanks for the PR. I am not entirely convinced by that argument yet. If you believe this is something Spring Boot should do, it is not mandatory that such implementation should be available at the framework level so I suggest we restrict the scope to a custom multi decorator arrangement.
Comment From: ttddyy
Hi @snicoll
so, you mean instead of adding CompositeTaskDecorator in spring-framework, putting it in spring-boot and accommodate multiple task decorators there?
I think it's a question of how much support do you provide for multiple task decorators. Spring-boot only or make it in spring and allow non spring-boot environment to get benefit.
Let me know, I can update the PR if it is better in spring-boot only.
Thanks,
Comment From: snicoll
Unfortunately, that's not what I meant. What I meant is that there is no guarantee that Spring Boot would add such feature once/if this PR is merged and I suggest to keep the discussion focused on the composite itself.
Comment From: ttddyy
Ah, ok, thanks for pointing out.
Yeah, I'm aware of that making multiple decorator support in spring-boot is a separate topic. It was just a reason behind why I needed the composite decorator.
So, to clarify, purpose of this PR is to add CompositeTaskDecorator in spring-framework, that's all about it.
Comment From: ttddyy
I have updated the PR comment, accordingly.
Thanks,
Comment From: jhoeller
Design-wise, with the language options that we have now, we would rather introduce a static asComposite(TaskDecorator...) method on the TaskDecorator interface itself... or an andThen arrangement along the lines of java.util.function.Function. So we would not rely on a public composite implementation class here, at least not for our core framework purposes.
However, since we don't ship a library of decorator implementations out of the box, I'm not convinced that this is necessary. I rather see TaskDecorator as a general purpose extension hook, not as a programming model component. If it turns out to become an arrangement of provided components e.g. in Boot, I'm open to introducing methods along the lines above.