DEV Community: Mujuzi Moses 

🚀 Building Spring by Example V2: Completing Module 07 - Spring Batch

Mujuzi Moses  — Sun, 08 Nov 2026 10:57:33 +0000

When I started learning Spring, I noticed something about many of the tutorials I found.

They often showed how to use a feature, but not always why it worked or how the different pieces fitted together in a real application.

I learn best by building things and documenting what I discover, so I started a project called spring-by-example.

The idea is simple: instead of building one large application, I’m creating a collection of small, focused examples where each example explores a specific Spring concept with clear explanations, tests, and documentation.

I’m happy to say that I’ve now completed Module 07 - Spring Batch. 🎉

This module took me from the fundamentals of batch processing to more advanced topics such as job execution metadata, restartability, fault tolerance, and testing.

The module covers:

Jobs and Steps
Job Parameters
Item Readers
Item Processors
Item Writers
Chunk-Oriented Processing
Tasklet Processing
Job Execution and Metadata
Job Restartability
Skip and Retry
Batch Testing

One thing I particularly enjoyed about this module was understanding how Spring Batch breaks a batch process into smaller, manageable components.

Jobs and Steps

I started with jobs and steps.

A Job represents the overall batch process, while Steps define the individual operations that make up that process.

From there, I explored job parameters and how they allow values to be passed into a job at runtime.

This also helped me understand how Spring Batch identifies job instances and distinguishes between identifying and non-identifying parameters.

Item Readers, Processors, and Writers

Next came item readers, processors, and writers.

These are the core components of chunk-oriented processing.

An ItemReader reads input data, an ItemProcessor transforms or filters it, and an ItemWriter writes the resulting items.

For example, a simple processor can transform an order description into uppercase:

@Override
public ProcessedOrder process(Order order) {
    return new ProcessedOrder(
            order.id(),
            order.description().toUpperCase(Locale.ROOT)
    );
}

Chunk-Oriented Processing

Chunk-oriented processing introduced another important concept.

Rather than processing and writing one item at a time, Spring Batch can process items in chunks.

For example:

new ChunkOrientedStepBuilder<Order, ProcessedOrder>(
        "processOrdersStep",
        jobRepository,
        3
)
.reader(orderItemReader)
.processor(orderItemProcessor)
.writer(orderItemWriter)
.build();

With a chunk size of three, Spring Batch processes items in groups of three before writing them.

This helped me understand transaction boundaries and how chunk size affects the execution of a batch step.

Tasklet Processing

I also explored tasklet processing.

Unlike chunk-oriented processing, a tasklet is useful for a single operation or a small, self-contained task, such as archiving records, performing cleanup, or executing a database operation.

Job Execution and Metadata

Job execution and metadata were another important part of the module.

I explored how Spring Batch stores information about job instances, job executions, and step executions using a JDBC-backed JobRepository.

This made it possible to expose execution information through REST endpoints and understand what happened during a batch run.

Restartability

Restartability was particularly interesting.

A batch job can fail partway through execution, but that doesn't necessarily mean everything needs to start again.

Spring Batch can use persisted execution metadata and execution contexts to restore state and continue processing from where the job left off.

Skip and Retry

I also explored skip and retry policies.

Not every processing failure should necessarily stop an entire batch job.

Some records may be invalid and can be skipped, while temporary failures may be worth retrying.

For example:

.faultTolerant()
.skipPolicy(skipPolicy)
.retryPolicy(retryPolicy)

This demonstrated how Spring Batch can handle different failure scenarios while allowing the overall job to complete when appropriate.

Batch Testing

Finally, I finished the module with batch testing.

Using @SpringBatchTest, JobOperatorTestUtils, and Spring Boot testing support, I explored how to test individual components, execute jobs and steps, verify execution metadata, and test step-scoped components.

One important lesson from this was that testing a batch application involves more than checking whether the final output is correct.

It is also important to verify execution status, read and write counts, commit counts, job parameters, and the behavior of individual steps.

The project is open source, and I'm continuing to build it as I learn:

🔗 GitHub: https://gith.ub/dsAQrAU5

🔗 GitLab: https://gitl.ab/gfDEyGH3

There’s still a long way to go, but completing Module 07 - Spring Batch feels like another important milestone. 🚀

Next up: Module 08 - Spring Integration continuing to explore the Spring ecosystem through small, focused, runnable examples.

One focused example at a time. 🚀

If you've worked with Spring Batch before, what do you find most useful in your batch applications - chunk processing, restartability, skip and retry, or something else?

java #springframework #springbatch #springboot #opensource #github #learninginpublic #backend #softwareengineering

🚀 Building Spring by Example V2: Completing Module 06 - Capstone Application

Mujuzi Moses  — Mon, 02 Nov 2026 12:55:52 +0000

When I started learning Spring, I noticed something about many of the tutorials I found.

They often showed how to use a feature, but not always why it worked or when you should choose one approach over another.

I learn best by building things and documenting what I discover, so I started a project called spring-by-example.

The idea is simple: instead of building one large application, I'm creating a collection of small, focused examples where each example explores a specific Spring concept with clear explanations, tests, and documentation.

I'm happy to say that I've now completed Module 06 - Capstone Application. 🎉

This module is a little different from the previous ones. Rather than focusing on individual Spring features, it brings together concepts explored throughout the project and demonstrates how they work together in complete applications.

The module covers:

Application Design and Architecture
Spring Boot
Spring Data and Persistence
REST APIs
Spring Security
Transaction Management
Modular Architecture with Spring Modulith
Application Testing
Integration Between Spring Technologies
End-to-End Application Verification

One of the most interesting parts of this module was exploring how to structure a Spring Boot application into well-defined modules.

Using Spring Modulith, I explored how to organize an application around business capabilities, establish clear module boundaries, manage dependencies, and communicate between modules using application events.

