S2629 does not recognize org.slf4j.ext.XLogger

[kecl...@gmail.com]

Hello!

I am working on a Java project and using sonar-scanner in our Jenkins CI pipeline, which reports to a SonarQube server.

S2629 states "Preconditions" and logging arguments should not require evaluation. Recently I noticed SonarQube is no longer flagging these issues in my project. I thought perhaps I had accidentally turned off the rule, but after further investigation it was clear that I had not. Rather, since switching from org.slf4j.Logger to org.slf4j.ext.XLogger, noncompliant code is no longer being flagged as such.

To test my theory I reverted the XLogger change in one of my classes. I rescanned the class, and now all locations featuring noncompliant logging are flagged. I then reapplied the change (Logger -> XLogger) and rescanned, and the issues disappeared.

(Flagged) Noncompliant org.slf4j.Logger example:

...

  private static final Logger log = LoggerFactory.getLogger(Builder.class);

...

  log.debug("Setting read timeout to " + readTimeout.timeout + " "

    + readTimeout.units);

...

(Not Flagged) Noncompliant org.slf4j.ext.XLogger example:

...

  private static final XLogger log = XLoggerFactory.getXLogger(Builder.class);

...

  log.debug("Setting read timeout to " + readTimeout.timeout + " "

    + readTimeout.units);

...

I believe it is an oversight that XLogger is not being recognized. Hopefully this is an easy fix.

In the meanwhile, is there an easy way to extend the existing rule to support XLogger, or will I have to write a custom rule to support it?

Thanks in advance!

Kristin

[kecl...@gmail.com]

Hi,

I forgot to mention that our SonarQube version is 6.4.0.25310, and our sonar-scanner version is 3.0.3.778.

Thanks!

Kristin

[Michael Gumowski]

Hey Kristin,

Thanks a lot for your feedback. Indeed, org.slf4j.ext.XLogger is currently not supported by latest implementation of rule squid:S2629 (SonarJava 4.14.0.11784).

It's consequently a False Negative, and the analyzer should definitely catch such case as well.

I created the following ticket to improve the rule, and eventually handle it correctly: SONARJAVA-2534 

So, to answer your question, no needs to write a custom rule, we are going to improve it to make it support XLogger when handling the ticket.

Now, if you want to contribute to the project, feel free to open a PR on SonarJava github repository (the rule is implemented here, and don't forget to read our guidelines).

As a side note, when reporting such kind of issues (false positive, false negative, rule making analysis crash), it's usually more important to provide the related programming language, and more particularly the version of the analyzer used during analysis! But I admit that in this case, it was obvious! :)

Cheers,

Michael

--
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/d4475eab-49b5-4d20-ad26-c521905865c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Michael Gumowski | SonarSource

Software Developer, Language Team
https://www.sonarsource.com