Plugins failing to start due to 'plugin has an extra copy of atlassian-spring-scanner-annotation classes'
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Problem
When starting up Confluence, a number of built-in Confluence plugins fail to start.
In the atlassian-confluence.log,
errors such as the below will be thrown. This example is from the "baseurl-plugin":
Caused by: java.lang.IllegalStateException: Cannot execute atlassian-spring-scanner-runtime: plugin has an extra copy of atlassian-spring-scanner-annotation classes, perhaps embedded inside the target plugin 'com.atlassian.confluence.plugins.confluence-baseurl-plugin'; embedding scanner-annotations is not supported since scanner version 2.0. Use 'mvn dependency:tree' and ensure the atlassian-spring-scanner-annotation dependency in your plugin has <scope>provided</scope>, not 'runtime' or 'compile', and you have NO dependency on atlassian-spring-scanner-runtime.
Depending on the plugin that fails to start, this may trigger other problems. For example, if the synchrony-interop
plugin fails in a Confluence Server (non Data Center) environment, then Confluence will not start Synchrony, and Collaborative Editing will not work.
Cause 1
Some Atlassian plugins use an old version of the Atlassian Spring Scanner. Generally, this is not an issue, but with more powerful servers, Confluence can get into a race condition where the plugins can start up in such an order and speed that one plugin is reading spring annotations from another plugin that runs a different version. This causes the plugin initialization to fail. Some plugins may be able to recover from this, and others may not. This is a known bug: CONFSERVER-55916 - Spring scanner library should be updated to v.2 in all plugins.
Cause 2
This behavior can also be caused by third-party plugins, which declare the Spring scanner twice. The following report has more details on this problem:
Potential Workaround For Cause 1
- For any plugin that failed to start, go to the 'Manage Add-Ons' page in Confluence and attempt to manually enable the plugin.
- Re-start Confluence, and the race condition may not be triggered
Workaround For Cause 2
As of now, only the Tooltip for Confluence has been identified as a cause for this problem. If you are using it, try to disable the plugin then restart your instance. As an alternative, try to manually enable the system plugins in UPM after disabling the Tooltip add-on.