This helped reinforce an important architectural idea: even when building a monolithic application, you don't have to organize everything into one large, tightly coupled codebase.

I also explored how to test applications built with these technologies.

Testing individual components is important, but it is equally important to understand how those components behave when working together inside a running Spring application.

That led to the next example: integrating multiple Spring technologies.

For this example, I built an Order Management application using:

Spring Boot
Spring Data JPA
Spring Web
Spring Security
Spring Modulith
Transaction Management
Application Events

The application is organized into four business modules:

Catalog - manages product information.
Inventory - manages product stock and reservations.
Ordering - handles customer orders.
Audit - records important application events.

One of the workflows I particularly enjoyed implementing was order placement.

When a customer places an order, the application needs to coordinate several operations:

Retrieve the requested product.
Reserve the required inventory.
Create and persist the order.
Publish an application event.
Record the resulting audit entry.

These operations also need to respect transaction boundaries.

For example, if there isn't enough inventory, the order should not be persisted and the inventory reservation should be rolled back.

I also explored how to use @TransactionalEventListener with AFTER_COMMIT to process an order event after the original transaction has successfully committed.

The Audit module then records the event in a separate transaction using REQUIRES_NEW.

This was a useful way to see how Spring transactions, application events, and modular architecture can work together in a realistic business workflow.

Finally, I completed the module with End-to-End Application Verification.

This example focuses on verifying a running Spring application through its externally exposed HTTP endpoints rather than testing its internal implementation directly.

Using Java's HTTP Client, Jackson, and JUnit, I built tests that communicate with the Order Management application as an external client would.

The verification covers:

Retrieving publicly accessible products.
Authentication and authorization.
Customer and administrator access restrictions.
Placing orders and retrieving order history.
Verifying inventory updates.
Preventing customers from accessing another customer's orders.
Verifying audit entries after successful order placement.
Handling invalid quantities, insufficient inventory, and nonexistent products.

I also added a dedicated GitHub Actions workflow that starts the Order Management application, waits for it to become available, and executes the end-to-end verification tests.

An important distinction I explored here is that end-to-end tests depend on a running application. They are therefore executed separately from the regular Maven build, which allows contributors to run the standard build without having to start the dependent application.

What I particularly enjoyed about this final module was seeing how the individual concepts explored throughout Spring by Example V2 come together.

Modular architecture helps organize the application. Spring Data JPA handles persistence. Spring Security protects endpoints. Transactions maintain consistency. Application events support communication between modules. Testing and end-to-end verification help establish confidence that everything works together.

The goal isn't just to know how to use individual Spring annotations or dependencies.

The bigger goal is to understand how these technologies complement one another when building real applications.

The project is open source, and I've been building it one focused example at a time:

🔗 GitHub: https://gith.ub/dsAQrAU5

🔗 GitLab: https://gitl.ab/gfDEyGH3

With Module 06 - Capstone Application complete, another important milestone in Spring by Example V2 has been reached. 🚀

Six modules completed, with each one building on the knowledge gained from the previous modules.

There's still more to explore, but I'm enjoying the process of turning what I learn into practical, runnable examples that others can learn from too.

If you've built applications with Spring, how do you approach modular architecture, transaction management, and testing workflows that involve multiple Spring technologies?

I'd love to hear about your experiences.

java #springframework #springboot #springmodulith #springdata #springsecurity #softwareengineering #opensource #github #learninginpublic #backend

🚀 Building Spring by Example V2: Completing Module 05 - Spring Testing

Mujuzi Moses  — Mon, 26 Oct 2026 14:20:15 +0000

When I started learning Spring, I noticed something about many of the tutorials I found.

They often showed how to use a feature, but not always why it worked, what was happening behind the scenes, or how to test it properly.

I learn best by building things and documenting what I discover, so I started a project called Spring by Example V2.

I'm happy to say that I've now completed Module 05 - Spring Testing. 🎉

This module explored how to test Spring applications at different levels, from loading application contexts and testing individual web layers to verifying security behavior, database interactions, and integration with external resources.

The module covers:

Spring TestContext Framework
@SpringJUnitConfig
@SpringBootTest
Spring MVC Testing
Spring Test Slices
MockMvc
Transaction Testing
Spring Security Testing
Integration Testing
Testcontainers
Application Context Testing
Context Caching

One thing I particularly enjoyed about this module was understanding that testing a Spring application isn't just about writing assertions. It's also about knowing what you're testing, which parts of the application you're loading, and how to make tests reliable and maintainable.

I started with the Spring TestContext Framework, exploring how Spring integrates with testing frameworks such as JUnit Jupiter to manage application contexts, dependency injection, and the test lifecycle.

From there, I explored @SpringJUnitConfig and @SpringBootTest.

These annotations helped me understand the difference between testing with a specific Spring configuration and loading a full Spring Boot application context.

For example:

@SpringJUnitConfig(AppConfig.class)
class GreetingServiceTest {

    @Autowired
    private GreetingService greetingService;

    @Test
    void returnsGreeting() {
        assertEquals("Hello, Moses!", greetingService.greet("Moses"));
    }
}

The important idea is that Spring can provide the configured dependencies directly to the test, allowing us to verify application behavior within a Spring-managed environment.

Next came Spring MVC testing and test slices.

I explored how @WebMvcTest allows us to focus on the web layer without loading the entire application context.

Combined with MockMvc, this makes it possible to test HTTP requests, controller behavior, response status codes, and returned content without starting a real web server.

For example:

@WebMvcTest(GreetingController.class)
class GreetingControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @MockitoBean
    private GreetingService greetingService;

    @Test
    void returnsGreeting() throws Exception {
        when(greetingService.greet("Moses"))
                .thenReturn("Hello, Moses!");

        mockMvc.perform(get("/greetings")
                        .param("name", "Moses"))
                .andExpect(status().isOk())
                .andExpect(content().string("Hello, Moses!"));
    }
}

