Adding FxCop rules to Sonarqube

In my posts about custom FxCop rules I mention creating rules for FxCop. In this post I’ll explain how to add the created rules to Sonarqube.

First of all, the assembly needs to be put on the server somewhere. The location doesn’t really matter too much, as long as it’s accessible for Sonarqube. In my case I just dropped it into the default FxCop Rules folder, which is located by default in C:\Program Files (x86)\Microsoft FxCop 10.0\Rules.

After that, Sonarqube needs to be told about the rules as well. The XML is actually fairly similar to the XML file we create for the FxCop rules in the first place.

<?xml version="1.0" encoding="utf-8" ?>
<rules>
    <rule key="Classname">
        <name><![CDATA[Name for the rule]]></name>
        <configKey><![CDATA[Classname@Location\Of\Assembly\Assemblyname.dll]]></configKey>
        <description><![CDATA[Rule description]]></description>
    </rule>
</rules>

So, to take the example of the GetItemUsingID rule, the XML could look something like this:

<?xml version="1.0" encoding="utf-8" ?>
<rules>
    <rule key="GetItemUsingID">
        <name><![CDATA[Enforce calling the GetItem method using an ID]]></name>
        <configKey><![CDATA[GetItemUsingID@$(FxCopDir)\Rules\Sitecore.FxCop.dll]]></configKey>
        <description><!CDATA[Use GUIDS where possible instead of path / name. This will improve performance as well as prevent code breaking if content is renamed or moved in the content tree.]]></description>
    </rule>
</rules>

When the XML has been created it has to be put in the FxCop custom rules field in Sonarqube. You can get to this by going to Sonarqube -> Settings -> Configuration -> .NET FxCop:
Sonarqube configuration settings

Before the rules can be used Sonarqube does have to be restarted. Then we can go into Sonarqube -> Settings -> Quality Profiles. Select the active code profile, and go to the inactive FxCop rules. Select the newly added rules to be active, and we’re all done.

I guess this would also be a good time to mention the source code of the 11 rules I initially created is available on Bitbucket and Sitecore’s marketplace, so feel free to create a fork and add your own rules!

If you just want to use the rules, that’s possible as well, just go to the download page on Bitbucket and download the zipfile. The zipfile contains a dll of the initial release at the moment, although I hope to steadily add new rules to the project.

Advertisements

Sitecore and FxCop – ItemAxes and Database Rules

This is the fourthpost in the Sitecore and FxCop series

I’ve been working on a bunch of easier to implement rules, which I figured I’d run through here. As always, I’m trying to improve the code, either increasing the performance of the code or making it a little more safe to use.

There’s a couple of categories in which I’ve added rules, and I’ll be creating a post per category, as it’ll be a huge post otherwise.

The categories I added rules in are:

ItemAxes & Database

This is one of the most important areas for performance issues. When we are using the ItemAxes to get all ancestors or descendants that can take a very big performance hit. It is often much better and faster to use Sitecore.ContentSearch (granted, this can only be done using Sitecore 7 and up). The same goes for the SelectItems() with Xpath as well.

So the four rules I put in on the ItemAxes are:

  1. Don’t use SelectSingleItem (accessible as Sitecore.Data.Items.ItemAxes.SelectSingleItem as well as Sitecore.Data.Database.SelectSingleItem)
  2. Don’t use SelectItems (accessible as Sitecore.Data.Items.ItemAxes.SelectItems as well as Sitecore.Data.Database.SelectItems)
  3. Don’t use GetAncestors
  4. Don’t use GetDescendants

On this blogpost I saw some stats for Lucene and fast query, which is not really a fair comparison I think because fast query will always go straight to the database, I figured I’d get a bit of data together.

Consider the following code:

