
Inline adoc files when they are included exactly once. Also fix language tags because this inlining gives us better information on what language the code is written in.
96 lines
3.9 KiB
Plaintext
96 lines
3.9 KiB
Plaintext
== Why is this an issue?
|
||
|
||
``++@ComponentScan++`` is used to find which Spring ``++@Component++`` beans (``++@Service++`` or ``++@Repository++`` or ``++Controller++``) are available in the classpath so they can be used in the application context. This is a convenient feature especially when you begin a new project but it comes with the drawback of slowing down the application start-up time especially when the application becomes bigger (ie: it references a large JAR file, or it references a significant number of JAR files, or the base-package refers to a large amount of .class files).
|
||
|
||
|
||
``++@ComponentScan++`` should be replaced by an explicit list of Spring beans loaded by ``++@Import++``.
|
||
|
||
|
||
The interface ``++@SpringBootApplication++`` is also considered by this rule because it is annotated with ``++@ComponentScan++``.
|
||
|
||
|
||
=== Noncompliant code example
|
||
|
||
[source,java]
|
||
----
|
||
@ComponentScan
|
||
public class MyApplication {
|
||
...
|
||
}
|
||
|
||
@SpringBootApplication
|
||
public class MyApplication {
|
||
...
|
||
}
|
||
----
|
||
|
||
|
||
=== Compliant solution
|
||
|
||
[source,java]
|
||
----
|
||
@Configuration
|
||
@Import({
|
||
DispatcherServletAutoConfiguration.class,
|
||
ErrorMvcAutoConfiguration.class,
|
||
HttpEncodingAutoConfiguration.class,
|
||
HttpMessageConvertersAutoConfiguration.class,
|
||
MultipartAutoConfiguration.class,
|
||
ServerPropertiesAutoConfiguration.class,
|
||
PropertyPlaceholderAutoConfiguration.class,
|
||
WebMvcAutoConfiguration.class
|
||
})
|
||
public class MyApplication {
|
||
...
|
||
}
|
||
----
|
||
|
||
|
||
== Resources
|
||
|
||
* https://sites.google.com/site/appsdevelopersindia/google-blog/optimizingspringframeworkforappengineapplications[Optimizing Spring Framework for App Engine Applications]
|
||
|
||
|
||
ifdef::env-github,rspecator-view[]
|
||
|
||
'''
|
||
== Implementation Specification
|
||
(visible only on this page)
|
||
|
||
=== Message
|
||
|
||
Consider replacing "@SpringBootApplication" | "@ComponentScan" by a list of beans imported with @Import to speed-up the start-up of the application.
|
||
|
||
|
||
'''
|
||
== Comments And Links
|
||
(visible only on this page)
|
||
|
||
=== on 20 Apr 2018, 14:00:32 Alexandre Gigleux wrote:
|
||
Reference: \https://alexecollins.com/spring-boot-performance/?spm=5176.100239.blogcont2360.15.1px5s9
|
||
|
||
=== on 20 Apr 2018, 17:31:04 Ann Campbell wrote:
|
||
\[~alexandre.gigleux] the title says "fine-tuned" and the description says "replaced". Should title be "should not be used"?
|
||
|
||
=== on 21 Jun 2018, 16:35:00 Andrei Epure wrote:
|
||
This rule partially overlaps with https://jira.sonarsource.com/browse/RSPEC-4604[RSPEC-4604] with regards to ``++SpringBootApplication++``. RSPEC-4604 suggests having either ``++@SpringBootApplication(exclude = {})++`` , or using ``++@Import++`` - like this rule
|
||
|
||
=== on 22 Jun 2018, 09:28:14 Alban Auzeill wrote:
|
||
Even if it overlaps with RSPEC-4604, [~andrei.epure] and I decided to add it to SonarJava because this rule is not in the "Sonar way" profile. So it will be not be noisy, but useful to those who requires it.
|
||
|
||
=== on 29 Aug 2018, 18:30:14 Michal Domagala wrote:
|
||
Are you aware of https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#beans-scanning-index[beans-scanning-index]?
|
||
|
||
Did you notice that you refer to article from 2012 (Spring 3) \https://cloud.google.com/appengine/articles/spring_optimization ?
|
||
|
||
=== on 14 Mar 2021, 18:08:06 Stéphane Nicoll wrote:
|
||
Spring Boot developer here.
|
||
|
||
|
||
Unfortunately, I think this rule is misleading. The impact of component scanning is very low, even with somewhat large application. We've implemented a compile-time indexer that really makes a difference with thousands of beans from tens of thousands of candidates.
|
||
|
||
|
||
A better way to structure this rule would be to guide users to rationalize the candidates in a given package. So, for instance, avoiding the use of `@ComponentScan("org")` or even`@ComponentScan("org.mycompany")`. Component scan is better use on the project's asserts (i.e. `org.mycomponent.myproject`). For libraries or reusable components, `@Import` is a better choice indeed.
|
||
|
||
endif::env-github,rspecator-view[]
|