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 Sonar SonarQube and is intended to assist plugin authors in understanding what classes/resources are accessible to their plugins at runtime.

Sonar Class Loader


SonarQube Classloader

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 Sonar class 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

How to


Share Classes Between Plugins 


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 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.