基于Java的配置元数据

基于Java的配置元数据

有了基于XML的配置元数据和基于注解的配置元数据（还是依赖XML，需要配置容器扫描的包，以至于能够找到注解），再来了解一种脱离XML的形式，Java-based

用配置类代替XML

配置类和普通的Java类一样，区别在于配置类被一些注解标注。

举例：

public class AppConfig {

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


ApplicationContext ctx = new AnnotationConfigApplicationContext(AppConfig.class);

@Bean

可以看到，在配置类Appconfig中有一个被@Bean标注的方法，这个方法返回一个实际类型为MyServiceImpl的对象。

这个配置等价于：

<beans>
    <bean id="myService" class="com.acme.services.MyServiceImpl"/>
</beans>

细节：关于bean的id以及bean的类型

通过对照发现，缺省@Bean的属性时，默认使用被@Bean修饰的方法的名称，作为bean的id

基于XML配置时，class指定bean的实际类型（通过反射机制创建对象）；在基于Java的配置中，方法中的new MyseviceImpl()就相当于指定了class属性。

AnnotationConfigApplicationContext(Class<?>…)

请注意，由于使用了基于Java的配置，所以不能使用基于XML的构造器来构建容器，因此引入基于Java配置类的的构造器，通过这个方法加载配置类。

@Configuration

这个注解的作用是标注一个类是配置类，在包扫描的时候，让容器“知道”这个类是一个配置元数据，从而加载到容器中。

注意上面的例子，并没有在AppConfig这个配置类上加上@Configuration注解，因为加载配置元数据的方式是直接传入构造器，而不是通过包扫描。（关于怎样配置包扫描路径，下面在介绍）

兼容基于注解的配置元数据 @ComponentScan

在介绍基于注解的配置时，特别强调XML中要配置包扫描路径。因为当时使用基于注解的配置时，构建容器时，传入的参数是XML文件，所以必须告诉容器到“哪些”包下去“找”注解。

现在，基于Java的配置，不再使用XML，因此，对于包扫描的标签，也需要使用注解的方式替换：@ComponentScan(basePackages = "org.example")等价于<context:component-scan base-package="org.example"/>

改变bean的Scope：@Scope

在之前讨论@Bean注解的时候，为了避免对各种标签的混淆，所以刻意的跳过了关于bean的Scope配置的问题。再来看上面的配置：

public class AppConfig {

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

注意，这里没有指定myService这个bean的Scope（默认为Singleton），因为兼容基于注解的配置，所以可以使用@Scope来指定bean的Scope

public class AppConfig {

    @Bean
	@Scope("prototype")
    public MyService myService() {
        return new MyServiceImpl();
    }
}

再谈@ComponentScan和@Configuration

在扫描包时，如果发现有类被@Configuration标注，容器就会将它当作配置类加载。

如果直接将某个类传递给构建容器的构造器，这个类即使不被Configuration标注，它也是被当作配置类加载。

最后再强调一点，仅有被@Bean修饰的方法，才会产生bean，否则，容器会把他当作普通方法，而不是去创建一个默认名字为方法名的bean