DEV Community: Mujuzi Moses 

🚀 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.

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 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

🚀 Building Spring by Example: Completing the Spring Boot Module

Mujuzi Moses  — Thu, 27 Aug 2026 08:50: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 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 9 — Spring Boot. 🎉

This module focused on the foundations of Spring Boot and covered:

SpringApplication
Auto Configuration
Starter Dependencies
Configuration Properties
Profiles
CommandLineRunner
Actuator

One of the things I enjoyed most about this module was seeing how much Spring Boot does behind the scenes while still allowing us to understand and control what is happening.

I started with SpringApplication, exploring how SpringApplication.run() bootstraps a Spring Boot application and creates the application context.

Then I explored Auto Configuration, which showed how Spring Boot can automatically configure application infrastructure based on the dependencies available on the classpath.

Starter Dependencies were another important piece. Instead of manually adding and managing every dependency needed for a particular feature, Spring Boot starters provide convenient dependency groupings that bring the required libraries together.

I also explored Configuration Properties, which demonstrated how application configuration can be externalized rather than hard-coded into the application.

With Profiles, I looked at how Spring applications can use different configurations depending on the active environment, such as development, testing, or production.

CommandLineRunner introduced a simple way to execute code when the application starts, which is useful for initialization tasks and understanding the application startup lifecycle.

Finally, Actuator showed how Spring Boot applications can expose operational information such as health endpoints. Seeing /actuator/health return an UP status was a nice way to finish the module.

What I’m enjoying about Spring Boot is that it isn't just about reducing configuration.

It provides conventions and sensible defaults while still allowing developers to understand and customize the underlying Spring infrastructure.

The goal of this project isn't just to collect Spring Boot annotations and APIs. I'm trying to understand what Spring is doing underneath the surface, 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: Spring Web (Spring MVC) — exploring DispatcherServlet, controllers, request mapping, request parameters, request bodies, views, exception handling, and request/session/application scopes.

If you've worked with Spring Boot before, what Spring Boot feature made the biggest difference in your day-to-day development?

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

🚀 Building Spring by Example: Completing the Spring Transactions Module

Mujuzi Moses  — Mon, 24 Aug 2026 08:54:17 +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 8 — Transactions. 🎉

The module covers:

@Transactional
Transaction Propagation
Isolation Levels
Rollback Rules
Programmatic Transactions
TransactionProxyFactoryBean

One of the most interesting parts of this module was understanding what actually happens when Spring manages a transaction.

For example, @Transactional makes it possible to declaratively define transaction boundaries without having to manually begin, commit, or roll back transactions in application code.

Transaction propagation introduced another important concept: what should happen when a transactional method calls another transactional method?

I explored propagation behaviors such as REQUIRED and REQUIRES_NEW, and how they affect whether operations participate in the same transaction or run in an independent transaction.

Isolation levels then showed another side of transaction management: how concurrent transactions interact with data and what kinds of visibility and consistency guarantees they provide.

Rollback rules were another useful area to explore. A transaction does not necessarily roll back for every exception automatically, so understanding how Spring determines whether a transaction should be rolled back is important when designing transactional services.

I also explored programmatic transactions, which provide more explicit control over transaction boundaries when declarative transaction management isn't the right fit.

Finally, I looked at TransactionProxyFactoryBean, an older Spring approach to applying transaction management through proxies. It was especially useful for understanding how Spring's transaction infrastructure evolved and how it connects to the proxy concepts explored in the previous AOP module.

The goal isn’t just to collect Spring annotations and APIs. I’m trying to understand how the Spring container works, 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: githu.b/sbe

🔗 GitLab: gitla.b/sbe

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

Next up: Spring JDBC — continuing to explore how Spring works with databases and how its abstractions simplify database access.

If you’ve worked with Spring before, what part of Spring's transaction management do you think developers commonly misunderstand?

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

🚀 Building Spring by Example: Completing the Spring AOP Module