This approach helped me appreciate the value of testing a specific application layer while replacing its dependencies with controlled test doubles.

I also explored transaction testing.

Transactions are important in application development because they help maintain data consistency when multiple operations must succeed or fail together.

Testing transactional behavior helps verify that database changes behave as expected, including rollback scenarios where appropriate.

Spring Security testing was another important part of the module.

Security behavior needs to be tested just as carefully as business logic. It's not enough for an endpoint to return the expected response; we also need to verify that authentication and authorization rules are enforced correctly.

I then moved into integration testing.

Unlike tests that isolate a particular layer, integration tests help verify that multiple application components work together as expected.

This led to Testcontainers, which introduces another useful approach: running tests against real instances of dependencies, such as databases, using containers.

That distinction matters because an in-memory database or a mocked dependency may not reproduce every behavior of the actual system used in production.

I also explored application context testing and finished the module with context caching.

This was particularly interesting because it connected test correctness with test performance.

Creating a Spring application context can involve configuration processing, bean creation, and dependency injection. Repeating that work unnecessarily can make a test suite slow.

Spring's TestContext Framework addresses this by caching and reusing compatible application contexts across tests.

For example:

ApplicationContext firstContext =
        loadContext(FirstContextTest.class);

ApplicationContext secondContext =
        loadContext(SecondContextTest.class);

assertSame(firstContext, secondContext);

When both test classes use compatible configuration metadata, Spring can reuse the same application context.

I also explored @DirtiesContext, which tells Spring that a context should no longer be reused from the cache.

This helped me understand an important balance: context caching improves performance, but tests must still be designed with proper isolation in mind.

A shared application context doesn't automatically reset the state of every singleton bean between tests.

Looking back, this module reinforced an important lesson for me: good tests don't just tell us whether something works; they help us understand where it works, how its dependencies behave, and whether the application can be trusted when its components interact.

The goal isn't simply to learn how to write:

@Test
void shouldWork() {
    // ...
}

The bigger goal is to understand the different testing strategies available in Spring, when to use each one, and how to build confidence in application behavior without making the test suite unnecessarily slow or complicated.

The project is open source, and I'm continuing to build it as I learn:

🔗 GitHub: https://gith.ub/dsAQrAU5

🔗 GitLab: https://gitl.ab/gfDEyGH3

Five modules completed, and each one has been another opportunity to explore the Spring ecosystem in more depth. 🚀

Next up: Module 06 - Capstone Application - bringing together concepts from the preceding modules to build a cohesive, production-oriented application.

One focused example at a time. 🚀

If you've worked with Spring testing before, which testing approach do you find most valuable in your day-to-day development - @WebMvcTest, @SpringBootTest, integration testing, Testcontainers, or something else?

java #springframework #springboot #testing #junit #testcontainers #opensource #github #learninginpublic #backend #softwareengineering

🚀 Building Spring by Example V2: Completing Module 04 - Spring Modulith

Mujuzi Moses  — Mon, 19 Oct 2026 09:04:45 +0000

When I started learning Spring, I noticed something about many of the tutorials I found.

They often showed how to use a feature, but not always why it worked or how different parts of an application fit together.

I learn best by building things and documenting what I discover, so I started Spring by Example V2.

I’m happy to say that I’ve now completed Module 04 - Spring Modulith. 🎉

This module helped me explore modular monolith architecture and understand how Spring Modulith supports the development of well-structured Spring applications.

The module covers:

Application Modules
Module Boundaries
Module Dependencies
Application Events
Event Externalization
Module Verification
Module Documentation
Module Testing

One thing I enjoyed about this module was learning how to organize an application into modules with clear responsibilities instead of allowing everything to become tightly coupled.

Module boundaries help define which parts of an application belong together and how they interact. Spring Modulith also provides tools for verifying module structure and detecting unwanted dependencies.

Application events introduced another useful concept: components can communicate through events without needing to depend directly on the components that handle them.

I also explored module verification, documentation, and testing, which help make modular architecture more than just a package-organization decision.

The goal isn’t simply to create separate packages. It’s to understand how to establish meaningful boundaries, manage dependencies, and keep an application maintainable as it grows.

The project is open source, and I’m continuing to build it as I learn:

🔗 GitHub: https://gith.ub/dsAQrAU5

🔗 GitLab: https://gitl.ab/gfDEyGH3

There’s still a long way to go, but completing Module 04 — Spring Modulith feels like another important milestone. 🚀

Next up: Module 05 - Spring Testing, where I’ll explore the Spring TestContext Framework, @SpringJUnitConfig, @SpringBootTest, test slices, MockMvc, integration testing, and more.

One focused example at a time. 🚀

If you’ve worked with Spring Modulith before, what has helped you most when designing modular Spring applications?

java #springframework #springboot #springmodulith #opensource #github #learninginpublic #backend #softwareengineering

🚀 Building Spring by Example V2: Completing Module 03 - Reactive Spring

Mujuzi Moses  — Tue, 13 Oct 2026 10:37:55 +0000

When I started learning Spring, I noticed something about many of the tutorials I found.

They often showed how to use a feature, but not always why it worked or when you should choose one approach over another.

I learn best by building things and documenting what I discover, so I started a project called spring-by-example-v2.

I’m happy to say that I’ve now completed Module 03 - Reactive Spring! 🎉

This module was an opportunity to explore a different way of building applications with Spring. Rather than focusing only on traditional blocking operations, I explored reactive programming, asynchronous data processing, and how Spring WebFlux works with Project Reactor.

The module covers:

Project Reactor
Mono and Flux
Reactive Pipelines
Backpressure
Spring WebFlux
Reactive Controllers
Reactive Clients
Reactive Data Access
Reactive Error Handling
Reactive Testing

Understanding Mono and Flux

