This article outlines the class loader hierarchy employed by Sonar and is intended to assist plugin authors in understanding what classes/resources are accessible to their plugins at runtime.
Sonar Class Loader
Sonar class loader on server-side is a class loader provided by application server.
Sonar class loader during Maven execution is a Maven plugin class loader :
- http://maven.apache.org/guides/mini/guide-maven-classloading.html
- https://cwiki.apache.org/MAVEN/maven-3x-class-loading.html
Sonar class loader during Ant execution is an Ant class loader :
Plugin Class Loader
For each plugin, a plugin class loader is created as a child of the Sonar class loader. By default plugin class loader uses parent-first delegation model.
Search order for parent-first model:
- parent class loader
- stuff exported from other plugins (see next section)
- stuff in plugin
A plugin can explicitly use the child-first model (see the property useChildFirstClassLoader). In this case search order is :
- stuff exported from other plugins (see next section)
- stuff in plugin
- 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 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.
For example the DBCleaner plugin shares the class org.sonar.plugins.dbcleaner.api.PeriodCleaner. Any plugin can use this class.
Labels
