原文地址:http://blog.fawnanddoug.com/2012/08/how-those-spring-enable-annotations-work.html

Spring's Java Config is a great way to configure your application without writing a lot of configuration code.  One reason is those awesome @Enable* annotations that let you magically set up things like Transactions (@EnableTransactionManagement), Spring MVC (@EnableWebMvc) or timed jobs (@EnableScheduling) with a simple class level annotation on your configuration class. These simple statements provide a lot of functionality but their machinations are fairly obscure.  On the one hand, it's great to get so much functionality for so little work, but on the other hand, if you don't understand how something works it makes debugging and problem solving much harder.  I couldn't find any posts or documents that covered how those annotations work so I figured I would write up one based on the research I did while debugging.  I don't work for Spring and I didn't write any of this code so please post any corrections or improvements in the comments and I'll update the post.

Design Goals

From what I can tell, the design goal of those @Enable* annotations is to allow the user set up complex functionality with a minimal amount of code.  In addition, it seems clear that users must be able to use either a  simple default or be allowed to manually configure that code.  Finally, the complexities of the code are intended to be hidden from the user.  In short, let the user set up a lot of beans and optionally configure them without having to know the details of those beans (or really what's being set up).  I think there are a lot of pros (and some cons) to this approach but I'll discuss that at the end.

Case #1: @EnableScheduling (importing an @Configuration class)

The first thing to note is that the @Enable* annotations are not magic.  Nothing in the Bean Factory knows anything about them specifically and there are no dependencies in the Bean Factory classes between the core functionality and specific annotations (like @EnableWebMvc) or the jars they're stored in (like spring-web).  Let's take a look at @EnableScheduling and see how it works.  You might have a MainConfig class that looks like this:

1
2
3
4
5
@Configuration
@EnableScheduling
public class MainConfig {
// some beans go in here
}

There's nothing special in the above. Just a standard Java Config that's annotated with @EnableScheduling. @EnableScheduling lets you execute certain methods at a set frequency. For example, you can run BankService.sendMoneyToDoug() every 20 minutes.   The @EnableScheduling annotation itself looks like this:

1
2
3
4
5
6
7
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Import(SchedulingConfiguration.class)
@Documented
public @interface EnableScheduling {
 
}

If we look at the annotation above, we can see that it is just a standard Class level annotation (@Target/@Retention) that should be included in JavaDocs (@Documented), but it has one Spring-specific annotation: @Import.  @Import is the key that ties everything together.  In this case, since our MainConfig is annotated as @EnableScheduling, when the Bean Factory is parsing the file (technically the ConfigurationClassPostProcessor is parsing it) it will also find the @Import(SchedulingConfiguration.class) annotation and it will import the class defined in the value.  In this case SchedulingConfiguration.  What does it mean to import?  Well, in this case it's just treated as another Spring bean.  SchedulingConfiguration is actually annotated as @Configuration, so the Bean Factory will see it as another configuration class and all of the beans defined in that class will get pulled into your Application Context just as if you had defined another @Configuration class yourself.  If we inspect SchedulingConfiguration we can see that it only defines one bean (a Post Processor) which does the scheduling we described above.

1
2
3
4
5
6
7
8
9
10
@Configuration
public class SchedulingConfiguration {
 
 @Bean(name=AnnotationConfigUtils.SCHEDULED_ANNOTATION_PROCESSOR_BEAN_NAME)
 @Role(BeanDefinition.ROLE_INFRASTRUCTURE)
 public ScheduledAnnotationBeanPostProcessor scheduledAnnotationProcessor() {
  return new ScheduledAnnotationBeanPostProcessor();
 }
 
}

OK, but what if I want to configure the beans defined in SchedulingConfiguration?  Well, at this point we're just dealing with regular beans.  So the same mechanisms that you would use for any other beans apply here.  In this case, the ScheduledAnnotationBeanPostProcessor uses a standard Spring Application Event to find out when the Application Context is refreshed.  When this happens it checks to see if any beans implement SchedulingConfigurer and if so, uses those beans to configure itself.  This is not at all intuitive (or easy to find with an IDE) but it is completely separated from the Bean Factory and is a fairly common pattern for a bean to be used to configure another bean.  And now that we can connect all of the dots it is (somewhat) easy to find (or you could google the documentation or read the JavaDocs).

Case #2: @EnableTransactionManagement (importing an ImportSelector)

In the previous case we discussed how an annotation like @EnableScheduling can use @Import to pull in another @Configuration Class and make all of its beans available (and configurable) to your application. But what happens if you want to load a different set of beans based on some configuration?  @EnableTransactionManaged is a good example of this.  You might have a MainConfig class that looks like this:
 
1
2
3
4
5
@Configuration
@EnableTransactionManagement(mode=AdviceMode.ASPECTJ)
public class MainConfig {
// some beans
}
 
Once again, there's  nothing special in the above. Just a standard Java Config that's annotated with @EnableTransactionManagement. The only thing that's a little different from the previous example is that the user specified a parameter to the annotation (mode=AdviceMode.ASPECTJ).  The @EnableTransactionManagement annotation itself looks like this:

1
2
3
4
5
6
7
8
9
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Import(TransactionManagementConfigurationSelector.class)
public @interface EnableTransactionManagement {
 boolean proxyTargetClass() default false;
 AdviceMode mode() default AdviceMode.PROXY;
 int order() default Ordered.LOWEST_PRECEDENCE;
}

As before, a fairly standard annotation, although this time it has some parameters.  However, I mentioned previously that the @Import annotation was the key that ties everything together and that is true once again.  The distinction though, is that this time we are importing TransactionManagementConfigurationSelector.class which is not a class that is annotated with @Configuration.  TransactionManagementConfigurationSelector is a class that implements ImportSelector.  The purpose of ImportSelector is to allow your code to choose which configuration classes to load at runtime.  It has one method that takes some metadata about an annotation and returns an array of class names.  In this case, the TransactionManagementConfigurationSelector looks at the mode and returns some classes based on the mode:

1
2
3
4
5
6
7
8
9
10
protected String[] selectImports(AdviceMode adviceMode) {
 switch (adviceMode) {
  case PROXY:
   return new String[] { AutoProxyRegistrar.class.getName(), ProxyTransactionManagementConfiguration.class.getName() };
  case ASPECTJ:
   return new String[] { TransactionManagementConfigUtils.TRANSACTION_ASPECT_CONFIGURATION_CLASS_NAME };
  default:
   return null;
 }
}

Most of these classes are @Configuration classes (e.g. ProxyTransactionManagementConfiguration) so we know that they'll work like before, but some of them are not (let's ignore those for now).  For the @Configuration classes they get loaded and configured in the exact same way that we previously saw.  So in short, we can use @Import with an @Configuration class to load a standard set of beans or we can use @Import with an ImportSelector to load a set of beans that are decided at run time.  Sweet! But what about those classes we ignored?