One of the first things I explored was the difference between Mono and Flux.

In Project Reactor, these are two fundamental types for representing asynchronous sequences of data.

A Mono represents a sequence that produces at most one item, while a Flux represents a sequence that can produce zero to many items.

For example:

Mono<String> greeting = Mono.just("Hello, Spring!");

Flux<String> greetings = Flux.just("Hello", "from", "Reactive Spring");

These types don't simply represent values or collections. They represent publishers that can participate in a reactive pipeline.

That distinction helped me understand why reactive code often looks different from traditional Java code.

Building Reactive Pipelines

After learning the basics, I explored how reactive pipelines are composed.

Instead of processing data through a sequence of blocking method calls, Reactor allows operations to be chained together using operators such as map, filter, and flatMap.

For example:

Flux<String> names = Flux.just("Moses", "John", "Mary");

Flux<String> filteredNames = names
        .filter(name -> name.length() > 4)
        .map(String::toUpperCase);

Here, the pipeline filters the names and transforms the remaining values.

Exploring these operators helped me understand how data flows through a reactive sequence and how individual operations can be composed into larger processing pipelines.

Understanding Backpressure

Backpressure was another important concept in this module.

A publisher may produce data faster than a subscriber can process it. Backpressure provides a mechanism through which demand can be communicated so that data processing can be better coordinated.

This introduced me to the relationship between publishers, subscribers, and demand in reactive streams.

It also helped me understand that reactive programming isn't simply about using asynchronous APIs. It involves thinking carefully about how data is produced, consumed, and managed throughout a pipeline.

Bringing Reactive Programming into Spring WebFlux

Once I had explored the Reactor fundamentals, I moved into Spring WebFlux.

I worked through reactive controllers, reactive clients, and reactive data access to understand how reactive programming fits into a Spring application.

One of the important distinctions I explored was that returning a Mono or Flux from a controller doesn't automatically make every operation in the application non-blocking.

The underlying operations matter too.

For example, a reactive controller that calls a blocking database driver can still introduce blocking work into the request-processing flow.

Understanding this distinction helped me appreciate why WebFlux works best when the application uses compatible non-blocking components throughout the relevant execution path.

Reactive Error Handling

Errors are an inevitable part of application development, and reactive pipelines introduce their own ways of handling them.

I explored how errors propagate through a pipeline and how Reactor operators can be used to recover from certain failures.

For example:

Mono<String> result = Mono.error(
        new IllegalStateException("Something went wrong")
).onErrorReturn("Fallback value");

Instead of allowing the error to terminate the sequence without recovery, onErrorReturn provides a fallback value.

This helped me understand error handling as part of the reactive pipeline rather than treating it as something separate from the data-processing flow.

Testing Reactive Applications

One of my favourite parts of this module was reactive testing.

Testing reactive code requires more than checking the final value returned by a method. Depending on the behavior being tested, we may also need to verify emitted items, completion signals, errors, timing, and demand.

I explored StepVerifier from Project Reactor's testing utilities.

For example:

StepVerifier.create(Flux.just("Spring", "WebFlux", "Reactor"))
.expectNext("Spring")
.expectNext("WebFlux")
.expectNext("Reactor").verifyComplete();

This test verifies the sequence of emitted values and confirms that the publisher completes successfully.

I also explored:

WebTestClient for testing reactive web endpoints.
Virtual-time testing for time-dependent reactive sequences without waiting for real delays.
Error testing for verifying how publishers behave when failures occur.
Backpressure testing for checking how publishers respond to subscriber demand.

These examples helped me see that reactive behavior can be tested explicitly rather than relying only on assumptions about how the pipeline should work.

What I Took Away from This Module

The biggest lesson from this module is that reactive programming is not just about replacing return types with Mono and Flux.

It's about understanding asynchronous sequences, composing operations, handling errors, managing demand, and choosing the right components for the execution model.

I also learned to pay more attention to the difference between writing reactive code and building an application that is genuinely non-blocking across its relevant processing path.

As with the previous modules, the goal wasn't to build one large application that uses every feature.

It was to create small, focused examples that make each concept easier to understand, test, and revisit later.

With Spring Data and Reactive Spring now complete, spring-by-example-v2 continues to grow as a practical learning resource covering different parts of the Spring ecosystem.

The project is open source, and I'm continuing to build it as I learn:

🔗 GitHub: https://gith.ub/dsAQrAU5

🔗 GitLab: https://gitl.ab/gfDEyGH3

Completing Module 03 - Reactive Spring feels like another important milestone in this journey. 🚀

There are still more Spring concepts to explore, more examples to build, and more things to learn.

One focused example at a time.

If you've worked with reactive programming in Spring, what was the biggest learning curve for you - understanding Reactor, handling backpressure, testing reactive pipelines, or knowing when to choose WebFlux over Spring MVC?

Java #SpringFramework #SpringBoot #ProjectReactor #SpringWebFlux #ReactiveProgramming #OpenSource #LearningInPublic #BackendDevelopment #SoftwareEngineering

🚀 Building Spring by Example V2: Completing Module 02 -Spring Data

Mujuzi Moses  — Wed, 07 Oct 2026 13:58:37 +0000

When I started learning Spring, I noticed something about many of the tutorials I found.

They often showed how to use a feature, but not always why it worked or when you should choose one approach over another.

I learn best by building things and documenting what I discover, so I started a project called spring-by-example.

I’m happy to say that I’ve now completed Module 02 - Spring Data. 🎉

This module took me from the fundamentals of Spring Data repositories to more advanced ways of querying, mapping, and testing data.

The module covers:

Spring Data Repositories
CrudRepository
Query Methods
@Query
Entity Mapping
Entity Relationships
Transactions
Pagination
Specifications
Projections
Auditing
Custom Repositories
Database Testing

One thing I really enjoyed about this module was seeing how much Spring Data can handle while still allowing you to take control when you need to.