var index = Sitecore.ContentSearch.ContentSearchManager.GetIndex("sitecore_master_index")
{
    using (var context = index.CreateSearchContext())
    {
        // ContentSearch
        Stopwatch sw = new Stopwatch();
        sw.Start();
        var indexed = context.GetQueryable<Sitecore.ContentSearch.SearchTypes.SearchResultItem>().Where(item => item.Name.Contains("s"));
        sw.Stop();
        Sitecore.Diagnostics.Log.Info(string.Format("ContentSearch. Elapsed time: {0}. Items found: {1}", sw.Elapsed, indexed.ToList().Count));
    }

    // Fast query
    Stopwatch sw2 = new Stopwatch();
    sw2.Start();
    var fQuery = Sitecore.Configuration.Factory.GetDatabase("master").SelectItems("fast://*[@@name='%s%']");
    sw2.Stop();
    Sitecore.Diagnostics.Log.Info(string.Format("Fast query. Elapsed time: {0}. Items found: {1}", sw2.Elapsed, fQuery.Length), this);

    // Normal query
    Stopwatch sw3 = new Stopwatch();
    sw3.Start();
    var query = Sitecore.Configuration.Factory.GetDatabase("master").SelectItems("//*[contains(@@name, 's')]");
    sw3.Stop();
    Sitecore.Diagnostics.Log.Info(string.Format("Normal query. Elapsed time: {0}. Items found: {1}", sw3.Elapsed, query.Length), this);
}

This gave me the following output in my Sitecore log file:

INFO ContentSearch. Elapsed time: 00:00:00:0178173. Items found: 8723
INFO Fast query. Elapsed time: 00:00:05.2718443. Items found: 5194
INFO Normal query. Elapsed time: 00:00:09.7881149. Items found: 4320

Those are some pretty big differences. These results are for just under 13000 items. Of course, it’s still not completely honest because the normal query does need to call the Contains function, which I don’t know the performance implications for…

Another big plus of using ContentSearch is that Linq is a lot easier to read in more complex queries than Xpath / Fast query.

From a custom rule perspective, those four rules are extremely simple to create. Almost all rules I added to my project so far use a lot of the same code – If the corresponding classes get called, flag them as warnings on the page.

Of course, as with all rules, there’s bound to be some exceptions and actual legitimate good uses of these classes. The rules are only there to point out that it might be a good idea to re-think that.

Sitecore and FxCop – Field Rules

This is the fourthpost in the Sitecore and FxCop series

I’ve been working on a bunch of easier to implement rules, which I figured I’d run through here. As always, I’m trying to improve the code, either increasing the performance of the code or making it a little more safe to use.

There’s a couple of categories in which I’ve added rules, and I’ll be creating a post per category, as it’ll be a huge post otherwise.

The categories I added rules in are:

Fields

I actually added a couple of field rules. In a previous post I was talking about accessing raw field value properly and getting items from the database with IDs rather than a path.

Now, of course it would also make sense to get the field values based not on the fieldname, but the GUID of the particular fields. This of course has the advantage of getting the correct field always, even when the fieldname changes.

I’ll admit this is a rule I had some difficulty with, although it ended up being very easy.

public override void VisitMethodCall(MethodCall methodCall)
{
    base.VisitMethodCall(methodCall);

    var memberBinding = methodCall.Callee as MemberBinding;
    if (memberBinding != null)
    {
        var methodCalled = memberBinding.BoundMember as Method;
        if (methodCalled != null)
        {
            if (methodCalled.FullName == "Sitecore.Collections.FieldCollection.get_Item(System.String)")
            {
                Expression parameter = methodCall.Operands[0];
                CheckValue(methodCall, parameter);
            }
        }
    }
}

In which CheckValue just tries to match the value of the parameter with a GUID, using a Regular Expression. The thing I had difficulties with was that I was accessing a FieldCollection, and could not inspect the actual line which was making the call.

Another rule which I think will be particularly useful is one that flags where people are trying to get the value from a CheckboxField – to check whether it’s been checked or not. The utils that come with Sitecore seem to be a little under-used, and one of the things that’s possible with the utils is exactly this: Get the value of a checkbox.

Consider the following code snippet:

namespace SomeNamespace
{
    public class SomeClass
    {
        public void SomeMethod()
        {
            var item = Sitecore.Context.Database.GetItem("{66EC0398-1E67-4D43-B2EB-ED29E3E8E291}");
            if (item != null)
            {
                CheckboxField field = (CheckboxField)item.Fields["checkbox"];
                if (field != null)
                {
                    var isChecked = field.Checked;
                }
            }
        }

