Spring Kafka bean configuration- why invoking bean method instead of autowire? - spring

Question

I have seen this pattern on tutorials and github projects regarding spring kafka bean declaration and
I don't understand why bean methods are invoked directly instead of autowire,
for example,
In https://www.baeldung.com/spring-kafka section 4:
#Configuration
public class KafkaProducerConfig {
#Bean
public ProducerFactory<String, String> producerFactory() {
Map<String, Object> configProps = new HashMap<>();
configProps.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapAddress);
configProps.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
configProps.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
return new DefaultKafkaProducerFactory<>(configProps);
}
#Bean
public KafkaTemplate<String, String> kafkaTemplate() {
return new KafkaTemplate<>(producerFactory());
}
}
why invoking the method producerFactory?
wouldn't it be better to declare it like this?
#Configuration
public class KafkaProducerConfig {
#Bean
public ProducerFactory<String, String> producerFactory() {
Map<String, Object> configProps = new HashMap<>();
configProps.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapAddress);
configProps.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
configProps.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
return new DefaultKafkaProducerFactory<>(configProps);
}
#Bean
public KafkaTemplate<String, String> kafkaTemplate(ProducerFactory<String, String> producerFactory) {
return new KafkaTemplate<>(producerFactory);
}
}
It seems that two instances of DefaultKafkaProducerFactory are created instead of just one.
What am I missing?

Answer 1

No, two instances of that object are not created because that producerFactory() is proxied by BeanFactory exactly for the case like this.
Although I agree that injected variant is better with the modern approach especially when we pursue a performance gain on start up.
See #Configuration.proxyBeanMethods JavaDocs:
/**
* Specify whether {#code #Bean} methods should get proxied in order to enforce
* bean lifecycle behavior, e.g. to return shared singleton bean instances even
* in case of direct {#code #Bean} method calls in user code. This feature
* requires method interception, implemented through a runtime-generated CGLIB
* subclass which comes with limitations such as the configuration class and
* its methods not being allowed to declare {#code final}.
* <p>The default is {#code true}, allowing for 'inter-bean references' via direct
* method calls within the configuration class as well as for external calls to
* this configuration's {#code #Bean} methods, e.g. from another configuration class.
* If this is not needed since each of this particular configuration's {#code #Bean}
* methods is self-contained and designed as a plain factory method for container use,
* switch this flag to {#code false} in order to avoid CGLIB subclass processing.
* <p>Turning off bean method interception effectively processes {#code #Bean}
* methods individually like when declared on non-{#code #Configuration} classes,
* a.k.a. "#Bean Lite Mode" (see {#link Bean #Bean's javadoc}). It is therefore
* behaviorally equivalent to removing the {#code #Configuration} stereotype.
* #since 5.2
*/
boolean proxyBeanMethods() default true;