Although automatic configuration of Spring through component scanning and autowiring is a more recommended way in many scenarios, sometimes the automatic configuration solution does not work, so Spring needs to be configured explicitly. For example, if you want to wire a component from a third-party library into your application, in this case, there is no way to add @Component and @Autowired annotations to its class, so you can't use Autowired plan.
In this case, you must use explicit assembly. When it comes to explicit configuration, there are two options: Java and XML. In this section, we will learn how to use Java configuration, and in the next section we will continue to learn Spring's XML configuration
Like I said before, JavaConfig is a better solution when doing explicit configuration as it is more powerful, type safe and refactoring friendly. Because it's Java code, just like any other Java code in the application. At the same time, JavaConfig is different from other Java code. Conceptually, it is different from the business logic and domain code in the application. Although it is expressed in the same language as the other components, JavaConfig is the configuration code. This means that it should not contain any business logic and JavaConfig should not intrude into the business logic code. Although not required, it is common to put JavaConfig in a separate package, keeping it separate from the rest of the application logic, so that there is no confusion about its intent
1.1 Implement injection with JavaConfig
We need to declare CDPlayerbean, which depends on CompactDisc. In JavaConfig, how to wire them together?
Here is a possible way to declare CDPlayer
The cdPlayer() method, like the sgtPeppers() method, is also annotated with @Bean, which indicates that this method will create a bean instance and register it with the Spring application context. The created bean ID is cdPlayer, which is the same name as the method.
It appears that the CompactDisc is obtained by calling sgtPeppers(), but that's not quite the case. Because the @Bean annotation is added to the sgtPeppers() method, Spring will intercept all calls to it and ensure that the method created by the method is returned directly.
bean instead of actually calling it every time.
For example, suppose you import an additional CDPlayer bean that is exactly the same as the previous bean:
If the call to sgtPeppers() is like any other Java method call, then each CDPlayer instance will have its own unique instance of SgtPeppers. This makes sense if we're talking about actual CD players and CD discs. If you have two CD players, there is no physical way to put the same CD in both CD players. However, in the software world, we can inject the same SgtPeppers instance into any number of other beans. By default, beans in Spring are singletons, and there is no need for us to create the exact same instance of SgtPeppers for the second CDPlayer bean. Therefore, Spring intercepts the call to sgtPeppers() and ensures that the bean created by Spring is returned, which is the CompactDiscbean created by Spring itself when calling sgtPeppers(). So both CDPlayer beans will get the same instance of SgtPeppers.
As you can see, the way a bean is referenced by invoking a method is a bit confusing. In fact, there is a simpler way to understand:
Here, the cdPlayer() method requests a CompactDisc as a parameter. When Spring calls cdPlayer() to create a CDPlayerbean, it will automatically wire a CompactDisc to the configuration method. The method body can then use it in the appropriate way. With this technique, the cdPlayer() method can also inject the CompactDisc into the CDPlayer's constructor without explicitly referencing the @Bean method of the CompactDisc
Referencing other beans in this way is usually the best choice because it does not require the CompactDisc to be declared in the same configuration class. There's not even a requirement that CompactDisc has to be declared in JavaConfig, in fact it can be automatically discovered by component scanning or configured via XML. You can spread configuration across multiple configuration classes, XML files, and auto-scan and wire beans, as long as the functionality is complete . Regardless of how the CompactDisc is created, Spring will pass it into the configure method and use it to create the CDPlayer bean.
Again, methods annotated with @Bean can employ any necessary Java functionality to produce bean instances. Constructor and Setter methods are just two simple examples . The possibilities here are limited only by the Java language.