I started with repository abstractions and CrudRepository, then explored how Spring Data can derive queries directly from method names.

For example:

List<Person> findByAgeGreaterThan(int age);

There's no SQL or JPQL in the method itself, but Spring Data can interpret the method name and create the appropriate query.

From there, I explored @Query for cases where defining the query explicitly makes more sense.

Then came entity mapping and relationships.

Working with @OneToOne, @OneToMany, @ManyToOne, and @ManyToMany helped me understand how object relationships are represented in the persistence layer rather than simply treating entities as isolated classes.

Transactions were another important part of the module.

I explored how multiple database changes can be grouped into a single transactional operation and, more importantly, how a failure partway through an operation can cause those changes to be rolled back.

Pagination and Specifications then showed two different ways of building more flexible queries.

With Specifications, I could compose criteria dynamically:

Specification<Person> specification =
        PersonSpecifications.nameContains("Jan")
                .and(PersonSpecifications.ageGreaterThan(30));

Projections introduced another useful idea: sometimes you don't need the entire entity.

Instead, you can retrieve only the data required by a particular use case.

I also explored auditing with annotations such as:

@CreatedDate
@LastModifiedDate
@CreatedBy
@LastModifiedBy

This helped me understand how Spring Data can automatically track information about when an entity was created or modified and who performed the operation.

Custom repositories were another interesting step.

Instead of relying entirely on derived queries and @Query, I explored repository fragments and how a custom implementation can be composed with a Spring Data repository.

Finally, I finished the module with database testing.

Using @DataJpaTest, H2, and @Sql, I explored how repository behavior can be tested against an actual database rather than relying only on mocks.

That distinction was particularly useful because a mocked repository cannot tell you whether a JPQL query, entity mapping, or derived query actually works against the database.

The goal isn’t just to learn how to write:

PersonRepository

The bigger goal is to understand what Spring Data is doing for me, where its conventions help, and when I should take more control.

The project is open source, and I’m continuing to build it as I learn:

🔗 GitHub: https://gith.ub/dsAQrAU5

🔗 GitLab: https://gitl.ab/gfDEyGH3

There’s still a long way to go, but completing Module 02 - Spring Data feels like another important milestone. 🚀

Next up: Module 03 - Reactive Spring - moving from traditional blocking application development into reactive programming with Spring.

One focused example at a time. 🚀

If you’ve worked with Spring Data before, which feature do you find most useful in your day-to-day development - derived queries, Specifications, projections, transactions, or something else?

java #springframework #springdata #springboot #opensource #github #learninginpublic #backend #softwareengineering

🚀 Starting Spring by Example V2: Completing Module 01 -Spring Security

Mujuzi Moses  — Wed, 30 Sep 2026 10:38:53 +0000

When I started learning Spring, I noticed that many tutorials showed how to use Spring features, but didn't always explain how the different pieces fit together.

I learn best by building and documenting what I discover, so I started Spring by Example.

The idea is simple: build small, focused examples that explore specific Spring concepts through code, tests, and documentation.

After completing the first version of the project, I decided to start a new chapter: Spring by Example V2.

Why V2?

V2 keeps the same philosophy but expands the scope.

The goal is to explore the modern Spring ecosystem through small but extensive examples, covering areas such as:

Spring Security
Spring Data
Reactive Spring
Spring Modulith
Spring Testing
Capstone Application
Spring Batch
Spring Integration
Spring Cloud
Spring AI
GraalVM Native
Kotlin

Small examples. Extensive coverage.

And I'm happy to say that Module 01 - Spring Security is now complete! 🎉

Module 01 - Spring Security

The module contains focused examples covering:

Basic Spring Security
SecurityFilterChain
Authentication
UserDetailsService
Password Encoding
Authorization
SecurityContext
Method Security
CSRF Protection
Session Management
OAuth2 Login
JWT Authentication
Spring Security Testing

One of the biggest things I wanted to understand was how these pieces fit together.

A simplified view looks like:

HTTP Request
     ↓
Security Filter Chain
     ↓
Authentication
     ↓
Authorization
     ↓
SecurityContext
     ↓
Application

The goal wasn’t simply to memorize Spring Security annotations.

It was to understand what each component does, where it fits, and how the pieces work together.

That’s the approach I want to continue throughout V2.

What’s Next?

With Spring Security complete, Module 02 - Spring Data is next.

I’ll be exploring repositories, entity mapping, queries, pagination, specifications, auditing, projections, transactions, and custom repository implementations.

The project is open source:

🔗 GitHub: https://gith.ub/dsAQrAU5

🔗 GitLab: https://gitl.ab/gfDEyGH3

One focused example at a time. 🚀

If you’ve worked with Spring Security before, what part helped you understand it better?

java #spring #springframework #springboot #springsecurity #opensource #github #learninginpublic #backend #softwareengineering #programming

🚀 Building Spring by Example: Completing the OpenMRS Examples Module

Mujuzi Moses  — Wed, 23 Sep 2026 11:58:45 +0000

When I started learning Spring, I noticed something about many of the tutorials I found.

They often showed how to use a feature, but not always what was happening behind the scenes or how the different pieces of the framework worked together.

I learn best by building things and documenting what I discover, so I started a project called spring-by-example.

I’m happy to say that I’ve now completed Module 14 - OpenMRS Examples. 🎉

But this milestone is a little more significant than completing another module.

Module 14 is the final module and final example of Spring by Example V1.

That means V1 of spring-by-example is now complete. 🚀

From Learning Spring to Studying Real-World Code

This module was different from the previous ones because it moved away from studying Spring only through isolated examples and focused on how Spring concepts are applied in a real-world, open-source application.

For this module, I used OpenMRS as the real-world reference.

OpenMRS is an open-source electronic medical record platform, and its codebase provided a much more realistic environment for exploring how Spring is used in a large application.

