Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

This article outlines the class loader hierarchy employed by SonarQube and is intended to assist plugin authors in understanding what classes/resources are accessible to their plugins at runtime.


SonarQube Classloader

SonarQube class loader on server-side is a class loader provided by The SonarQube classloader:

  • Server side - is provided by the application server.






For each plugin, a plugin class loader classloader is created as a child of the SonarQubeclass loaderSonarQube classloader. By default, the plugin class loader classloader uses parent-first delegation model.

Search order for parent-first model:

  1. parent class loader
  2. stuff classes exported from other plugins (see next section)
  3. stuff classes in plugin

A plugin can explicitly use the child-first model (see the property useChildFirstClassLoader). In this case, the search order is :

  1. stuff classes exported from other plugins (see next section)
  2. stuff classes in plugin
  3. parent class loader



This feature is implemented since version 2.4 for Maven 2 builds, and since version 2.5 for Maven 3 builds.

Each plugin has its own class loader, so by default a plugin can not cannot use a class defined in other plugins. This constraint can be bypassed if a plugin explicitly exports a subset of classes. These classes must be defined in the package "org.sonar.plugins.<plugin key>.api" or any of its potential sub-packages. For this reason this feature is reserved to the plugins hosted in the forge of open-source plugins.