Fix deserialization errors after upgrading AEM Forms

Last update: October 30, 2026

After upgrading Adobe Experience Manager (AEM) Forms to version 6.5.25 on IBM WebSphere Application Server 9.0.5.28, deserialization errors appear during server startup and Configuration Manager execution. Resolve this issue by configuring the notsoserial Java agent with a required JVM argument that initializes its allowlist at startup because the customer doesn’t have CRX.

Description description

Environment

Product: Adobe Experience Manager (AEM) Forms JEE
Version: 6.5.25, upgraded from 6.5.23
Application server: IBM WebSphere Application Server 9.0.5.28
Operating system: Windows Server 2022 Datacenter

Issue/Symptoms

After upgrading to AEM Forms 6.5.25 and starting the application on IBM WebSphere, a large number of Deserialization not allowed for class error messages appear in the logs.
The errors appear during both server startup and Configuration Manager execution.

Resolution resolution

To resolve this issue, follow these steps:

Ensure that the notsoserial.jar file is present in the directory used by your deployed AEM application on WebSphere, such as the installedApps directory for your application server instance.
Create an empty file named is-deserialized.txt in the same directory as notsoserial.jar.
In the WebSphere Admin Console, go to Servers >[ your server] > Java and Process Management > Process Definition > Java Virtual Machine > Generic JVM arguments.

Add or update the following JVM argument:

code language-none
`-javaagent:<path-to-notsoserial.jar> -Dnotsoserial.dryrun=<path-to-is-deserialized.txt>`

Replace <path-to-notsoserial.jar> and <path-to-is-deserialized.txt> with their full paths.

Remove any previous related JVM arguments unless your environment specifically requires them:

code language-none
`-Dorg.kantega.notsoserial.allow=... -Djdk.serialFilter=...`

Save the changes and restart the WebSphere application server.
After restart, verify that deserialization errors no longer appear in SystemOut.log or other relevant logs during startup and Configuration Manager execution.

Notes

The -Dnotsoserial.dryrun property forces initialization of the allowlist at startup, which is necessary for proper operation during JNDI bootstrap.
Keep these JVM arguments in place for future patching or upgrades. If deserialization errors reappear after maintenance, confirm that these settings are still present.
The location of notsoserial.jar differs depending on the deployment structure. Ensure that you reference the correct path for your environment.
No additional troubleshooting steps are provided beyond the steps above.

recommendation-more-help

experience-cloud-kcs-help-kbarticles