Implementing component scanning

- [Instructor] So now that we've spent some time learning about component scanning, let's put it into practice in our application and convert it from a Java config based app to a component scanned application. In our ID, let's open up our service classes, and we're going to do this one at a time. So the first thing we're going to do on our greeting service is add the annotation @Service, which is a stereotype of that component, and now to our string we're going to remove the final key word and we are going to set this equal to a value. And the value much like we had done before is going to come from our property app.greeting. And import that. And then we will remove greeting from the constructor. And now we will go to our output service and we're going to do very much the same thing. We're going to set this equal to @Service. We'll remove the final qualifier on our name and set it equal to a value, and the value that we are going to set this one equal to is app.name. So app.greeting, app.name. We can now remove the name from our constructor. And now to our time service, we will set this equal to service. We will take our boolean, again remove the final qualifier, set this equal to a value, and we're going to use our spell once again, so pound, curly brace, and in that curly brace, we will set equal to new boolean to the environment value Spring.profiles.active, not equal to dev and then we will remove from the constructor that value. Replace this with super. And now in our application.config we will remove everything. We will add an annotation @ComponentScan and set our base packages equal to com.frankmoley.lil.fid. And let's do a little bit of import organization here to get rid of our no longer needed imports. And we should be able to very simply run our application. So we'll run the prod version. We get our 24 hour clock. And we'll run the dev version as well. And we get our 12 hour clock. So everything is wired correctly. Let's take a look here at what we have done. So, we've brought in some Spring imports into our classes. And that may have some negative side effects based on your implementation, but I think what you'll find is that most of the time, these are very easy to strip out if you do decide to go away from Spring. But the real value is, is because all of these classes were so simple, and a lot of times this is the case, right? You have one or two constructor arguments, if any at all, so configuration can really be handled through auto wiring and in doing so, you get a much simpler config, and that's really what makes it easier to maintain. Now one thing you may notice is I never actually set like on our output service, I never actually set auto wire on the constructor. And the reason for that is that Spring needs a constructor to construct this object. There's only one constructor and it's not the default constructor, so Spring knows it has to use that constructor. And if it was the default then there's nothing to inject anyway. So since Spring knows it has to use that constructor, it'll automatically auto wire dependencies in for you. But if you want to, to make it more explicit, you can add @autowired to these and it'll work just the exact same, but we saw that it wast even necessary. So that's really your decision as to whether you want to do that. I tend to flip back and forth because it's not needed but it does make it a little bit more explicit so you can see what's going on. Again that's up to you. But we've now taken our application, configured it with Java config and now converted that to component scanning which would then port very easily into a Spring boot application if we chose to do that because at that point we could just remove that config totally and use the Spring boot framework to do all of the auto config for us, which includes this component scan.