Sonar complains about Spring Boot configuration

[Daniel Frey]

I have this class to start up the spring-cloud config server. It is a spring-boot application.

@SpringBootApplication
@EnableConfigServer
@EnableDiscoveryClient
public class ConfigServerApplication {

    public static void main( String[] args ) {

        SpringApplication.run( ConfigServerApplication.class, args );

    }

}

The application runs fine and all my unit tests are fine. However, in our bamboo pipeline, it will initial a sonar process to analyze the code. We keep getting these minor warnings indicating the following:

Utility classes should not have a public constructor

I know that this is a minor issue, but I have been tasked with removing these from our code.

Ideally, you would mark the class final and provide a private constructor, or so all searches provide as a solution. However, a Spring Configuration class cannot be made final and cannot have a private constructor.

Can Sonar be modified to not include spring-boot application classes (and configuration classes) from being reported as Utility classes, especially if there is a public static void main method in the class?

Thanks,

Dan

[Freddy Mallet]

Hi Dan,

According to me this is really a corner case which should not generate lot of false-positives as I don't expect you to have lot of start-up classes ? So I tend to say -1 on my side to support this exception. 

Kind regards

Freddy MALLET | SonarSource

Product Director & Co-Founder
http://sonarsource.com

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/BY2PR0701MB1973605DF51EC3DEBBF9208CEB420%40BY2PR0701MB1973.namprd07.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Frey]

Thanks for the update Freddy.

I was only asking because I was tasked with cleaning up the sonar reported issues.  I will see if I can relax the rules around these types of classes to eliminate these minor warnings from appearing.

Dan

---

From: Freddy Mallet <freddy...@sonarsource.com>
Sent: Friday, October 2, 2015 8:16 AM
To: Daniel Frey
Cc: sona...@googlegroups.com
Subject: Re: Sonar complains about Spring Boot configuration

 

Hi Dan,

According to me this is really a corner case which should not generate lot of false-positives as I don't expect you to have lot of start-up classes ? So I tend to say -1 on my side to support this exception. 

Kind regards

Freddy MALLET | SonarSource

Product Director & Co-Founder
http://sonarsource.com

SonarSource - Continuous Inspection of Code Quality Customers. SonarSource products and services are used by customers all over the world. More customers Read more...

[Brian Sperlongano]

This one bit me, too.  There is no way to wrangle a Spring Boot application to be SonarQube compliant, it seems.  Simply, sonar should NOT report the utility class finding on classes annotated with @SpringBootApplication (and possibly other Spring annotations).

[Nicolas Peru]

@Brian, would you mind elaborate a bit the pain you are feeling analyzing your spring boot code with SonarQube? because we might improve things but we need detailed and specific use cases to do so (because switching off all issues if something is annotated with a *.spring.* annotation seems a bit too much ;) ). 

Cheers,

Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

https://twitter.com/benzonico

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/3bc49eca-341c-4167-b933-4ffbaa34779d%40googlegroups.com.

[Brian M. Sperlongano]

In coming up with a clean example, I actually found a way to do this with Spring that still works and makes the SonarQube findings go away. I will share for the benefit of anyone else that encounters this pattern.  Consider Example:

@ComponentScan("com.somecompany")

@PropertySource("my-application.properties")

@SpringBootApplication

public class MyApplication

{

  public static void main(String... args)

  {

  SpringApplication.run(MyApplication.class, args);

  }

}

This code will report a finding that the MyApplication class should have a private Constructor.  So step 1, developer adds a private constructor to MyApplication.  However, Spring Boot will NOT work with a private constructor!  So that's no good.

So, attempt #2 is to take all of the class annotations and move them to a separate class:

public class MyApplication

{

  public static void main(String... args)

  {

  SpringApplication.run(MyApplicationBoot.class, args);

  }

}

@ComponentScan("com.somecompany")

@PropertySource("my-application.properties")

@SpringBootApplicationBoot

public class MyApplicationBoot

{

}

This makes all the findings go away on MyApplication, but now MyApplicationBoot is detected as an empty class that should be removed!  Now, if you change MyApplicationBoot to an interface rather than a class, Spring Boot still works and all the sonar findings go away.