GH-3542: Adds the ability to add record interceptors instead of override them

[chickenchickenlove]

Fixes: #3542
Issue link: #3542

What?
Change RecordInterceptor to List<RecordInterceptor> in MessageListenerContainer.

Why?
To allow adding multiple RecordInterceptor instances instead of overriding the existing one. Currently, only a single RecordInterceptor is supported. Users may want to register multiple RecordInterceptors. There are some workarounds, but they are not clean or ideal solutions.

By supporting List<RecordInterceptor>, users can add their own interceptors via setRecordInterceptor(...).

[artembilan]

We already have this: https://github.com/spring-projects/spring-kafka/blob/main/spring-kafka/src/main/java/org/springframework/kafka/listener/CompositeRecordInterceptor.java#L51.
So, I would expect done change over there . This is really not a container responsibility. Plus, you made too many braking changes. And setter contract is to override , not add. For add we would implement adder.
At a glance a cannot accept the change .
Thank you for understanding!

[chickenchickenlove]

@artembilan

Sorry to bother you.
I misunderstood your point at all 🙇‍♂️.

I made new commits to use CompositeRecordInterceptor.
When you have time, please take a look!

[artembilan]

So, if the composite is an external and shared, calling this from one container would mutate all others. I understand a desire to have everything container related in one place, but consequences might not be good.
Or we just leave responsibility only in the composite, or bite a bullet and always have a composite here internally as a value of interceptor property. This way any add on the container would not effect the rest of application . The awkward situation when composite is provided, but I don’t see any other way to protect from race condition .
Of course, I’d prefer to have add only in the composite, but I’m opened for any other arguments.

[chickenchickenlove]

You are right.
I missed that case. (Many users already create it as bean and use it)

As you said, Adding a new API addRecordInterceptor(...) to only CompositeRecordInterceptor makes sense to me 👍 . Also, I don't like useless recursive usage (Composite -> Composite -> ... -> Composite) 😄.

[artembilan]

Your name to the @author list of this affected class?

[artembilan]

Looks like we also need a getRecordInterceptor() in the container. See issue for more info.
As we have just discussed the add in the container is not OK, but get, compose manually and then set should be clear enough without consequences .