Instead of simply asking:

"How does this Spring feature work?"

I wanted to ask:

"How is this Spring feature actually used in a real application?"

and:

"Why was it implemented this way?"

The goal of this module was not to reproduce the entire OpenMRS codebase.

Instead, I created focused examples based on patterns and concepts found in OpenMRS, while keeping each example small enough to understand independently.

The module explored areas such as:

Service Registration
Module Loading
XML to Java Configuration
OpenmrsBeanRegistrar
ServiceContext
AOP in OpenMRS
Transaction Management
Custom Spring Profiles

One of the things I found particularly valuable was seeing how the concepts from the previous modules connect when they're no longer isolated examples.

For example, after learning about dependency injection, bean definitions, BeanPostProcessor, transactions, and AOP proxies, it's one thing to understand each concept individually.

It's another thing to encounter them together in a real application and understand why they are there and how they interact.

That was one of the main goals of this module.

The Journey Through V1

The progression of Spring by Example V1 now looks something like this:

Spring Core
     │
     ▼
Dependency Injection
     │
     ▼
Bean Lifecycle
     │
     ▼
Events
     │
     ▼
AOP
     │
     ▼
Transactions
     │
     ▼
Spring Boot
     │
     ▼
Spring MVC
     │
     ▼
Testing
     │
     ▼
Advanced Spring
     │
     ▼
Spring Internals
     │
     ▼
OpenMRS Examples
     │
     ▼
   V1 DONE 🎉

Looking back at the progression, each module added another layer of understanding.

I started with the fundamentals of Spring and gradually moved into dependency injection, bean lifecycle, events, AOP, transactions, Spring Boot, Spring MVC, testing, and more advanced Spring concepts.

Then I went deeper into Spring Internals to understand what was happening behind many of those features.

Finally, OpenMRS Examples brought those ideas into the context of a real-world application.

What I Took Away

One of the biggest lessons from this journey is that understanding a framework isn't only about knowing its annotations and APIs.

It's also about understanding how those pieces are used together to solve problems in a larger system.

A simple annotation such as @Autowired or @Transactional can look straightforward when used in a small example.

In a real application, however, it can be connected to configuration, proxies, bean lifecycle processing, transactions, service layers, persistence, testing, and many other parts of the system.

Looking at these interactions made the concepts from the earlier modules feel much more concrete.

The goal of the project was never to simply collect Spring annotations and interfaces.

I wanted to understand how Spring works, why these features exist, and how the different pieces fit together.

Building small examples made the concepts easier to explore.

Studying Spring's internals helped me understand what was happening underneath.

And studying OpenMRS helped me see how those concepts can come together in a much larger application.

V1 Is Complete

After all the modules, examples, tests, documentation, and experiments, Spring by Example V1 is officially complete. 🎉

This isn't the end of the project.

It's the end of V1.

The project started as a way for me to learn Spring by building small examples instead of simply reading about the framework.

Over time, it grew into a structured journey through different areas of the Spring ecosystem.

And now I have a complete V1 that I can look back on as a record of what I learned.

The next stage will be about deciding what Spring by Example V2 should look like and where to take the project from here.

For now, though, I'm taking a moment to appreciate reaching this milestone.

14 modules.

One focused example at a time.

Spring by Example V1 — complete. 🚀

Open Source

The project is open source, and the complete V1 is available here:

🔗 GitLab https://gitl.ab/gfDEyGH3

🔗 GitHub https://gith.ub/dsAQrAU5

Completing Module 14 - OpenMRS Examples helped me connect those concepts to a real-world application.

And completing Module 14 means something even bigger:

The final example of Spring by Example V1 is complete.

There’s still a long way to go, but reaching this milestone feels like an important point in the journey. 🚀

Spring by Example V1 — DONE.

Now, let's see what V2 brings.

java #springframework #opensource #github #learninginpublic #backend #softwareengineering #spring #springboot #openmrs #programming

🚀 Building Spring by Example: Completing the Spring Internals Module

Mujuzi Moses  — Fri, 18 Sep 2026 12:31:13 +0000

When I started learning Spring, I noticed something about many of the tutorials I found.

They often showed how to use a feature, but not always what was happening behind the scenes or how the different pieces of the framework worked together.

I learn best by building things and documenting what I discover, so I started a project called spring-by-example.

I’m happy to say that I’ve now completed Module 13 - Spring Internals. 🎉

This module was particularly interesting because it went beyond using Spring features and focused on understanding what happens behind the scenes.

Instead of simply writing @Autowired, @Transactional, or @Component and letting Spring handle everything, I wanted to understand what Spring is actually doing with those annotations and how the different pieces of the container work together.

The module covers:

How Beans Are Registered
How Dependency Injection Works
How Component Scanning Works
How @Autowired Works
How @Transactional Works
How AOP Proxies Are Created
How Bean Post Processors Work
Understanding DefaultListableBeanFactory
Understanding ConfigurationClassPostProcessor

One of the first things I explored was how beans are registered.

I already knew that Spring manages beans, but looking at BeanDefinition and DefaultListableBeanFactory helped me understand an important distinction: registering a bean definition is not the same thing as creating the bean itself.

Spring can first work with metadata describing a bean and later use that metadata to create and manage the actual object.

That led naturally into dependency injection.

Instead of looking at dependency injection only from the perspective of annotations, I explored concepts such as DependencyDescriptor, MethodParameter, and resolveDependency().

This helped me see dependency injection as a process of identifying an injection point, resolving the required dependency, and obtaining the appropriate bean from the container.

Then I explored component scanning.

Using @Component is something I've done many times, but looking at ClassPathBeanDefinitionScanner made the process much clearer.

A class annotated with @Component doesn't magically become a Spring bean. Spring has to discover it during scanning, create a corresponding BeanDefinition, and register that definition with the container.

