Which one of Spring's Xml and JavaConfig extensions do you choose?

introduction

In the previous article, how did we introduce how to define Spring extensions in the form of XML "How about Spring Interview Questions: Custom XML Schema Extensions" , a lot of people are complaining about what age is it now, there are still people in xml Do you use it again? This thing is outdated a long time ago, is it necessary to master it? Spring's official website puts this method at the end. Can you imagine how important it is? Now that everyone is complaining, let's continue to introduce the annotation-based Spring extension today.

JavaConfig configuration extension

Starting from Spring 3.0, Spring provides a JavaConfig method that can be used to replace the previous XML method. The original XML configuration can be replaced by annotations one by one. It is mainly achieved through the collocation of @Configuration, @Bean, @Import, and @DependsOn annotations. This method is also used by SpringBoot.

@Configuration

@Configuration can only be marked on a class, indicating that the class is a JavaConfig class, so that it can be scanned and identified by the Spring IOC container and create a Bean to add to the container. The @Configuration class is equivalent to an xml file in the past. Let's look at an example provided by the official website:

@Configuration
public class AppConfig {
    @Bean
    public MyService myService() {
        return new MyServiceImpl();
    }

This defined JavaConfig is equivalent to the original XML configuration as follows:

<beans>
    <bean id="myService" class="cn.javajr.services.MyServiceImpl"/>
</beans>

@Bean

@Bean can only be marked on the method, indicating that the method returns a Spring Bean, which can be managed by the IOC container, which is equivalent to the <bean/> element previously written in the xml file.

• name: Specify the name of one or more beans. When the name is not set, the Spring container will default to the @Bean method name as the bean name. When the name is set, the method name will no longer be used. When multiple names are set at the same time , Except for the first name, everything else will be used as an alias for the bean. It is equivalent to the name attribute in the xml configuration.
• initMethod: Specifies the method that the container calls after the bean is initialized. It is equivalent to the init-method attribute in the xml configuration.
• destroyMethod: Specifies the method to be called before the container destroys the bean. Equivalent to destroy-method in xml configuration.
• autowire: Specifies the strategy used by bean dependency injection during automatic assembly. The value can refer to the three constants of Enum class Autowire: Autowire.BY_NAME, Autowire.BY_TYPE, Autowire.NO.

@Import

The <import/> tag in the XML configuration provides @Import based on JavaConfig to combine modular configuration classes. The usage is as follows:

@Configuration()  
@Import({ApplicationContextConfig.class})  
public class ApplicationContextConfig {

The above is a relatively simple introduction to several kinds of annotations in the form of XML that are replaced by JavaConfig annotations. It is still very simple to use. If you have a better understanding of the previous XML configuration files, using JavaConfig is even easier and more convenient.

Dubbo's JavaConfig

In the last article, we introduced dubbo to customize extensions through XML. Today we will look at how dubbo uses JavaConfig to replace XML extensions.
Let's take a look at how dubbo's service provider implements annotations

@Configuration
@EnableDubbo(scanBasePackages = "org.apache.dubbo.samples.annotation.impl")
@PropertySource("classpath:/spring/dubbo-provider.properties")
static class ProviderConfiguration {
}

We have already introduced the @Configuration annotation above, let’s focus on the @EnableDubbo annotation
@EnableDubbo is actually @EnableDubboConfig @DubboComponentScan is achieved through these two combined annotations,
The @EnableDubboConfig annotation is implemented as follows:

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
@Import(DubboConfigConfigurationRegistrar.class)
public @interface EnableDubboConfig {

This annotation uses @Import(DubboConfigConfigurationRegistrar.class) so Spring is processing
@EnableDubboConfig will instantiate DubboConfigConfigurationRegistrar when annotated
And call its registerBeanDefinitions method, this method is mainly to parse the propties file and according to different configurations
The item generates a Bean object of the corresponding type.

to sum up

• Through the configuration extension based on XML and Java, users can use the components developed by us through Spring, providing good ease of use.
• Although most of them are now using JavaConfig this way, there are still some people who prefer xml this way

XML can make configuration centralized, all components are not scattered, so you have a good overview of beans, such as mybais configuration file, SpingMvc configuration file, all put together, if you need to split the file, Spring can help You realize. Then (Spring) will reassemble through internal <import> tags or aggregate external context files.

• Of course, xml and JavaConfig can also be mixed. As to which method to use depends on personal programming habits, no method is absolutely good, and each has its own merits.
• After reading these two articles about Spring extensions in different ways, can we implement one by ourselves?

the end

• Due to my lack of knowledge, there will inevitably be mistakes. If you find something wrong, please leave a message to point it out and I will correct it.
• If you think the article is not bad, your forwarding, sharing, admiration, liking, and commenting are your greatest encouragement to me.
• Thank you for reading, welcome and thank you for your attention.

Picking apples from the shoulders of giants:
https://javajr.cn