Spring beans belonging to packages that are not included in a ``++@ComponentScan++`` configuration will not be accessible in the Spring Application Context. Therefore, it's likely to be a configuration mistake that will be detected by this rule.
*Note:* the ``++@ComponentScan++`` is implicit in the ``++@SpringBootApplication++`` annotation, case in which Spring Boot will auto scan for components in the package containing the Spring Boot main class and its sub-packages.
public class MyController { // Noncompliant; MyController belong to "com.mycompany.app.web" while the ComponentScan is looking for beans in "com.mycompany.app.beans" package
XXX is not reachable by @ComponentScan or @SpringBootApplication. Either move it to a package configured in @ComponentScan or update your @ComponentScan configuration.
*Note:* the ``++@ComponentScan++`` is implicit in the ``++@SpringBootApplication++`` annotation, case in which Spring Boot will auto scan for components in the package containing the ``++@SpringBoot++`` main class and its sub packages.
*Out of scope:* usage of filters to customize scanning, e.g.:
This rule should never be in the Default Profile because:
* it ignores XML _component-scan_ configuration
* it's perfectly valid to have project A with a @Component class which is not actually consumed in project A. And then project B declares in a @ComponentScan configuration class the package from Project A, and consumes it as a dependency. Everything will work just fine, even if the code for project A is totally separate from the code from project B.
=== on 14 Mar 2021, 18:10:12 Stéphane Nicoll wrote:
A more compliant solution would be to remove the `@ComponentScan` directive altogether and use `@SpringBootApplication`. This way `com.mycompany.app` is used. This also helps with slice tests where the appropriate filter will be configured automatically.