Create rule S6832: Non-singleton Spring beans should not be injected in a Singleton bean

[github-actions]

You can preview this rule here (updated a few minutes after each push).

Review

A dedicated reviewer checked the rule description successfully for:

• logical errors and incorrect information
• information gaps and missing content
• text style and tone
• PR summary and labels follow the guidelines

[johann-beleites-sonarsource]

Nice rule and nicely detailed explanation!

[sonarqube-next]

SonarQube Quality Gate for 'rspec-tools'

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[sonarqube-next]

SonarQube Quality Gate for 'rspec-frontend'

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[dnsmkl2]

Regarding https://rules.sonarsource.com/java/RSPEC-6832/

the dependency is resolved at instantiation time and thus the same instance is used for each HTTP request.

Above sentence is correct only when proxyMode = ScopedProxyMode.TARGET_CLASS is missing.
(If proxyMode = ScopedProxyMode.TARGET_CLASS is present, then only proxy is resolved at instantiation; actual class resolving is deferred to invocation time)

Any chance to reword the issue and make it clear that @Scope(value = WebApplicationContext.SCOPE_REQUEST) is problem, while
@Scope(value = WebApplicationContext.SCOPE_REQUEST, proxyMode = ScopedProxyMode.TARGET_CLASS) is not a problem.

Or maybe reword to make it clear that is a question of style. (less error prone style)

Also, is the problem limited to REQUEST and PROTOTYPE scopes? (not a problem for SESSION?)

Somewhat relevant:

• https://www.baeldung.com/spring-inject-prototype-bean-into-singleton describes @Scope(value = WebApplicationContext.SCOPE_REQUEST, proxyMode = ScopedProxyMode.TARGET_CLASS) as valid solution.