Then came @Autowired.

One of the most useful lessons here was understanding that @Autowired itself doesn't perform the injection.

It provides metadata that AutowiredAnnotationBeanPostProcessor detects and processes.

I also explored @Transactional.

Rather than hiding transaction management behind Spring's higher-level configuration, I worked directly with TransactionInterceptor, TransactionAttributeSource, AnnotationTransactionAttributeSource, and PlatformTransactionManager.

Another particularly interesting part was AOP proxy creation.

I used ProxyFactory and MethodInterceptor to see how a proxy can sit between the caller and the target object.

Then I looked at BeanPostProcessor.

This was another important piece of the puzzle because it showed how Spring can intercept and modify bean instances during their lifecycle.

I also explored how a post processor can return the original bean or even replace it with another object.

After working with all these individual mechanisms, I reached DefaultListableBeanFactory.

This was probably one of the most important pieces for putting everything together.

It helped me see why the bean factory is so central to Spring's internals.

It brings together responsibilities around bean definitions, bean lookup, dependency resolution, singleton management, and bean creation.

Finally, I explored ConfigurationClassPostProcessor.

This connected many of the concepts from earlier examples.

@Configuration, @Bean, @ComponentScan, and @Import are all configuration metadata that Spring needs to process.

ConfigurationClassPostProcessor participates in turning that configuration metadata into bean definitions that can ultimately be managed by the bean factory.

The bigger picture started to look something like this:

Configuration Metadata
        │
        ▼
ConfigurationClassPostProcessor
        │
        ▼
BeanDefinitions
        │
        ▼
DefaultListableBeanFactory
        │
        ▼
Dependency Resolution
        │
        ▼
Bean Creation
        │
        ▼
BeanPostProcessors
        │
        ├── @Autowired
        └── AOP-related processing

Of course, this is a simplified model of Spring's internals, but having this mental model makes the framework feel much less like magic.

And I think that's what made this module particularly valuable.

The goal wasn't just to learn more Spring classes or memorize internal APIs.

It was to understand the machinery underneath the features I've already been using.

Instead of thinking:

"Spring does this."

I can now start asking:

"Which part of Spring does this, and at what stage of the container lifecycle?"

That shift in perspective is probably the biggest thing I'm taking away from this module.

After completing modules covering Spring Core, dependency injection, bean lifecycle, events, AOP, transactions, Spring Boot, Spring MVC, testing, Advanced Spring, and now Spring Internals, the project continues to grow into something much bigger than I originally imagined.

The goal still isn't to simply collect Spring annotations and interfaces.

I'm trying to understand how Spring works, why these features exist, and how the different pieces of the framework fit together - one focused example at a time.

The project is open source, and I'm continuing to build it as I learn:

🔗 GitLab: https://gitl.ab/gfDEyGH3

🔗 GitHub: https://gith.ub/dsAQrAU5

There’s still a long way to go, but completing Module 13 - Spring Internals feels like another important milestone in this learning journey. 🚀

And now comes the next stage.

Next up: Module 14 - OpenMRS Examples.

This time, instead of focusing only on isolated Spring concepts, I'll be looking at how these concepts are actually applied in a real-world project.

I'm especially looking forward to this module because it brings everything closer to the kind of code found in a real production system.

One focused example at a time. 🚀

If you've worked with Spring internals before, what's one part of the Spring container that helped you understand the framework better?

java #springframework #opensource #github #learninginpublic #backend #softwareengineering #spring #springboot #openmrs #programming

🚀 Building Spring by Example: Completing the Advanced Spring Module

Mujuzi Moses  — Tue, 15 Sep 2026 08:16:00 +0000

When I started learning Spring, I noticed something about many of the tutorials I found.

They often showed how to use a feature, but not always why it worked or when you should choose one approach over another.

I learn best by building things and documenting what I discover, so I started a project called spring-by-example.

I’m happy to say that I’ve now completed Module 12 - Advanced Spring. 🎉

This module was a particularly interesting one because it moved beyond the higher-level features I had been using and gave me a closer look at some of the abstractions and extension points that make Spring work.

The module covers:

BeanFactory
ApplicationContext
FactoryBean
BeanDefinition
BeanDefinitionRegistry
ImportSelector
DeferredImportSelector
ImportBeanDefinitionRegistrar
Environment
Property Sources
Resource Loading
MessageSource
ConversionService
Validation
Spring Expression Language (SpEL)
Method Injection
@Lookup

One of the things I really enjoyed about this module was seeing how much of Spring's behavior is built around the application context, bean definitions, and the container itself.

For example, BeanDefinition helped me understand that Spring doesn't immediately need an object instance to know how a bean should be created. Instead, it can work with metadata describing the bean.

BeanDefinitionRegistry then showed how those definitions can be registered and managed programmatically.

The configuration-related examples went even deeper. With ImportSelector, DeferredImportSelector, and ImportBeanDefinitionRegistrar, I explored different ways Spring can dynamically select configuration or register bean definitions during application context processing.

I also explored the Environment and property sources, which helped connect Spring's environment abstraction with how configuration values can be provided and resolved from different sources.

The Resource abstraction and MessageSource introduced another side of Spring: providing consistent APIs for accessing resources and resolving localized messages.

With ConversionService and Spring validation, I explored how Spring provides reusable infrastructure for type conversion and object validation rather than requiring every application to implement these concerns independently.

Then came SpEL - Spring Expression Language - which was a great example of how Spring provides its own expression engine for evaluating values, properties, variables, and expressions.

Finally, I explored Method Injection and @Lookup, including the interesting singleton/prototype problem where a singleton bean needs to obtain a new prototype instance whenever a method is called.

What made this module especially meaningful is that it wasn't just about learning more Spring APIs. It gave me a better understanding of the machinery underneath the features I've already been using.

And there's another milestone worth mentioning: SpEL was my 100th example in the project. 🎉

