Spring is the core container in the SSM stack. It solves the problems of manual Java object creation, fragmented dependency management, and tight coupling. This guide focuses on three essentials—IoC, Beans, and XML-based DI—and connects them through a first Spring application, container internals, bean scope, and autowiring. It works well as a fast-reference introduction to Spring.
Technical Specification Snapshot
| Parameter | Description |
|---|---|
| Core Languages | Java, XML |
| Core Framework | Spring Framework |
| Runtime Model | Configuration loaded through ClassPathXmlApplicationContext |
| Core Protocols / Conventions | IoC, DI, Bean configuration conventions |
| GitHub Stars | Not provided in the source material |
| Core Dependencies | spring-context, spring-beans, junit, logging components |
Spring delivers clear value as a container framework
Spring is essentially a lightweight container whose core capabilities are IoC and DI. It moves object creation out of business code and into the container, which reduces direct dependencies between modules and makes maintenance, testing, and extension easier.
In a traditional approach, developers must explicitly new objects, assemble dependencies, and manage lifecycle details. Once Spring takes over these responsibilities, business code only needs to focus on what to use, not how to create it. That is the engineering value of Inversion of Control.
AI Visual Insight: The diagram shows how responsibility for object creation shifts. In the traditional model, business code instantiates dependency objects directly. Under IoC, the Spring container centrally manages object creation, caching, and delivery, which weakens the direct coupling between callers and implementation classes.
Inversion of Control is best understood as transferring ownership of object management
IoC is not a specific API. It is a design principle. Previously, the program controlled objects; now, the container controls them. After the application starts, Spring reads the configuration, creates Beans in the container, and then delivers them to callers through getBean() or autowiring.
// Traditional approach: business code creates the object directly
Users user = new Users(); // Manual instantiation; object creation remains in the developer's hands
user.setUsername("秋香");
user.setPassword("321");This code shows that traditional development requires manual object instantiation and property assignment.
A first Spring application usually starts by bootstrapping an XML container
The smallest beginner workflow has two steps: define spring.xml, then load it with ClassPathXmlApplicationContext. The configuration file is typically placed on the classpath, commonly under the src or resources directory.
After the container starts, Beans are created and cached according to the configuration. Developers retrieve an object instance by its Bean id and then invoke business logic. This approach is especially useful for understanding Spring’s most fundamental execution model.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
<!-- Let the Spring container manage the Users class -->
<bean id="u" class="com.myspring.pojo.Users"></bean>
</beans>This XML declares a Users Bean managed by Spring.
package com.myspring.test;
import com.myspring.pojo.Users;
import org.junit.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
public class Demo {
@Test
public void run() {
// Load spring.xml and start the IoC container
ApplicationContext ac = new ClassPathXmlApplicationContext("spring.xml");
// Get the Bean by id and cast it to the target type
Users u = (Users) ac.getBean("u");
u.setUsername("秋香");
u.setPassword("321");
System.out.println(u);
}
}This example demonstrates the full flow of container startup, Bean retrieval, and instance usage.
Spring’s core container centers on BeanFactory and ApplicationContext
In most learning paths, ApplicationContext appears more often. It is an enhanced form of BeanFactory that provides internationalization, event propagation, and a more developer-friendly container model. The source material also uses it as the primary entry point.
AI Visual Insight: The image highlights the hierarchy of the Spring container. At the foundation, BeanFactory provides basic Bean management. Above it, ApplicationContext extends the model with resource loading, event handling, and a more enterprise-ready configuration experience. This reflects Spring’s evolution from “able to create objects” to “able to manage the application context.”
The Bean tag defines object identity and type mapping
The two most common attributes on `
` are `id` and `class`. The `id` is the unique identifier inside the container, and `class` is the fully qualified name of the class to instantiate. Once Spring reads this mapping, it knows which object to create and under which name to store it. By default, Spring Beans are singletons, which means repeated lookups of the same `id` usually return the same instance. If you want a new object each time, set `scope` to `prototype`. “`xml “` This configuration means each lookup of `u` returns a different `Users` instance. ## Spring’s execution model can be summarized as reading configuration, creating objects, storing mappings, and dispatching on demand When the container starts, it first parses the XML, then uses reflection to instantiate objects based on ` ` metadata, and finally stores them in an internal cache structure. A call such as `getBean(“u”)` essentially performs a lookup in that mapping table and returns the matching instance.  **AI Visual Insight:** The image illustrates the full chain from configuration parsing to Bean registration and finally to business-layer object retrieval. The technical emphasis is that the container uses metadata to drive instantiation and dependency assembly, rather than hard-coding object relationships in business logic. ### Dependency injection moves property assignment from code into configuration The essence of DI is injecting dependencies or property values into an object. In the XML era, the two most common approaches are `property` injection and `constructor-arg` injection. The former depends on setters, while the latter depends on constructors. “`xml “` This configuration demonstrates simple value injection, constructor injection, and reference object injection together. ## XML can directly configure injection for common collection types Spring provides native tag support for arrays, `List`, `Set`, `Map`, and `Properties`. This style works well for legacy projects and teaching scenarios because it makes it easy to see how object structure maps from configuration into in-memory instances. “`xml 北京 上海 深圳 11 12 浙江 江苏 河北 root “` This XML shows Spring’s unified approach to injecting mainstream collection properties. ### Autowiring reduces repeated explicit `ref` configuration Autowiring includes `byName` and `byType`. `byName` requires the Bean `id` to match the property name, while `byType` requires a unique matching type in the container. In both teaching and real-world use, `byType` is often easier to understand, but you must avoid type conflicts. “`xml “` This configuration shows that both local and global autowiring can be configured in XML. ## This Spring foundation is the prerequisite for understanding later SSM integration In the SSM stack, Spring acts as the central hub for business object management. Once you understand IoC, Bean scope, XML injection, and autowiring, it becomes much easier to see how Spring MVC controllers or MyBatis integration plug into the same container. If you fully understand this layer, then later moving to annotations, Java Config, or Spring Boot autoconfiguration is mainly an upgrade in configuration style. The underlying ideas remain the same. ## FAQ ### 1. Why does `getBean()` often require an explicit type cast? Because the base interface returns `Object` or a generic object reference. In the XML era, the most common pattern was to retrieve a Bean by `id` and then cast it to the target type. In modern projects, you can also retrieve Beans by type to reduce casting. ### 2. How should I choose between `singleton` and `prototype`? Use `singleton` first for stateless, reusable service objects. Choose `prototype` for objects that require independent state and should produce a fresh instance for each request. The default scope is `singleton`. ### 3. Which autowiring mode is safer: `byName` or `byType`? `byType` is more intuitive, but it requires type uniqueness. `byName` depends more heavily on naming conventions. If a project contains many Beans of the same type, use clearer naming or switch to annotations for more precise control. **Core Summary:** This article restructures the original Spring study notes and focuses on the IoC container, Bean lifecycle, scope, XML configuration, and dependency injection practices. It helps Java developers quickly build a solid understanding of Spring fundamentals and use runnable examples to understand `getBean`, `property`, `constructor-arg`, and autowiring.