xwork ModuleDescriptor errors during Confluence startup
Platform Notice: Data Center Only - This article only applies to Atlassian apps on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. 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
Summary
Confluence startup logs show errors indicating that the xwork module cannot be loaded for certain plugins because the ModuleDescriptor class is missing. This occurs in Confluence Data Center 8.0 and later versions, including 10.2.x, due to old, out of date, legacy plugin records in the database.
Environment
This issue affects Confluence Data Center versions 8.0 and later, where the legacy xwork module type has been removed from the plugin framework.
Diagnosis
1. Check the startup logs for xwork ModuleDescriptor errors
Search the atlassian-confluence.log for the following error pattern during Confluence startup:
"Cannot find ModuleDescriptor class for plugin of type 'xwork'"This is typically followed by one or more messages like:
"There were problems loading the module 'xwork' in plugin '<plugin name>'. The module has been disabled."Common plugin names that appear in these messages include:
User Lister
Advanced Macros
Confluence PDF Export
Confluence HTML Macros
Page Tree
2. Confirm the Confluence version
This issue occurs in Confluence Data Center 8.0 and later (including 10.2.x), where the legacy xwork module type was removed from the plugin framework.
3. Verify legacy records exist in the PLUGINDATA table
Run the following query against the Confluence database:
SELECT * FROM PLUGINDATA;Alternatively, if a Support Zip is available, locate the plugindata.csv file in the database-queries folder.
Look for entries with old JAR filenames and LASTMODDATE values significantly older than the current Confluence version — for example, plugin JARs dated from 2009–2012. These stale records are the source of the errors.
4. Confirm the errors are cosmetic
These errors do not prevent Confluence from starting or functioning normally. If Confluence is failing to start entirely, the root cause is likely something else — investigate other errors in the startup log.
Cause
In more recent versions of Confluence, the xwork module type is no longer registered as a first-class plugin module descriptor. While current versions of bundled plugins (like Page Tree or PDF Export) have been updated and are now bundled with Confluence, old records from previous versions of these plugins may exist in the PLUGINDATA table.
As a result, Confluence attempts to load these legacy records, fails to find the required class, and generates an error during start up. Please note that these errors are harmless and don’t prevent Confluence from working as expected.
Solution
To resolve these errors, you must identify and remove the legacy plugin records from the Confluence database. These plugins are now bundled with the application, and the old database entries are no longer required.
Step 1: Review the logging statements
First, working from a startup of Confluence, a message like the following should be present:
"timestamp:"2026-07-18 13:00:16,260 UTC" app:"MY-APP" level:"ERROR" thread:"Catalina-utility-1" class:"com.atlassian.plugin.internal.parsers.XmlDescriptorParserUtils" line:"60" method:"newModuleDescriptor" message:"There was a problem loading the descriptor for module 'xwork. Cannot find ModuleDescriptor class for plugin of type 'xwork'Following this, one or more messages like the following will be recorded with each of these representing a legacy plugin that is trying to load the xwork module. Here’s a list of examples involving some legacy plugins:
"timestamp:"2026-07-18 13:00:16,260 UTC" app:"MY-APP" level:"ERROR" thread:"Catalina-utility-1" class:"com.atlassian.plugin.internal.parsers.XmlDescriptorParserUtils" line:"56" method:"newModuleDescriptor" message:"There were problems loading the module 'xwork' in plugin 'User Lister'. The module has been disabled.
timestamp:"2026-07-18 13:00:16,469 UTC" app:"MY-APP" level:"ERROR" thread:"Catalina-utility-1" class:"com.atlassian.plugin.internal.parsers.XmlDescriptorParserUtils" line:"56" method:"newModuleDescriptor" message:"There were problems loading the module 'xwork' in plugin 'Advanced Macros'. The module has been disabled.
timestamp:"2026-07-18 13:00:18,533 UTC" app:"MY-APP" level:"ERROR" thread:"Catalina-utility-1" class:"com.atlassian.plugin.internal.parsers.XmlDescriptorParserUtils" line:"56" method:"newModuleDescriptor" message:"There were problems loading the module 'xwork' in plugin 'Confluence PDF Export'. The module has been disabled.
timestamp:"2026-07-18 13:00:19,417 UTC" app:"MY-APP" level:"ERROR" thread:"Catalina-utility-1" class:"com.atlassian.plugin.internal.parsers.XmlDescriptorParserUtils" line:"56" method:"newModuleDescriptor" message:"There were problems loading the module 'xwork' in plugin 'Confluence HTML Macros'. The module has been disabled.
timestamp:"2026-07-18 13:00:19,444 UTC" app:"MY-APP" level:"ERROR" thread:"Catalina-utility-1" class:"com.atlassian.plugin.internal.parsers.XmlDescriptorParserUtils" line:"56" method:"newModuleDescriptor" message:"There were problems loading the module 'xwork' in plugin 'Page Tree'. The module has been disabled.Step 2: Crosscheck log entries against the records in PLUGINDATA table to identify the problematic legacy plugins
Next, we’ll need to crosscheck these entries against the records within the PLUGINDATA table to determine which plugin entries are causing the problem and can be removed.
There are two ways to do this:
Run the following query against the PLUGINDATA table to get a list of all entries:
SELECT * FROM PLUGINDATA;Or, if you have a Support Zip file, expand the file and locate the plugindata.csv file within the database-queries folder.
Either way, within that output locate the plugin entries that match those mentioned in the above messaging and note the PLUGINDATAID value(s) as these will be used in the queries that follow.
For example, here’s what a list of problematic plugin records might look like:
PLUGINDATAID | PLUGINKEY | FILENAME | LASTMODDATE |
|---|---|---|---|
11108354 | confluence.macros.advanced | confluence-advanced-macros-1.12.3.jar | Jan 29, 2011 |
19562498 | com.atlassian.confluence.extra.flyingpdf | confluence-flyingpdf-plugin-1.12.jar | Jan 29, 2011 |
23396353 | confluence.macros.html | confluence-html-macros-2.0.2.jar | Nov 10, 2012 |
8486916 | com.atlassian.confluence.plugins.pagetree | pagetree-1.20.jar | Jan 29, 2011 |
11108359 | confluence.extra.userlister | downloadedPlugin.Qr6ajpwHnBdxsQsCi3rI.14201.jar | Dec 6, 2009 |
Step 3: Remove legacy records
Stop Confluence on all nodes.
Create a full backup of your Confluence database.
Run the following SQL to verify which legacy plugin records will be removed: DELETE FROM
SELECT * FROM PLUGINDATA WHERE PLUGINDATAID IN (<ID1>, <ID2>, <ID3>);Run the following SQL to remove the legacy records identified earlier:
DELETE FROM PLUGINDATA WHERE PLUGINDATAID IN (<ID1>, <ID2>, <ID3>);Start Confluence.
Review the atlassian-confluence.log to verify that the xwork ModuleDescriptor errors no longer appear.
Was this helpful?