DEV Community: Mujuzi Moses 

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

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

🚀 Building Spring by Example: Completing the Bean Lifecycle Module

Mujuzi Moses  — Thu, 13 Aug 2026 12:00:30 +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 5 — Bean Lifecycle. 🎉

The module covers:

InitializingBean
DisposableBean
@PostConstruct
@PreDestroy
BeanPostProcessor
BeanFactoryPostProcessor
SmartLifecycle

One thing I’ve really enjoyed about this module is seeing how these concepts fit into different stages of the Spring container lifecycle.

For example, @PostConstruct and InitializingBean help with bean initialization, while @PreDestroy and DisposableBean provide ways to perform cleanup.

BeanPostProcessor introduced another interesting part of Spring: processing bean instances before and after initialization. BeanFactoryPostProcessor took that a step further by working with bean definitions before the actual bean instances are created.

And with SmartLifecycle, I explored how Spring can coordinate the startup and shutdown of components that have an active running state.

The goal isn’t just to collect Spring annotations and interfaces. I’m trying to understand how the Spring container works 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/mujuzimoses

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

Next up: Events — exploring how Spring components can communicate through application events, including custom events, transactional events, and asynchronous events.

If you’ve worked with Spring before, what’s one part of the Spring bean lifecycle you think developers commonly misunderstand?

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

🚀 Building Spring by Example: Completing the Dependency Injection Module

Mujuzi Moses  — Mon, 10 Aug 2026 11:28:16 +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 4 — Dependency Injection. 🎉

The module covers:

@primary
@Qualifier
Collection Injection
@Order
Map Injection
ObjectProvider
Optional Dependencies
Circular Dependencies
Bean Aliases

One thing I’ve really enjoyed about this module is seeing how these concepts build on each other.

For example, @primary and @Qualifier help resolve multiple candidates, while collection and map injection let us work with multiple beans. ObjectProvider introduces more flexible bean retrieval, and examples like circular dependencies show what can go wrong when the dependency graph isn’t designed carefully.

The goal isn’t just to collect Spring annotations. I’m trying to understand how the Spring container works 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: github

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

Next up: Bean Lifecycle — understanding how Spring creates, initializes, and destroys beans.

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

java #springframework #opensource #github #learninginpublic #backend #softwareengineering #dependencyinjection

🚀 Building Spring by Example: Completing the Configuration Module

Mujuzi Moses  — Wed, 05 Aug 2026 11:30:29 +0000

When I started building spring-by-example, my goal was simple:

Learn Spring by creating small, focused, runnable examples that explain not just how something works, but why it works.

Since then, the project has grown steadily, and I’ve just completed the Configuration module.

So far, the repository includes examples covering:

✅ Fundamentals

Spring Beans
Dependency Injection
Constructor Injection
Setter Injection
Field Injection
Choosing an Injection Strategy

✅ Bean Scopes (Core)

Singleton Scope
Prototype Scope

✅ Configuration

@Configuration
@bean
@Component
@Service
@Repository
@Controller
@ComponentScan
@import
@ImportResource
XML Configuration
Java Configuration
Mixing XML and Java Configuration

Each example is intentionally small, runnable, and documented so you can focus on understanding one concept at a time without the noise of a large application.

Next up is Dependency Injection, where I’ll be exploring topics like @primary, @Qualifier, collection injection, ObjectProvider, and more.

Building this repository has been a great way to deepen my own understanding while creating something I hope will be useful to others learning Spring.

If you’ve worked with Spring, which concept was your biggest “aha!” moment—or which one took the longest to truly understand?

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