19.6.1. Spring Configuration: XML-based

<beans>
<bean id="engine" class="com.example.Engine"/>
<bean id="car" class="com.example.Car">
<constructor-arg ref="engine"/>
</bean>
</beans>

In this chunk, we see an XML configuration snippet for defining beans in a Spring application. The <beans> tag indicates the start of the Spring configuration. Inside this, two <bean> entries define the components of the application. The first bean defines an 'engine' of type 'com.example.Engine'. The second bean, a 'car' of type 'com.example.Car', has a constructor argument that references the 'engine' bean. This means that when the 'car' bean is created, it will receive an instance of 'engine' automatically, illustrating Dependency Injection via Constructor Injection.

Imagine you're assembling a toy car. Instead of building the engine yourself each time, you have a box of pre-made engines to use. In this case, the XML configuration is like a blueprint that specifies which engine goes into which car, simplifying the assembly process.

ApplicationContext context = new ClassPathXmlApplicationContext(
"beans.xml");
Car car = context.getBean("car", Car.class);
car.drive();

This chunk demonstrates how to use the Spring framework to create an application context based on the XML configuration file we defined earlier. The line new ClassPathXmlApplicationContext("beans.xml") loads the beans defined in the 'beans.xml' file. Then, context.getBean("car", Car.class) retrieves the 'car' bean from the Spring context. Finally, the method car.drive() is called, which triggers the car's behavior, showing that everything is properly wired up and functional.

Think of the application context like a restaurant. You place an order (similar to calling getBean), and the kitchen prepares your meal (the 'car' bean), ready for you to enjoy. This process abstracts much of the complexity, just like a synchronized restaurant experience allows you to focus on dining rather than cooking.

@Component
class Engine {
public void start() {
System.out.println("Engine started.");
}
}
@Component
class Car {
private final Engine engine;
@Autowired
public Car(Engine engine) {
this.engine = engine;
}
public void drive() {
engine.start();
System.out.println("Driving...");
}
}

In this chunk, we shift to using annotations for Spring configuration, which is a more modern and typically more concise method compared to XML configuration. The @Component annotation tells Spring that 'Engine' and 'Car' classes are components that it should manage. The @Autowired annotation on the constructor of the 'Car' class indicates that Spring should inject an instance of 'Engine' when creating a 'Car'. This approach leads to cleaner code and less boilerplate while achieving the same outcomes as the XML configuration.

Think of annotations like tags on an item in a store. A tag that says 'This is an Engine' helps the storekeeper know where to place that engine in the shop. Similarly, the @Component tag helps Spring manage the objects effectively, identifying them without the need for a detailed instruction manual.

AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);
Car car = context.getBean(Car.class);
car.drive();

This final chunk illustrates how to set up the application context for annotations. Instead of loading a configuration file, AnnotationConfigApplicationContext initializes the context using a configuration class (here assumed as 'AppConfig'). The getBean(Car.class) retrieves the bean managed by Spring, and calling car.drive() demonstrates that it works just like before, but now using annotations instead of XML configuration, reflecting the flexibility of Spring framework.

Consider this annotation setup like assembling a LEGO model where each piece has stickers indicating what it is and where it goes. Instead of a bulky guidebook, you use a simple outline (the configuration class) to put your model together. It's efficient and visually clear, simplifying your building process.

--