Can not register consumer customizer to only be used for PulsarListener

[onobc]

Fact 1: When using Spring Boot auto configuration, all registered ConsumerBuilderCustomizer beans are used as default config customizers for the DefaultPulsarConsumerFactory.

Fact 2: The @PulsarListener allows a customizer bean to be applied to its underlying consumer via its consumerCustomizer attribute.

Outcome: A user is unable to register a customizer that is only used by a @PulsarListener and not as default configuration for the consumer factory.

Ask: We need a way to register a customizer and exclude it from factory default configuration.

Options

@Qualifer

Introduce a @Qualifer that can then be filtered out on the Boot side.

• ✅ single customize API easier to maintain and reason with
• ❌ Would require changes to Boot (would not happen in 3.2.0 as we are in RC phase)
• ❌ Would require more complicated lookup code respecting the qualifier (like what is done for actuator groups)
• ❌ User would need to know to qualify these vs the listener specific customizers

Specific Types

Another option is to make the customizer that is used on that annotation a different type (eg. PulsarListenerConsumerBuilderCustomizer) and that would naturally be exluded by Boot.

• ✅ No change needed by Boot (could be introduced in framework during RC phase if low risk)
• ✅ No complicated Boot lookup code
• ✅ The customizer type makes its purpose clear and direct (vs implied w/ @Qualifer)
• ❌ Another customizer API introduced

Do Nothing

This was discovered while investigating a user report around consumer customizers (#480) but not directly reported by a user. One option is to simply do nothing until an issue is reported. In many cases having the customizer as the default might not be an issue but if the customizer is doing something highly specific to the application it could be very problematic.

• ✅ nothing needs to be done now (in line w/ let's not add a bunch of things until user's tell us what they want)
• ❌ could be an unpleasant surprise to users
• ❌ introducing the concepts later could be a breaking change/ripple to users

---

ℹ️ This applies to the following so any chosen solution w/ ripple across these areas:

• ConsumerBuilderCustomizer w/ @PulsarListener
• ReaderBuilderCustomizer w/ @PulsarReader
• ReactiveMessageConsumerBuilderCustomizer w/ @ReactivePulsarListener

---

[onobc]

@awilkinsona @philwebb it would be good to get your thoughts on this as one of the options would be done in Boot and one would remain in the framework only. I am leaning on "Specific Types" approach.

[philwebb]

I'd probably lean on the specific types approach as well, but it's unfortunate that so many would need to be introduced. I think most Boot users are used to a Customizer applying to all beans and I think the @Qualifier might be a bit confusing.

One option you might consider is allowing a regular Consumer to be used instead of adding new types. E.g. if you did @PulsarListener(consumerCustomizer="myBean") myBean could implement Consumer<ConsumerBuilder<T>> rather than ConsumerBuilderCustomizer. The problem there is one bean can't implement multiple customizers any more.

[onobc]

I think most Boot users are used to a Customizer applying to all beans and I think the @qualifier might be a bit confusing.

Agreed. I also feel that not all users understand the impact of @Qualifier and how to use them.

One option you might consider is allowing a regular Consumer to be used instead of adding new types. E.g. if you did @PulsarListener(consumerCustomizer="myBean") myBean could implement Consumer<ConsumerBuilder> rather than ConsumerBuilderCustomizer. The problem there is one bean can't implement multiple customizers any more.

Clever idea to prevent creating 3 more types as a customizer is truly just a type specific java.util.Consumer. However, the fact that it is a java.util.Consumer of a org.apache.pulsar.ConsumerBuilder might be a bit confusing (the consumer consumer pattern hehe).

I'd probably lean on the specific types approach as well, but it's unfortunate that so many would need to be introduced.

I have prototyped this option a bit and I can limit the ripple by simple adapting the "Listener" specific customizer variant in the annotation processor before passing it down into the framework. I will share a branch w/ you here in a bit to get your thoughts.

[onobc]

@philwebb the associated proposal shows all the changes required for the @PulsarListener. This would be roughly the same effort for the other 2 @ReactivePulsarListener and @PulsarReader. I think this will work well. Wdyt?

[philwebb]

@onobc I think that's the best option. FWIW we spoke about it in our team meeting today and all preferred option 2.