When invoking the usage of a plugin that requests a child-first class loading strategy via setting
useChildFirstClassLoader in its Maven configuration, SonarQube does not set the thread’s context class loader to that of the child. This results in the plugin receiving the class loader of the parent (SonarQube), which will throw a
ClassCastException if there are any conflicting jars used between the plugin the parent.
This was experienced with the Fortify plugin and SonarQube 7.7 Enterprise Edition because SonarQube Developer Edition and Enterprise Edition both ship with /lib/common/javax.ws.rs-api-2.1.jar, while the Fortify plugin ships with jakarta.ws.rs-api-2.1.5.jar. It appears that SonarQube Community Edition does not ship with the JAX-RS jar and thus does not exhibit the issue (in this case), but the problem would still arise if there were to be a jar conflict.
We resolved this in the Fortify plugin by temporarily setting the class loader of the thread whenever the plugin was invoked, but all plugins should not have to do this; SonarQube should be setting the class loader for the executing thread properly and then resetting it if needed after the plugin has finished executing.
More details are available here, where the issue in the Fortify plugin was discussed and resolved: