CODEWITHSUNDEEP
springspring-bootspring-kafka
user3761001
user3761001

Reputation: 128

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

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?

Upvotes: 1

Views: 473

Answers (1)

Artem Bilan
Artem Bilan

Reputation: 121462

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;

Upvotes: 2

Related Questions