Mujuzi Moses  — Thu, 20 Aug 2026 10:02: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 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 7 — Spring AOP. 🎉

The module covers:

What is AOP?
JDK Dynamic Proxies
CGLIB Proxies
Creating an Aspect
Before Advice
After Advice
After Returning Advice
Around Advice
Pointcuts
Advice Ordering

One of the most interesting parts of this module was understanding that Spring AOP is built around proxies.

Before getting into Spring's AOP abstractions, I explored JDK Dynamic Proxies and CGLIB proxies separately. That made it easier to understand what Spring is doing behind the scenes when it creates an AOP proxy around a Spring-managed bean.

For example, instead of manually creating a proxy, Spring can use an aspect such as:

@Aspect
public class LoggingAspect {

    @Before("execution(* com.springbyexample.GreetingService.greet(..))")
    public void beforeGreeting() {
        System.out.println("Before greeting");
    }
}

Spring then uses the pointcut to determine which method calls should receive that behavior.

That led into another important concept: advice.

I explored several different types of advice:

@Before — runs before the target method.
@After — runs after the method invocation completes.
@AfterReturning — runs when the method returns successfully.
@Around — surrounds the target invocation and gives the advice control over when the target executes through ProceedingJoinPoint.

Around advice was particularly interesting because proceed() determines whether the target method actually gets invoked.

I also explored pointcuts, which helped clarify an important distinction:

Pointcut
    ↓
Where should the advice apply?

Advice
    ↓
What should happen?

For example:

@Before("execution(* com.springbyexample.GreetingService.greet(..))")

uses the pointcut to tell Spring which method should be intercepted.

Finally, I looked at advice ordering.

When multiple aspects apply to the same method, @Order can be used to control their precedence. Lower order values have higher precedence, and the ordering becomes especially interesting when looking at how @Before and @After advice execute around the target method.

One of the things I wanted to understand through these examples was not just how to write an aspect, but what is actually happening when a method call goes through Spring AOP:

Caller
   ↓
Spring AOP Proxy
   ↓
Pointcut matching
   ↓
Ordered Advice
   ↓
Target Method
   ↓
Ordered Advice
   ↓
Return value

That connects nicely with the earlier proxy examples and makes Spring AOP feel much less like "magic."

The goal of spring-by-example isn't just to collect Spring annotations and APIs.

I'm trying to understand how the Spring container works, 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

🔗 GitLab

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

Next up: Spring Transactions — continuing the journey by exploring another important part of the Spring ecosystem.

If you’ve worked with Spring AOP before, what concept do you think is the most difficult for developers to understand: proxies, pointcuts, advice, or advice ordering?

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

🚀 Building Spring by Example: Completing the Spring Events Module

Mujuzi Moses  — Sun, 16 Aug 2026 15:57:40 +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 6 — Events. 🎉

The module covers:

Publishing Events
Listening for Events
Custom Events
Transactional Events
Async Events

One thing I’ve really enjoyed about this module is seeing how Spring’s event system can help decouple different parts of an application.

For example, ApplicationEventPublisher allows one component to publish an event without needing to know which components will respond to it. @EventListener then provides a simple way for other components to react to those events.

I also explored custom events, which made it possible to model application-specific events such as an order being created.

Transactional events introduced another interesting concept: controlling when an event listener should run in relation to a transaction. With @TransactionalEventListener, event handling can be tied to transaction phases such as after a successful commit.

Finally, @Async showed how event listeners can be processed asynchronously, allowing the publisher to continue without waiting for the listener to finish.

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

🔗 GitHub: githu.b/mujuzimoses

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

Next up: Spring AOP — exploring Aspect-Oriented Programming, proxies, aspects, advice, pointcuts, and how Spring applies cross-cutting concerns.

If you’ve worked with Spring before, what’s one part of Spring’s event system you think developers commonly misunderstand?

java #springframework #opensource #github #learninginpublic #backend #softwareengineering #spring #events