After building examples across Spring Core, dependency injection, bean lifecycle, events, AOP, transactions, Spring Boot, Spring MVC, testing, and now Advanced Spring, reaching 100 examples feels like a significant milestone in this learning journey.

The goal still isn't to simply collect Spring annotations and interfaces.

I'm trying to understand how Spring works, why these features exist, and how the different pieces of the framework fit together - one focused example at a time.

The project is open source, and I’m continuing to build it as I learn:

🔗 GitLab: https://gitl.ab/gfDEyGH3

🔗 GitHub: https://gith.ub/dsAQrAU5

There’s still a long way to go, but completing Module 12 - Advanced Spring and reaching 100 examples feels like a milestone worth celebrating. 🚀

Next up: continuing with the next stage of the project and exploring more Spring concepts, one example at a time.

If you’ve worked with Spring before, what’s one advanced Spring concept you think developers should understand better?

java #springframework #opensource #github #learninginpublic #backend #softwareengineering #spring #springboot #programming

🚀 Building Spring by Example: Completing the Spring Testing Module

Mujuzi Moses  — Mon, 07 Sep 2026 09:03:28 +0000

When I started learning Spring, I noticed something about many of the tutorials I found.

They often showed how to use a feature, but not always why it worked or when you should choose one approach over another.

I learn best by building things and documenting what I discover, so I started a project called spring-by-example.

I’m happy to say that I’ve now completed Module 11 - Spring Testing. 🎉

The module covers:

Unit Testing with JUnit
Spring TestContext
@SpringBootTest
@MockitoBean
@TestConfiguration
Integration Testing

One of the things I enjoyed about this module was understanding the different levels at which a Spring application can be tested.

I started with unit testing, where the goal is to test a class in isolation without starting the Spring application context. This helped reinforce the idea that not every test needs Spring.

I then moved into the Spring TestContext, where Spring can create and manage the application context for tests. This makes it possible to test components using the same dependency injection and configuration mechanisms used by the application.

From there, I explored @SpringBootTest and how it can be used to load the full Spring Boot application context. This helped connect the concepts of application startup, component scanning, dependency injection, and testing.

I also explored mocking Spring-managed dependencies. With Spring Boot 4, the approach uses @MockitoBean to replace a bean in the test context with a Mockito mock. This makes it possible to isolate the component being tested while still using Spring's dependency injection.

Another interesting part was @TestConfiguration, which allows test-specific beans to be defined without changing the production configuration. This was a useful way to understand how Spring's configuration system can be customized specifically for tests.

Finally, I explored integration testing, where multiple parts of the application work together instead of being tested in isolation.

The integration testing example uses a controller, service, and repository together, starts the application on a random port, and makes a real HTTP request using TestRestTemplate.

That helped put the previous testing concepts together and made the distinction between unit tests and integration tests much clearer.

The goal isn’t just to collect Spring annotations and APIs. I’m trying to understand how Spring works under the hood, how its features fit together, and why these features exist, one concept at a time.

The project is open source, and I’m continuing to build it as I learn:

🔗 GitHub: https://gith.ub/dsAQrAU5

🔗 GitLab: https://gitl.ab/gfDEyGH3

There’s still a long way to go, but completing another module feels like a good milestone. 🚀

Next up: Module 12 - continuing deeper into the Spring ecosystem and building on the concepts covered so far.

If you’ve worked with Spring testing before, what’s one testing concept you think developers commonly misunderstand?

java #springframework #opensource #github #gitlab #learninginpublic #backend #softwareengineering #spring #testing #junit

🚀 Building Spring by Example: Completing the Spring Web (Spring MVC) Module

Mujuzi Moses  — Wed, 02 Sep 2026 10:00:21 +0000

When I started learning Spring, I noticed something about many of the tutorials I found.

They often showed how to use a feature, but not always why it worked or when you should choose one approach over another.

I learn best by building things and documenting what I discover, so I started a project called spring-by-example.

I’m happy to say that I’ve now completed Module 10 — Spring Web (Spring MVC). 🎉

The module covers:

DispatcherServlet
Controllers
Request Mapping
Path Variables
Request Parameters
Request Body
Response Body
Model and View
View Resolvers
Exception Handling
Request Scope
Session Scope
Application Scope

One of the things I enjoyed about this module was understanding what actually happens when an HTTP request enters a Spring MVC application.

The DispatcherServlet acts as the front controller, receiving incoming requests and coordinating the request-handling process. Controllers then define how those requests should be handled using mappings such as @GetMapping and @PostMapping.

I also explored different ways of working with request data, including path variables, request parameters, and request bodies, as well as how Spring converts incoming data into Java objects.

The view-related examples helped connect the pieces between a controller, a model, and a view. ModelAndView can be used to return both model data and a logical view name, while ViewResolver determines which actual view should be rendered.

Exception handling was another important part of the module. Using mechanisms such as @ExceptionHandler and @ControllerAdvice, it becomes possible to keep error-handling logic organized instead of putting it directly into every controller.

Finally, I explored Spring's web scopes - request, session, and application scope — and how the lifetime of a bean can be tied to the lifecycle of an HTTP request, user session, or web application.

The project is open source, and I’m continuing to build it as I learn:

🔗 GitHub: https://gith.ub/dsAQrAU5

🔗 GitLab: https://gitl.ab/gfDEyGH3

There’s still a long way to go, but completing another module feels like a good milestone. 🚀

Next up: Module 11 - Testing - exploring how to test Spring applications, starting with unit testing and the Spring TestContext, followed by @SpringBootTest, @MockBean, @TestConfiguration, and integration testing.

If you’ve worked with Spring MVC before, what’s one part of the request-handling process you think developers commonly misunderstand?

java #springframework #opensource #github #gitlab #learninginpublic #backend #softwareengineering #spring #springmvc