        public void SomeOtherMethod()
        {
            var item = Sitecore.Context.Database.GetItem("{66EC0398-1E67-4D43-B2EB-ED29E3E8E291}");
            if (item != null)
            {
                var isChecked = MainUtil.GetBool(item["checkbox", false);
             }
        }
    }
}

Of course, instead of calling the field with its fieldname we should do that with the ID – but for this example it’s a bit easier to read like this.
We don’t have to first get the checkboxfield, then check whether it even exists followed by finally getting the value, we can just call Sitecore’s MainUtil.GetBool, pass in the value we want to convert to bool and the default value. A lot safer and it’s a couple lines shorter which should appeal to us lazy programmers 😉

I figured I’d skip the same FxCop rule code this time, as it’s the same as the examples in the other posts. The method we’re checking for this time is Sitecore.Data.Fields.CheckboxField.get_Checked . If that method is indeed called, flag that as a possible problem.

Sitecore and FxCop – Security Rules

This is the third post in the Sitecore and FxCop series

I’ve been working on a bunch of easier to implement rules, which I figured I’d run through here. As always, I’m trying to improve the code, either increasing the performance of the code or making it a little more safe to use.

There’s a couple of categories in which I’ve added rules, and I’ll be creating a post per category, as it’ll be a huge post otherwise.

The categories I added rules in are:

  • Security
  • Fields
  • ItemAxes
  • Database

Security

The first new FxCop rule I implemented is to make sure to use the Sitecore.Security.Accounts.UserSwitcher, rather than the Sitecore.SecurityModel.SecurityDisabler.
The SecurityDisabler elevates the users permission (temporarily) to administrator rights, which has the potential to be very dangerous to use and errors to potentially be very costly. An interesting side effect is that anything done with the SecurityDisabler will show up as being done by the sitecore\Anonymous role, messing up the audit trail.

However, if we use a UserSwitcher, we will actually tell the system to do something based on a user, with the access rights of that user. Consider the following code snippet:

namespace SomeNamespace
{
    public class SomeClass
    {
        var home = Sitecore.Context.Database.GetItem("{66EC0398-1E67-4D43-B2EB-ED29E3E8E291}");
        using (new Sitecore.SecurityModel.SecurityDisabler())
        {
            home.Delete();
        }

