[MUSIC] >> When you're using configurations to automatically construct your application through dependency injection in Spring, there are a number of annotations that Spring provides that vastly simplify your life and work when creating these configurations. So let's assume that we have a configuration, you know, again, in our Application class. And, we have annotated this with @configuration. [BLANK_AUDIO] Now we could go and think of every different component in our application and define an individual method with, that's annotated with @ being to say, here's is how you go an construct that particular component. Here's the interface as the return type. And here's the actual implementation of that interface that I want you to use when it's referenced. However, it's a lot of work, particularly if there's only a single implementation of an interface or you have your implementations divided in some nice way. For example where all of the imp-, implementations that are related in some way all live in the same package. And wouldn't it be nice if you could tell Spring to automatically go and find all of the implementations of the various interfaces and automatically associate those implementations with the interfaces so that wherever you @Autowired that interface in, it will use the implementation that it's discovered. The way that you do that in Spring is you can say @ComponentScan and you can provide it a series of package names, Java package names, or prefixes to Java package names. So we could have com.mobile. And Spring is automatically going to go and scan that package, find all of the interfaces, look at any annotations on any of the interfaces or any of the classes in that package as well, and then based on what it discovers it will automatically decide. For example, if it finds an interface for something that is @Autowired throughout your application and then it finds an implementer of that interface, it will automatically associate that implemented with that interface and then wherever there is an @Autowired for that interface it will take the implementer in and insert it. This of course is assuming that there is a one to one mapping based on the component scanned packages. So if it scans this package and there are multiple implementations of an interface, it can't automatically decide which one should go went into a particular object when it's being autowired. Instead, this is good for when you have either exactly one implementation of an interface, or you've divided up your implementations into packages in some way so that you can component scan one package that will have all of the implementations, but only a single implementation of each interface and automatically allow Spring to figure out which one should go where. Another important annotation to know about it is the annotation that tells Spring to go and look for all of the @Autowired annotations and actually go and fill them in. If you don't add this particular annotation to your configuration, Spring won't go and look for those@Autowired annotations. So the annotation that we need to add to our configuration is @EnableAutoConfiguration. And what this tells Spring to do is go and look for, go look for the @Autowired annotations. And wherever you find one of them, automatically fill it in with an appropriate value. So commonly you see @EnableAutoConfiguration and @ComponentScan used together. So, you'll automatically go and find a particular set of implementations that you want to use that you define, defined in some package and then you will automatically enable auto configuration through @EnableAutoConfiguration so that Spring will go and look for all the @Autowired's and fill them in. And using these two you can simplify your configuration class, because you don't have to go and explicitly define a bean with a @ bean and then a method to retrieve the bean for every single component in your application. You can simply allow Spring to discover them and then to automatically autowire them for you. Without going to all of the work they're defining each one individually or doing anything else. Now, there is a slight downside to this. The downside is, is this that going and actually doing something like automatically scanning all of the classes, and in particular package and all of the sub-packages off of this. So if this is com.mobile and you have com.mobile.data as a package and com.mobile.http as a package, all of those sub-packages will be scanned as well. So if you have lots and lots of classes on your class path in all in the sub-packages, it can take a while at launch time to actually go and scan them all, read all of the autowired instances, and configure everything. But the important thing to note is that this is only when you're starting up your application. So as long as you're running in an environment where you're starting your application up infrequently, which is the case in most environments, this isn't a big deal. There actually are a subset of cloud environments where the cloud service provider may shut your application down when it's not receiving enough requests. And these are things like Google App Engine. And in those cases, if you do this it can be a performance hit to your application in Google App Engine. And there's lots of information on the web about the impact of auto-configuration and component scanning on applications on Google App Engine. So just be aware that this can simplify your life, but at the same time, it can also create problems from a performance perspective if you are running on specific providers and they are continually restarting your application over and over. But in most cases this is not a performance set that we care about.