Case #3: @EnableAspectJAutoProxy (importing at the Bean Definition Level)

@Import supports one last case which is when you want to deal with a Bean Registry (Factory) directly. If you need to manipulate the Bean Factory or work with beans at the Bean Definition level then this case is for you and it's very similar to the ones above.  Your MainConfig might look like:

1
2
3
4
5
@Configuration
@EnableAspectJAutoProxy
public class MainConfig {
// some beans
}

Once again, there's nothing special in the above. Just a standard Java Config that's annotated with @EnableAspectJAutoProxy.  Here's the source for @EnableAspectJAutoProxy:

1
2
3
4
5
6
7
8
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Import(AspectJAutoProxyRegistrar.class)
public @interface EnableAspectJAutoProxy {
 boolean proxyTargetClass() default false;
 
}

As before, the @Import is the key, but this time it's pointing to AspectJAutoProxyRegistrar which is neither an @Configuration class nor implements ImportSelector.  The trick this time is that it implements ImportBeanDefinitionRegistrar.  This interface gives access to the Bean Registry and Annotation Metadata so that we can manipulate the registry at runtime based off of the parameters in the annotation.  If you look at the previous case you can see that the classes we ignored were also ImportBeanDefinitionRegistrars.  These classes directly manipulate the Bean  Factory for those times when @Configuration classes aren't enough.

So now we've covered all of the different ways the @Enable* annotations use @Import to pull various beans into your Application Context.  They either pull in a set of @Configuration classes directly and all of the beans from those classes get imported into your Application Context.  Or they pull in an ImportSelector which chooses a set of @Configuration classes at runtime and imports those beans into your Application Context.  Or finally, they pull in an ImportBeanDefinitionRegistrars which can directly work with the Bean Factory at the Bean Definition level.

Conclusion

In general I think this approach to importing beans into an Application Context is great because it makes set up very easy for the developer.  Unfortunately it obscures how to find the available options and how to configure them.  In addition, it doesn't directly take advantage of the IDE so it's hard to tell which beans are being created (and why).  However, now that we know about the @Import annotation we can use our IDE to dig a little into each Annotation and its related configuration classes and understand which beans are being created, how they're being added to your Application Context and how to configure them.  I hope this helps! Please leave comments to let me know what you think and what I've missed / messed up.

