27 lines
1.9 KiB
Plaintext
27 lines
1.9 KiB
Plaintext
=== 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.
|
||
|