Does ComponentScan order matter?

Question

I'm setting up a very small Spring/REST/JPA project with Boot, using annotations.

I'm getting some Bean not found errors in my REST controller class that has an Autowired repository variable, when I move my JPA repository class out to a different package, and calling componentscan on its package. However, everything was working fine when all my files(5 total) were in the same package.

So I was wondering, however unlikely, if the component scan order matters? For example, if a class is AutoWiring some beans from a package that has not been 'component scanned' yet, will that cause a Bean not found error?

Answer 1

No, Spring loads all configuration information, from files and annotations and the environment when appropriate. It then creates beans (instances of classes) according to a dependency tree that it calculates in memory. In order to do this it has to have a good idea of the entire configuration at startup. The whole model derived from all the aggregated configuration information is called the Application Context.

In modern versions of spring the application context is flexible at runtime and so it's not quite the case that all the configuration is necessarily known up front, but the configuration that is flexible is limited in scope and must be planned for carefully.

Answer 2

Maybe you need to share some code. When you move that stuff, you also need to tell Spring where they went. My guess would be you haven't defined @EntityScan and @EnableJpaRepositories (which default to the location of @EnableAutoConfiguration).

Answer 3

There could be several problems:

• You moved your class out of the some package where you have @ComponentScan without arguments. That basically means that components are scan only in this package and its children. Thus, moved class are not scanned and there is no bean to wire.
• Wrong package name in @ComponentScan args.

The order isn't matter at all. There is an @Order annotation, but it's purpose is more about loading multiple implementations of sth in a different order. At first Bean Definitions are created and they have nothing to do with wiring. Then via bean post processors, autowired beans are injected. Since there were no bean definition. There is nothing to inject.

Answer 4

In a well structured program it doesn't, because first each bean gets instantiated, then autowired and then you can actually use them.

However there could be situations where the order does matter and I had an issue figuring out what was going on. So this is an example where it would matter:

1. You have some Repository that you want to fill with data initially, call it SetupData component.
2. Then you use @PostConstruct to save the default objects.
3. You have some component that this Repository depends on but isn't managed by Spring, for example a @Converter.
4. And that @Converter depends on some other component which you would statically inject.

In this case @PostConstruct methods will be executed before the components into your @Converter get autowired which will result in an exception.

Relying on ComponentScan order is a bad habit, because it's not intuitive especially when you are working with multiple people who may not know about. Or there might be such dependencies that you can't fix the code by changing the scan order.

The best solution in this case was using a task executor service that takes care of running initialization functions.