In large-scale enterprise Java applications, keeping all bean definitions inside a single configuration class quickly leads to bloated, unmaintainable code. Spring's @Import annotation provides an elegant solution by allowing developers to split bean configurations across focused, modular @Configuration classes and aggregate them cleanly into a central configuration hub.
How Aggregating Configuration Works
Instead of registering multiple configuration classes manually when initializing the container, you designate one primary or root configuration class and aggregate other specialized classes:
Modular Configuration Classes: Separate your beans logically into domain-specific modules (such as AppConfigA and AppConfigB).
Aggregation Hub: Annotate a root configuration class with @Import({AppConfigA.class, AppConfigB.class}) to consolidate the configurations.
Simplified Container Bootstrapping: Pass only the main configuration class to AnnotationConfigApplicationContext. Spring automatically discovers and loads all imported classes and their associated @Bean definitions.
Step-by-Step Implementation Flow
Define Feature Configs: Create individual configuration classes annotated with @Configuration, defining beans specific to their feature.
Create Main Config: Define a main aggregation class (e.g., AppConfig) and apply @Import passing an array of module configuration classes.
Initialize ApplicationContext: Instantiate the container with new AnnotationConfigApplicationContext(AppConfig.class).
Access Beans: Retrieve beans declared across any of the imported configuration classes seamlessly from the single context.
Major Architectural Benefits
Separation of Concerns: Keeps configuration files cohesive, lightweight, and focused on specific domains (e.g., database, security, or business logic).
Easier Unit & Integration Testing: Allows test suites to bootstrap only relevant configuration modules rather than the entire application graph.
Clean Maintenance: Adding, removing, or swapping modular features becomes as simple as updating an entry in the @Import array.
Recommended Next Videos
Continue your deep dive into Spring configuration and annotations with these tutorials from our channel:
@Bean(name = "customer") public Customer customer() { System.out.println( "In CustomerConfig employee() is called by the Spring container"); returnnew Customer("John"); }
Customer customer = (Customer) context.getBean("customer"); System.out.println("Got customer object from the ApplicationContext");
customer.customerDetails();
} }
Output
Oct 07, 2018 7:32:15 AM org.springframework.context.support.AbstractApplicationContext prepareRefresh
INFO: Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext@5f4da5c3: startup date [Sun Oct 07 07:32:15 IST 2018]; root of context hierarchy
In EmployeeConfig employee() is called by the Spring container
com.ram.core.Employee, Employee(String name) constructor is called, Peter
In CustomerConfig employee() is called by the Spring container
com.ram.core.Customer, Customer(String name) constructor is called, John
---------------------------------------
Got employee object from the ApplicationContext
Employee Name = Peter
---------------------------------------
Got customer object from the ApplicationContext
Customer Name = John
Managing Complex State Lifecycles in Real Projects
In software development projects, domain entities frequently transition through intricate multi-stage lifecycles. Whether you are building an order processing system, an approval workflow, or a document management engine, objects change their behavior dramatically based on their current stage.
Relying on flag variables and nested switch-case statements leads to brittle code that is prone to regression bugs whenever a new lifecycle phase is introduced. The State Design Pattern provides an object-oriented solution by turning states into independent classes.
Project Implementation Architecture
In this end-to-end project walkthrough, the architecture is structured around clean object-oriented delegation:
State Interface: Outlines the contract and domain actions valid across various lifecycle phases.
Concrete State Classes: Each state class encapsulates the exact logic for handling incoming requests and controls transitions to subsequent states.
Context Class: Maintains a reference to the active state instance and delegates operational methods directly to it, decoupling the consumer from state transition logic.
Architectural Benefits in Production Code
Applying the State pattern to real-world applications delivers clear advantages:
Open/Closed Principle: Introduce new project states or lifecycle steps by creating new classes without altering existing state code.
Single Responsibility Principle: Isolate state-specific execution logic into dedicated files for simpler unit testing and debugging.
Cleaner Domain Models: Remove convoluted conditionals, replacing them with expressive, polymorphic method dispatch.
State Design pattern - Implementation [Project] - Class Diagram
ProjectState.java public interface ProjectState
{
public void doRequirmentGathering();
public void doDesignAndArchitecture();
public void doDevelopement();
public void doTesting();
}
RequirementGatheringState.java
public class RequirementGatheringState implements ProjectState
{
@Override public void doRequirmentGathering() { System.out.println("'RequirmentGathering' has been started .............");
System.out.println("'RequirmentGathering' has been finished by 7 days .............");
}
@Override public void doDesignAndArchitecture() { System.out.println("Cannot do 'DesignAndArchitecture' because Project is in 'RequirmentGathering' Phase...");
}
@Override public void doDevelopement() { System.out.println("Cannot do 'developement' because Project is in 'RequirmentGathering' Phase...");
}
@Override public void doTesting() { System.out.println("Cannot do 'Testing' because Project is in 'RequirmentGathering' Phase...");
}
}
DesignAndArchitectureState.java
public class DesignAndArchitectureState implements ProjectState
{ @Override public void doRequirmentGathering() { System.out.println("'RequirmentGathering'[Clarification of Requirement] you can do in ''DesignAndArchitecture'' Phase ......."); }
@Override public void doDesignAndArchitecture() { System.out.println("'DesignAndArchitecture' has been started .............");
System.out.println("'DesignAndArchitecture' has been finished by 10 days ............."); }
@Override public void doDevelopement() { System.out.println("Cannot do 'developement' because Project is in 'DesignAndArchitecture' Phase...");
}
@Override public void doTesting() { System.out.println("Cannot do 'Testing' because Project is in 'DesignAndArchitecture' Phase...");
}
}
DevelopementState.java
public class DevelopementState implements ProjectState
{ @Override public void doRequirmentGathering() { System.out.println("Cannot do 'RequirmentGathering' because Project is in 'Developement' Phase..."); }
@Override public void doDesignAndArchitecture() { System.out.println("'DesignAndArchitecture'[Clarification of DesignAndArchitecture] you can do in ''Developement'' Phase ......."); }
@Override public void doDevelopement() { System.out.println("'Developement' has been started .............");
System.out.println("'Developement' has been finished by 40 days .............");
}
@Override public void doTesting() { System.out.println("Cannot do 'Testing' because Project is in 'Developement' Phase...");
}
}
TestingState.java
public class TestingState implements ProjectState
{
@Override
public void doRequirmentGathering()
{
System.out.println("Cannot do 'RequirmentGathering' because Project is in 'Testing' Phase...");
}
@Override
public void doDesignAndArchitecture()
{
System.out.println("Cannot do 'DesignAndArchitecture' because Project is in 'Testing' Phase...");
}
@Override
public void doDevelopement()
{
System.out.println("'Developement'[Bug fixes] you can do in ''Testing'' Phase .......");
}
@Override
public void doTesting()
{
System.out.println("'Testing' has been started .............");
System.out.println("'Testing' has been finished by 20 days .............");
}
}
Project.java
// This is like Context
public class Project implements ProjectState
{
private ProjectState projectState;
public Project()
{
projectState = new RequirementGatheringState();
}
public ProjectState getProjectState()
{
return projectState;
}
public void setProjectState( ProjectState projectState )
{
this.projectState = projectState;
}
@Override
public void doRequirmentGathering()
{
projectState.doRequirmentGathering();
/*
* Once RequirmentGathering is finished project internal state
The Intercepting Filter Design Pattern is widely applied in modern web frameworks and enterprise backends to handle cross-cutting concerns cleanly. Instead of embedding security checks, request encoding, or auditing directly into your business controllers, this pattern lets you execute specialized filters in an ordered chain before reaching the final handler.
How the Components Work Together
Filter Interface: Defines a standard contract (such as an execute(String request) method) that every concrete filter implements.
Concrete Filters: Specific implementations that handle focused tasks (e.g., an AuthenticationFilter validating credentials or a DebugFilter logging request payloads).
Target: The ultimate business destination or resource (such as a core service or web handler) that processes the request once all filters approve.
FilterChain: Maintains an ordered list of filters, executes them sequentially, and finally triggers the target.
FilterManager: Coordinates the filter chain setup and manages which filters attach to incoming requests.
Client: The caller that sends requests through the FilterManager rather than directly to the target.
Execution Flow in Code
The Client issues an incoming request.
The FilterManager receives the request and initializes the FilterChain.
The FilterChain invokes each registered Filter in succession (e.g., checking tokens, validating headers, logging data).
Once every filter executes successfully, the chain passes control directly to the Target.
Key Benefits for Software Design
Single Responsibility: Each filter class has only one job, making your codebase modular and easy to debug.
Dynamic Extensibility: You can plug in new filters (like rate limiting or data compression) without modifying the target resource.
High Reusability: Common filters can be attached to multiple handlers across different services.
Recommended Next Videos
Deepen your understanding of filters and servlet architecture with these related tutorials from our channel:
