A Common Problem When Starting Out With The Spring Framework

Hello! Welcome to a series of blog posts where I will be going in depth and talking about my experiences with learning the Spring Framework! Of course, we all love Spring for its simplicity and the power it offers through things like Hibernate and Spring MVC. But sometimes, when so many things are abstracted away as they are in Spring, when you run into a problem it can be a nightmare to try and find out how and where you’re going wrong. Today, I hope to shed some light on a really nebulous feature of Spring I’ve ran into and how to fix it. Let’s get started!

Let’s first talk about what a Component is in general. Essentially, when Spring starts, it looks through a list of packages for anything that it can create a Spring Bean out of. You can think of a Spring Bean like a Java Bean. These Spring Beans are annotated with a @Component annotation. At the heart of it, even annotations like @Controller and @Repository are components at the end of the day. Any kind of entity you might need for your Spring Application, be it a simple POJO or something more complex like a RESTful controller is an example of a Component. It’s through this definition of a Component that Spring can work its magic with Dependency Injection. Spring scans these components and maps them all together through the process of Component Scanning. Unfortunately, what is included in the Component Scan and what is not are not readily apparent. Sometimes a Component is never scanned for seemingly no reason. Or at least that was my beginner experience. This nebulous feature is what I want to shed light on today.

Now, let’s build a basic application to show you what is included in component scanning and what is not.

Take this package structure:

Our main method is inside BlogPost1Application like so:

Each component is named after a fruit in this example. Here is the component class structure (they’re all the same, just different class names):

Let’s break down what’s happening in the main method. You add the @ComponentScan and @Configuration to signify that this class finds and sets up the Spring Beans. Then the main method sets up the application context with SpringApplication.run(). The rest of the code is just there to access the application context and print out the name of all created beans by the Component Scan. With this, we can easily see what Components are being detected and which are not.

The Components themselves are annotated with @Component to declare to Spring that they are Components. There isn’t much going on with them since we only care about the class names.

Now let’s see which Components are detected. Here is the output with the current package structure:

We can see with this that our Main class is picked up along with Apple and Banana. But where are Peach and Orange?? This is the crux of Component Scanning. By default, Spring will only scan classes in the same package or lower than where the Configuration class is located. What this means is that only com.canada.spring.main and com.canada.spring.main.deep are being scanned, since the Configuration class is the Main class, and that class is located in com.canada.spring.main. There are two ways to cause other packages to be scanned.

You can add the parameter basePackages to the Component Scan Annotation like this:

This forces Spring to look for Components in the com.canada.spring package and anything below it. This allows the Peach and Orange classes to be scanned. The output is shown below:

Alternatively, you can relocate the Configuration class away from the main method. I’ll create a new class in the high level com package:

This class now contains the @ComponentScan and @Configuration annotations:

Then, we need to instantiate the location of the configuration class in the main method:

With this, we will see all Components are found as before without tying everything down to the main method.

Both methods have their pros and cons. On the one hand, adding a simple parameter to the Main class is super easy and I would normally go for this method to solve any Component Scanning issues. But, being able to separate the Configuration class out can keep your Main class from becoming too cluttered. Also, if you want to add more functionality to your Configurations, more than what a simple application can handle, another class will be all but required.

I hope you gained an understanding about how component scanning works in Spring! Thank you for reading! I posted some helpful links below for more reading.

Related posts:

I was surprised to receive an email from Microsoft letting me know that I had access to the early preview of its brand-new web-based design tool, Microsoft Designer. It is a new graphic design app…

Can Democracy be a desired state (a promise /a “what if!” state) or can it be inter-woven in the design process itself? What about sustainability? Both seems possible, though a desired state is…

For these past 2 years, I have been focusing my study in creating an interactive documentary. As part of the Interactive Capstone class working with Soul of Athens project that I took this Spring…