Welcome to Springwolf. Thanks a lot for creating your first pull request. Please check out our contributors guide and feel free to join us on discord.

Thank you @ruskaof for looking into this issue and providing a link to the spring-kafka code. In its basic form, the change looks good to me.

I notice that due to the BindingFactory change (public interface), a lot of files needed adjustments. Additionally, Springwolf users will need to update their implementation (breaking compile change).
I wonder if it is possible to avoid this?
If not, I like to make sure that the change is future-proof for similar feature requests (method as context instead of class?). Please understand that I/we will review this change more closely due to the interface change.

I assume that tests are missing at this point, since you wanted to get a feedback about the general direction first. Before this PR can be merged, test(s) in springwolf-plugin/springwolf-kafka-plugin are required.

Also, to demo this improvement (and have another layer of test), please update the springwolf-kafka example (probably new BeanRefConsumer file).

I plan to get a second opinion from @sam0r040 tomorrow (method vs class).

In case you have any questions, let us know.
Thank you for picking up this issue!

Hi @ruskaof,

Thank you for the update, sorry for the delay.

We like the change and breaking changes are avoided by the addition you added 👍
Also, the BindingContext encapsulates the class well.

Springwolf completely operates on classes at this point, not specific Spring bean instances. The Spring ApplicationContext is used to get the (one) current instance of a class using #getBean(clazz) [0]. The method will only return, when exactly one bean for that class is found. As a result, the following bean definition will not work:

@Bean
public Listener listener1() {
    return new Listener("topic1");
}

@Bean
public Listener listener2() {
    return new Listener("topic2");
}

We are willing to accept this at this point. The alternative is to create multiple classes extending the Listener class. Just want to make sure that you are aware of this limitation and your use-case still works?

As the getBean method may throw a NoUniqueBeanDefinitionException, can you wrap the error to indicate the class to assist the user in locating the original error? The error message may include a hint that the error is a limitation of Springwolf in combination with beanRef.

Also, in the next step, tests are required for the KafkaBeanRefHelper.

Great work! Looking forward to the addition.