        Sitecore.Security.Accounts.User someUser = Sitecore.Security.Accounts.User.FromName(@"sitecore\SomeUser", false);
        using (new Sitecore.Security.Accounts.UserSwitcher(someUser))
        {
            home.Delete();
        }
    }
}

Assuming we have set up the access for the SomeUser account correctly, the home item will not be deleted with the UserSwitcher, but will be deleted with the SecurityDisabler, because we have effectively disabled all security there. In our case, because the SomeUser account has been set up correctly, an AccessDeniedException will be thrown.
Although this is a trivial example, it does point out the dangers of the SecurityDisabler.

The rule is actually also very easy, and is very similar to the rules described in earlier posts. The biggest difference is that because we’re now looking for a constructor rather than a method that’s been called, we need to override the VisitConstruct method.

public override void VisitConstruct(Construct construct)
{
    base.VisitConstruct(construct);

    Method method = (Method)((MemberBinding)construct.Constructor).BoundMember;
    if (method.FullName.Equals("Sitecore.SecurityModel.SecurityDisabler.#ctor", StringComparison.OrdinalIgnorecase)
    {
        this.Problems.Add(new Problem(this.GetResolution(method), construct));
    }
}

We don’t really care about anything else – if the SecurityDisabler is getting called, we want to add a warning that the UserSwitcher should be used.

Sitecore and FxCop – Accessing Raw Field Values

This is the second post in the Sitecore and FxCop series. Read the first post here. 

The second rule I came up with has to do with how to access raw field values.

Let’s say we want to grab the raw value of the Title field on the current item. There’s two different options we can use:

var fieldValue = Sitecore.Context.Item.Fields["Title"].Value;

Which really isn’t correct – what if there is no Title field? Or what if we have a typo in the fieldname? We’d end up with a NullReferenceException. To get around this we could use:

var field = Sitecore.Context.Item.Fields["Title"];
if (field != null)
{
    var fieldValue = field.Value;
}

The other option is:

var fieldValue = Sitecore.Context.Item["Title"];

In this case, if there is no Title field, or if we have a typo in the fieldname, we’d get an empty string.

To be absolutely clear, this is only to get the raw field value.  To display it on the front end side of things usually one would use a FieldRenderer instead anyway.

So, the second option is shorter and safer. Seems like a good thing to check for.

In the Rules.xml we need to add the following to our existing <Rules> definitions:

<Rule TypeName="AccessRawFieldValueProperly" Category="Sitecore.BestPractice" CheckId="SC002">
  <Name>Get the raw field value properly</Name>
  <Description>
    Accessing the raw field value through the Field property on the item can throw NullReferenceExceptions when
    the fieldname changes, the field doesn't exist or there's a misspelling in the fieldname.
  </Description>
  <Url />
  <Resolution>
    Raw field value is accessed by Item.Fields["Fieldname"].Value. Raw field values should be accessed by Item["fieldname"]
  </Resolution>
  <Email />
  <MessageLevel Certainty="70">Error</MessageLevel>
  <FixCategories>Breaking</FixCategories>
  <Owner />
</Rule>

As always, the TypeName needs to match the name of the class.

internal sealed class AccessRawFieldValueProperly : BaseRule
{
  public AccessRawFieldValueProperly() : base("AccesssRawFieldValueProperly")
  {
  }

  public override ProblemCollection Check(Member member)
  {
    var method = member as Method;
    if (method != null)
    {
      VisitStatements(method.Body.Statements);
    }

    return this.Problems;
  }

  public override void VisitMethodCall(MethodCall methodCall)
  {
    var memberBinding = methodCall.Callee as MemberBinding;
    if (memberBinding != null)
    {
      var methodCalled = memberBinding.BoundMember as Method;
      if (methodCalled != null)
      {
        if (methodCalled.FullName == "Sitecore.Data.Fields.Field.get_Value")
        {
          Problems.Add(new Problem(GetResolution(), methodCall));
        }
      }
    }

    base.VisitMethodCall(methodCall);
  }
}

Then, when I have a solution with the following code:

public void SomeMethod()
{
  var rawFieldValue1 = Sitecore.Context.Item.Fields["fieldname"].Value;
  var rawFieldValue2 = Sitecore.Context.Item["fieldname"];
  var field = Sitecore.Context.Fields["fieldname"];
}

I would expect to get one error in FxCop. I still want to be able to grab the actual field of course.

The correct error showing up

When I have a couple more rules in here I’m thinking about releasing this to the Sitecore Marketplace, so your input is very welcome. Is there any rule you would like to see added?

Sitecore and FxCop

I’ve been looking to create some FxCop rules for Sitecore development to get easier overviews to check (and possible enforce) using best practices on Sitecore development. This is the first post in a series of  Sitecore specific rules, which eventually (when there’s a couple of useful rules) will be released through the Sitecore Marketplace as well.

Creating custom rules for FxCop isn’t that hard, especially with some great resources such as this post. Following that post, there’s a couple of simple steps which boil down to the following:

Create a new class library project. The project will of course require references to the FxCop assemblies, FxCopSdk.dll and Microsoft.Cci.dll.

After that, create a rule definition XML, a BaseRule and a custom Rule which inherits BaseRule. The custom Rule can now contain some code that will show if the code is abiding by the rules or breaking them.

Before I give an example of my custom rules, please note that it’s very important to set the Build Action for the XML file as Embedded Resource, otherwise the error ‘Analysis was not performed; at least one valid rules assembly and one valid target file must be specified’ will be thrown.

No valid rules assembly and no valid target file

Oops…

I would strongly advise having a read through the blog post to get a better understanding what’s going on.

Sitecore rules

I’ve created a baseclass called BaseRule, which is exactly the same as in the blog mentioned earlier so I won’t describe that one. As for the rule I’ll describe here, I want to make sure that the GetItem method is called using a GUID, not a path.

To do this, I’ve created a Rules.xml which looks like this:

<?xml version="1.0" encoding="utf-8" ?>
<Rules>
  <Rule TypeName="GetItemUsingID" Category="Sitecore.BestPractice" CheckId="SC0001">
    <Name>Enforce calling the GetItem method using ID</Name>
    <Description>
      Use GUIDs where possible instead of path / name. This will improve performance, as well as prevent any breakage if you move content to a new location in the content tree.
    </Description>
    <Url />
    <Resolution>GetItem is called passing in {0}. GetItem should be called passing in an ID.</Resolution>
    <Email />
    <MessageLevel Certainty="80">Error</MessageLevel>
    <FixCategories>NonBreaking</FixCategories>
    <Owner />
  </Rule>
</Rules>

A couple clarifications: I’ve put the certainty on 80 for now, since all I’m doing is checking if there’s a string parameter that does not have a GUID. I completely ignore things like queries, empty IDs and the like.

Also, the Resolution message could be a little clearer, pointing out where the GetItem method gets called for instance, but for the purpose of this example it’s clear enough.

namespace Sitecore.FxCop
{
  using System;
  using System.Collections.Generic;
  using System.Text.RegularExpressions;
  using Microsoft.FxCop.Sdk;

  internal sealed class GetItemUsingID : BaseRule
  {
    public GetItemUsingID() : base("GetItemUsingID")
    {
      public override ProblemCollection Check(Member member)
      {
        Method method = member as Method;
        if (method != null)
        {
          this.Visit(method.Body);
        }

        return this.Problems;
      }

      public override void VisitMethodCall(MethodCall call)
      {
        base.VisitMethodCall(call);

        Method targetMethod = (Method)((MemberBinding)call.Callee).BoundMember;
        if (targetMethod.DeclaringType.FullName.Equals("Sitecore.Data.Database", StringComparison.Ordinal) && targetMethod.Name.Name.Equals("GetItem", StringComparison.Ordinal))
        {
          Expression endResponse = call.Operands["0"];
          if (endResponse.NodeType = NodeType.Literal)
          {
            var value = ((Literal)endResponse).Value.ToString();
            var match = Regex.IsMatch(value, @"\b[A-F0-9]{8}(?:-[A-F0-9]{4}){3}-[A-F0-9]{12}\b", RegexOptions.IgnoreCase);
            if (!match)
            {
              this.Problems.Add(new Problem(this.GetResolution(value, call))
            }
          }
        }
      }
    }
  }
}

A couple of interesting things here:

  • On line 8: The name of the class needs to be exactly the same as what’s defined in the XML definition.
  • On line 30: we only check the first parameter (so the parameter at index 0). This is because the GetItem method, when a path or GUID is used, will always have that path or GUID as the 0th parameter.
  • On line 31: we are only interested in that parameter when it’s a string. Remember, the first parameter for GetItem is either string, DataUri or ID. We could check them all of course, but right now I just want to make sure the first parameter is a string, and contains a GUID
  • On line 37: I pass in the value of the string that gets passed to GetItem, which will replace the {0} token defined in the XML with that value

So now consider the following code:

  var database = Sitecore.Data.Database.GetDatabase("master");
  var item1 = database.GetItem("/sitecore/content/home");
  var item2 = database.GetItem("{4E7AB8D1-6A39-4C8C-BF5B-816F8105BFFD}");

When I then add my custom rule to be inspected by FxCop, I get the following:

FxCop showing custom rule

A grand start, although I would still only get one message about GetItem even if I would have multiple instances of calling GetItem with a path in the same method.

Which FxCop rules would you like to have regarding Sitecore best practices?

SonarQube and TeamCity

Recently I attended a Sitecore Usergroup in London, with a talk about Continuous Integration by Andrew Thompson. Among other things, he was talking about SonarQube and how he implemented that in combination with TeamCity. I decided to try my hand on implementing it as well, but found the documentation (or findability of the documentation, more accurately) lacking.

Here are my finds:
I started with installing a local copy of it, with the integrated database. To do this I could simply follow the steps documented in the ‘Get Started in Two Minutes‘ guide.

As that was so easy I figured I’d implement this on our TeamCity server right away, but that was when things got a little more unclear. I tried following the installation guide as much as I could, but initially without the first step – Installing the Database, as I wanted to start off simple. Initially I’d install it with the embedded database (which would of course be a big no-no going forward, so it would have to change later on). Now, I hadn’t had any experience with anything like this before, so I wasn’t sure about the POM file or the properties file, and what I could do with them. A little reading up here told me it was a Project Object Model file, which as the documentation on POMs says: ‘It is a one-stop-shop for all things concerning the project’. Sample pom files for various languages can be found here. I used the sample C# file. A sample sonar.properties file can be found in the same project.

After I created my POM file and properties file I installed the SonarQube server on my TeamCity server. I installed this as a service using the “InstallNTService.bat” file and started the service by using the “StartNTService.bat” file. At the time, I wasn’t an administrator on the server, so I couldn’t initially, but after I had my access rights to the server changed I was able to execute both bat files. My first issue showed up here: I received an error about not being able to start the server because of the language (C#) plugins missing. This is also something the documentation addresses. After installing the C# plugins (which consists of downloading them and copying them into the <sonarfolder>\extensions\plugins folder) I tried running it again, but still no dice, this time I had an error about not being able to locate Java (although I can’t quite remember what the error was). The solution to this was fairly simple, add Java to the PATH environment variable.
This time I got the Sonar server started through the service.

Next step: I had to make sure that my code analysis would be executed from TeamCity, which as specified in the documentation consists of 4 steps:

  1. Make sure the ‘fail build if: at least one test failed’ is unchecked (this can be found in the Build Failure Conditions step in TeamCity).
  2. In the configuration for the Build Step select the runner type Maven with the goals ‘clean install sonar:sonar’.
    As additional Maven command line parameters set ‘-Dmaven.test.failure.ignore=true’
  3. Create a build trigger (I’ve set mine to a daily build)
  4. In the Build Parameters, in the Environment Variables, add a variable called MAVEN_OPTS and set the value to ‘-Xmx512m’.

From TeamCity I now started the project – and it failed. I changed the goal in TeamCity from: Clean install sonar:sonar To: Clean install sonar:sonar –X Which adds extended logging. The issue I was having was that it was using the wrong language (Java) even though I specified sonar.language=cs in my properties file. Adding <sonar.language>cs</sonar.language> to the POM file resolved this. For some reason, it looks like my environment is completely skipping the properties file, which I am currently looking into (although I don’t have too much time to spend on this as it’s already working through the POM file).

Now to remove the database and use a SQL database instead. I found this extremely helpful article to set up Sonar which told me I had to create a new database (I called it simply “sonarqube”) with the collate option SQL_Latin1_General_CP1_CS_AS. The article also gives a seperate link to settings you need to change to enable using a SQL database with SonarQube rather than the default embedded database.

In short, it consists of the following changes:

  • Create a new database (with collate option SQL_Latin1_General_CP1_CS_AS)
  • Set sonar.jdbc.username to the user you want to use
  • Set sonar.jdbc.password to the password of the selected user
  • Change the sonar.jdbc.url to Jdbc:jtds:sqlserver://<database server>;databaseName=database;selectMethod=cursor;
  • Change the sonar.jdbc.driverClassName to com.microsoft.sqlserver.jdbc.SQLServerDriver (this did not work for me – we’ll get to that in a second)
  • Set sonar.jdbc.validationQuery: select 1 (sonar.jdbc.validationQuery wasn’t in my properties file at all, so I had to add this. As I understand it its an optional parameter)
  • Set sonar.jdbc.dialect=mssql (which also wasn’t in my properties file, so added that too)

More information of course is available in the article itself.

After changing the properties to what’s specified in the previous link I was getting errors.
Initially because I didn’t have the correct database access rights for my sonar user, but even after I gave the user dbo access I was getting nowhere starting http://localhost:9000/ – something that was working before I changed databases. My logfiles (located in <sonarfolder>\logs) gave me an error with a huge stack trace, starting with:
Cannot connect to database. Please check connectivity and settings (see the properties prefixed by ‘sonar.jdbc.’). org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC driver class ‘com.microsoft.sqlserver.jdbc.SQLServerDriver’
That did give me a hint of course, and I changed the sonar.jdbc.driverClassName setting to net.sourceforge.jtds.jdbc.Driver (which was the default under SQL Server to begin with). If there’s no driver in <sonarfolder>\extensions\jdbc-driver\mssql it can be downloaded here. Be aware that there can be only one JAR file in that folder.
However, after that it still gave me an error:
INFO | jvm 1 | 2013/08/12 12:58:24 | java.sql.SQLException: No suitable driver
I wasn’t sure how to fix that, so I contacted Andrew to see if he could help out. He kindly agreed to help with my issues: I had my sonar.jdbc.url set to
jdbc:sqlserver://servername;databaseName=sonarqube;selectMethod=cursor;
but it needs to be
jdbc:jtds:sqlserver://servername;databaseName=sonarqube;selectMethod=cursor;
Next thing I encountered was the error
Fail to connect to database: Cannot create PoolableConnectionFactory (Connection is broken: “java.net.ConnectException: Connection refused: connect: localhost
I wasn’t using anything even remotely resembling localhost, so that confused me. Andrew to the rescue again, he was kind enough to send me over one of his POM files.
The difference: In the <properties> node he had the following:
<sonar.jdbc.url>jdbc:jtds:sqlserver://servername;databaseName=sonarqube;SelectMethod=Cursor;</sonar.jdbc.url>
<sonar.jdbc.driver>net.sourceforge.jtds.jdbc.Driver</sonar.jdbc.driver>
<sonar.jdbc.username>username</sonar.jdbc.username>
<sonar.jdbc.password>password</sonar.jdbc.password>
I initially had this in the .properties file, but SonarQube seems to be ignoring that file completely for some reason.

After I added this to my POM file it worked successfully and I could start improving the code.