How those spring enable annotations work--转的更多相关文章

  1. Spring Enable annotation – writing a custom Enable annotation

    原文地址:https://www.javacodegeeks.com/2015/04/spring-enable-annotation-writing-a-custom-enable-annotati ...

  2. Spring Enable* 注解

    Spring提供了一系列以Enable开头的注解,这些注解本质上是激活Spring的某些管理功能.比如,EnableWebMvc. 这个注解引入了MVC框架在Spring 应用中需要用到的所有bean ...

  3. Spring Project Annotations

       Project  Annotation  Discovered By  Package     Target(s)  Parameters  Notes . AspectJ @EnableSpr ...

  4. Spring Enable*高级应用及原理

    Enable* 之前的文章用到了一些Enable*开头的注解,比如EnableAsync.EnableScheduling.EnableAspectJAutoProxy.EnableCaching等, ...

  5. Spring Enable高级应用及原理

    Enable* 之前的文章用到了一些Enable*开头的注解,比如EnableAsync.EnableScheduling.EnableAspectJAutoProxy.EnableCaching等, ...

  6. 译:Spring框架参考文档之IoC容器(未完成)

    6. IoC容器 6.1 Spring IoC容器和bean介绍 这一章节介绍了Spring框架的控制反转(IoC)实现的原理.IoC也被称作依赖注入(DI).It is a process wher ...

  7. Developing JSF applications with Spring Boot

    Developing JSF applications with Spring Boot Spring Boot can leverage any type of applications, not ...

  8. spring@PropertySource用法

    测试例子 package com.hjzgg.auth.config; import org.springframework.beans.factory.annotation.Autowired; i ...

  9. Spring框架文档与API(4.3.6版本)

    http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/ Table of Contents I ...

随机推荐

  1. 采用EntityFramework.Extended 对EF进行扩展(Entity Framework 延伸系列2)

    前言 Entity Framework 延伸系列目录 今天我们来讲讲EntityFramework.Extended 首先科普一下这个EntityFramework.Extended是什么,如下: 这 ...

  2. UML课程复习重点

    第一章 一.UML图示建模工具 二.UML--统一建模语言,以图形符号为基础,描述软件模型既简洁又清晰.它不是开发方法,是独立于任何开发方法之外的语言.它用于描述软件系统分析.设计和实施中的各种模型. ...

  3. android http 抓包

    有时候想开发的时候想看APP发出的http请求和响应是什么,这就需要抓包了,这可以得到一些不为人知的api,比如还可以干些“坏事”... 需要工具: Fiddler2 抓包(点击下载) Android ...

  4. Vue + Webpack + Vue-loader 系列教程(2)相关配置篇

    原文地址:https://lvyongbo.gitbooks.io/vue-loader/content/ 使用预处理器 在 Webpack 中,所有的预处理器需要和一个相应的加载器一同使用.vue- ...

  5. 转:serialVersionUID作用

    汗,以前学了还忘了... Java的序列化机制是通过在运行时判断类的serialVersionUID来验证版本一致性的.在进行反序列化时,JVM会把传来的字节流中的serialVersionUID与本 ...

  6. ASP.NET Core框架揭秘(持续更新中…)

    之前写了一系列关于.NET Core/ASP.NET Core的文章,但是大都是针对RC版本.到了正式的RTM,很多地方都发生了改变,所以我会将之前发布的文章针对正式版本的.NET Core 1.0进 ...

  7. CRL快速开发框架系列教程十二(MongoDB支持)

    本系列目录 CRL快速开发框架系列教程一(Code First数据表不需再关心) CRL快速开发框架系列教程二(基于Lambda表达式查询) CRL快速开发框架系列教程三(更新数据) CRL快速开发框 ...

  8. 在Linux系统下运行微信Web开发者工具

    微信Web开发者工具只有window版本和mac版本,如果想要在Linux系统下运行微信Web开发者工具,需要花费很大周折. 注:带 * 的步骤或文件为不确定是否管用的步骤或文件.本人系统为Linux ...

  9. 基于window7+caffe实现图像艺术风格转换style-transfer

    这个是在去年微博里面非常流行的,在git_hub上的代码是https://github.com/fzliu/style-transfer 比如这是梵高的画 这是你自己的照片 然后你想生成这样 怎么实现 ...

  10. spring applicationContext.xml和hibernate.cfg.xml设置

    applicationContext.xml配置 <?xml version="1.0" encoding="UTF-8"?> <beans ...