Customer had a working LiveCycle 90 SP1 cluster and they upgraded to SP2. After successful upgrade to SP2 (a.k.a 220.127.116.11) their forms were failing to render in workspace.
Error message indicated a generic ALC-WKS-007-027 for workspace rendering but server logs had different stacktraces which indicated a classloading problem for a DSC class “com.adobe.internal.pdftoolkit.pdf.document.PDFDocument”.
Caused by: java.lang.NoClassDefFoundError: com.adobe.internal.pdftoolkit.pdf.document.PDFDocument
at java.lang.J9VMInternals.verifyImpl(Native Method)
at java.lang.Class.newInstanceImpl(Native Method)
… 132 more
Caused by: java.lang.ClassNotFoundException: Class name com.adobe.internal.pdftoolkit.pdf.document.PDFDocument from package com.adobe.internal.pdftoolkit.pdf.document not found.
… 139 more
Tracing back we found that this class is shipped as part of LiveCycle DSC “adobe-pdfservices-dsc.jar -> pdfservices.jar”.
LiveCycle component architecture is based on OSGi and components (a.k.a. DSCs) are shipped as JARs and can be found under <LiveCycle Install>\deploy directory.
Once these DSCs are installed using LiveCycle Configuration Manager at deployment time, LiveCycle server extracts those to <LiveCycle TEMP>\ArchiveStore directory at startup and serves the classes from there at runtime.
In above situation, we manually installed “adobe-pdfservices-dsc.jar” using Workbench to take care of the problem.
After manually installing the component via workbench, form rendering worked fine; however problem resurfaced after cluster was restarted.
It looked like <LC TEMP\ArchiveStore> contained old version of the component and it was getting served after a restart.
In order to refresh component classes in <LC TEMP\ArchiveStore>; a) we stopped the cluster b) cleaned <LC TEMP> and c) restarted the cluster. Workspace form rendering worked consistently after that across cluster restarts.