In a typical Spring application, we might use both automated and explicit configuration. Even if you prefer explicit configuration via JavaConfig, sometimes XML is the best solution. Fortunately in Spring, none of these configuration schemes are mutually exclusive. You can mix JavaConfig's component scanning with autowiring and/or XML configuration whenever possible. Actually, as we saw in Section 2.2.1, we need at least a little bit of explicit configuration to enable component scanning and autowiring. The first thing to understand about hybrid configuration is that when autowiring, it doesn't care where the beans to be wired come from. Autowiring takes into account all beans in the Spring container, whether it is declared in JavaConfig or XML or obtained through component scanning. You may be wondering how to reference beans in explicit configuration, such as in XML configuration and Java configuration. Let's first take a look at how to reference XML-configured beans in JavaConfig
1.1 Referencing XML configuration in JavaConfig
Now, let's tentatively assume that CDPlayerConfig has become a bit unwieldy and we want to split it up. Of course, it currently only defines two beans, far from being a complex Spring configuration. However, let's assume that two beans are too much. Create a higher level SoundSystemConfig, in this class use @Import to combine the two configuration classes
Now, let's assume (for some reason) that we want to configure the BlankDisc via XML as follows
Now that BlankDisc is configured in XML, how do we get Spring to load it along with other Java-based configuration?
The answer is the @ImportResource annotation. Assuming that BlankDisc is defined in a file named cd-config.xml, which is located in the root classpath, you can modify the SoundSystemConfig to use the @ImportResource annotation, such as
as shown below:
Both beans - CDPlayer configured in JavaConfig and BlankDisc configured in XML - will be loaded into the Spring container. Because the method annotated with @Bean in CDPlayer accepts a CompactDisc as a parameter, the BlankDisc will be assembled, and it has nothing to do with whether it is configured through XML.
1.2 Reference JavaConfig in XML configuration
Suppose you're using Spring's XML-based configuration and you've realized that XML is getting out of hand. Like before, we're dealing with two beans, but things are actually going to get worse. Before getting overwhelmed by countless angle brackets, we decided to split the XML configuration file. In the JavaConfig configuration, we have shown how to use @Import and @ImportResource to split the JavaConfig class. In XML, we can use the import element to split the XML configuration. For example, suppose you want to split the BlankDisc bean into its own configuration file called cd-config.xml, which is the same as we used @ImportResource earlier. We can reference this file using the <import> element in the XML configuration file:
Now, let's assume that BlankDisc is no longer configured in XML, but is configured in JavaConfig, and CDPlayer continues to be configured in XML. How does XML-based configuration reference a JavaConfig class? In fact, the answer is not so intuitive. The <import> element can only import other XML configuration files, and no XML element can import the JavaConfig class. However, there is one element you are already familiar with that can be used to import Java configuration into XML configuration: the <bean> element. To import the JavaConfig class into the XML configuration, we can declare the bean like this:
In this way, two configurations - one described in XML and the other in Java - are combined. Similarly, you may also want to create a higher-level configuration file that does not declare any beans, but is responsible for combining two or more configurations. For example, you could remove the CDConfig bean from the previous XML file and instead use a third configuration file to combine the two:
Whether using JavaConfig or XML for assembly, I usually create a root configuration, as shown here, that combines two or more assembly classes and/or XML files. I would also enable component scanning in the root config (via <context:component-scan> or @ComponentScan). You'll see this technique in many examples throughout this book.