Expand Authors Top

If you have a few years of experience in the Java ecosystem and you’d like to share that with the community, have a look at our Contribution Guidelines.

Expanded Audience – Frontegg – Security (partner)
announcement - icon User management is very complex, when implemented properly. No surprise here.

Not having to roll all of that out manually, but instead integrating a mature, fully-fledged solution - yeah, that makes a lot of sense.
That's basically what Frontegg is - User Management for your application. It's focused on making your app scalable, secure and enjoyable for your users.
From signup to authentication, it supports simple scenarios all the way to complex and custom application logic.

Have a look:

>> Elegant User Management, Tailor-made for B2B SaaS

November Discount Launch 2022 – Top
We’re finally running a Black Friday launch. All Courses are 30% off until the end of this week:

>> GET ACCESS NOW

NPI – Lightrun – Spring (partner)

We rely on other people’s code in our own work. Every day. It might be the language you’re writing in, the framework you’re building on, or some esoteric piece of software that does one thing so well you never found the need to implement it yourself.

The problem is, of course, when things fall apart in production - debugging the implementation of a 3rd party library you have no intimate knowledge of is, to say the least, tricky. It’s difficult to understand what talks to what and, specifically, which part of the underlying library is at fault.

Lightrun is a new kind of debugger.

It's one geared specifically towards real-life production environments. Using Lightrun, you can drill down into running applications, including 3rd party dependencies, with real-time logs, snapshots, and metrics. No hotfixes, redeployments, or restarts required.

Learn more in this quick, 5-minute Lightrun tutorial:

>> The Essential List of Spring Boot Annotations and Their Use Cases

1. Introduction

When writing our Spring application we might need to specify a certain list of packages that contain our entity classes. Similarly, at some point, we would need only a specific list of our Spring beans to be initialized. This is where we can make use of @EntityScan or @ComponentScan annotations.

To clarify the terms we use here, components are classes with @Controller, @Service, @Repository, @Component, @Bean, etc. annotations. Entities are classes marked with @Entity annotation.

In this short tutorial, we'll discuss the usage of @EntityScan and @ComponentScan in Spring, explain what are they used for, and then point out their differences.

2. The @EntityScan Annotation

When writing our Spring application we will usually have entity classes – those annotated with @Entity annotation. We can consider two approaches to placing our entity classes:

  • Under the application main package or its sub-packages
  • Use a completely different root package

In the first scenario, we could use @EnableAutoConfiguration to enable Spring to auto-configure the application context.

In the second scenario, we would provide our application with the information where these packages could be found. For this purpose, we would use @EntityScan.

@EntityScan annotation is used when entity classes are not placed in the main application package or its sub-packages. In this situation, we would declare the package or list of packages in the main configuration class within @EntityScan annotation. This will tell Spring where to find entities used in our application:

@Configuration
@EntityScan("com.baeldung.demopackage")
public class EntityScanDemo {
    // ...
}

We should be aware that using @EntityScan will disable Spring Boot auto-configuration scanning for entities.

3. @ComponentScan Annotation

Similar to @EntityScan and entities, if we want Spring to use only a specific set of bean classes, we would use @ComponentScan annotation. It'll point to the specific location of bean classes we would want Spring to initialize.

This annotation could be used with or without parameters. Without parameters, Spring will scan the current package and its sub-packages, while, when parameterized, it'll tell Spring where exactly to search for packages.

Concerning parameters, we can provide a list of packages to be scanned (using basePackages parameter) or we can name specific classes where packages they belong to will also be scanned (using basePackageClasses parameter).

Let's see an example of @ComponentScan annotation usage:

@Configuration
@ComponentScan(
  basePackages = {"com.baeldung.demopackage"}, 
  basePackageClasses = DemoBean.class)
public class ComponentScanExample {
    // ...
}

4. @EntityScan vs. @ComponentScan

In the end, we can say that these two annotations are intended for completely different purposes.

Their similarity is that they both contribute to our Spring application configuration. @EntityScan should specify which packages do we want to scan for entity classes. On the other hand, @ComponentScan is a choice when specifying which packages should be scanned for Spring beans.

5. Conclusion

In this short tutorial, we discussed the usage of @EntityScan and @ComponentScan annotations and also pointed to their differences.

November Discount Launch 2022 – Bottom
We’re finally running a Black Friday launch. All Courses are 30% off until the end of this week:

>> GET ACCESS NOW

Generic footer banner
Comments are closed on this article!