Correction des erreurs de désérialisation après la mise à niveau d’AEM Forms

Dernière mise à jour : 31 octobre 2026

Après la mise à niveau de Adobe Experience Manager (AEM) Forms vers la version 6.5.25 sur IBM WebSphere Application Server 9.0.5.28, des erreurs de désérialisation apparaissent lors du démarrage du serveur et de l’exécution de Configuration Manager. Résolvez ce problème en configurant l’agent Java notsoserial avec un argument JVM requis qui initialise sa liste autorisée au démarrage car le client ne dispose pas de CRX.

Description description

Environnement

Produit : Adobe Experience Manager (AEM) Forms JEE
Version : 6.5.25, mise à niveau à partir de la version 6.5.23
Serveur d’applications : 9.0.5.28 d’IBM WebSphere Application Server
Système d’exploitation : Windows Server 2022 Datacenter

Problème/Symptômes

Après la mise à niveau vers AEM Forms 6.5.25 et le démarrage de l’application sur IBM WebSphere, un grand nombre de messages d’erreur Désérialisation non autorisée pour la classe s’affichent dans les journaux.
Les erreurs s’affichent au démarrage du serveur et lors de l’exécution de Configuration Manager.

Résolution resolution

Pour résoudre ce problème, procédez comme suit :

Assurez-vous que le fichier notsoserial.jar figure dans le répertoire utilisé par votre application AEM déployée sur WebSphere, tel que le répertoire installedApps pour votre instance de serveur d’applications.
Créez un fichier vide nommé is-deserialized.txt dans le même répertoire que notsoserial.jar.
Dans WebSphere Admin Console, accédez à Servers >[ your server] > Java and Process Management > Process Definition > Java Virtual Machine > Generic JVM arguments.

Ajoutez ou mettez à jour l’argument JVM suivant :

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

Remplacez <path-to-notsoserial.jar> et <path-to-is-deserialized.txt> par leurs chemins d’accès complets.

Supprimez tous les arguments JVM associés précédents, sauf si votre environnement les requiert spécifiquement :

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

Enregistrez les modifications et redémarrez le serveur d’applications WebSphere.
Après le redémarrage, vérifiez que les erreurs de désérialisation n’apparaissent plus dans les journaux SystemOut.log ou dans d’autres journaux pertinents au démarrage et lors de l’exécution de Configuration Manager.

Notes

La propriété -Dnotsoserial.dryrun force l’initialisation de la liste autorisée au démarrage, ce qui est nécessaire au bon fonctionnement pendant le démarrage JNDI.
Conservez ces arguments JVM en place pour les correctifs ou les mises à niveau ultérieures. Si des erreurs de désérialisation réapparaissent après la maintenance, vérifiez que ces paramètres sont toujours présents.
L’emplacement de notsoserial.jar diffère selon la structure de déploiement. Veillez à référencer le chemin d’accès correct pour votre environnement.
Aucune étape de dépannage supplémentaire n’est fournie en dehors des étapes ci-dessus.

recommendation-more-help

experience-cloud-kcs-help-kbarticles