How to Deal with LiveCycle DSC Classloading Problems

Scenario:

Customer had a working LiveCycle 90 SP1 cluster and they upgraded to SP2. After successful upgrade to SP2 (a.k.a 9.0.0.2) 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.J9VMInternals.verify(J9VMInternals.java:69)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:131)
at java.lang.Class.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1328)
at com.adobe.idp.dsc.registry.component.impl.ComponentRegistryImpl$12.doInTransaction(ComponentRegistryImpl.java:897)
at com.adobe.idp.dsc.transaction.impl.ejb.adapter.EjbTransactionBMTAdapterBean.doRequiresNew(EjbTransactionBMTAdapterBean.java:218)
… 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.
at com.adobe.idp.dsc.DSContainerSearchPolicy.searchClassUsingParentLast(DSContainerSearchPolicy.java:346)
at com.adobe.idp.dsc.DSContainerSearchPolicy.findClass(DSContainerSearchPolicy.java:200)
at org.ungoverned.moduleloader.ModuleClassLoader.loadClass(ModuleClassLoader.java:161)
at java.lang.ClassLoader.loadClass(ClassLoader.java:605)
… 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.

Solution:

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.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 8.0/10 (5 votes cast)
How to Deal with LiveCycle DSC Classloading Problems, 8.0 out of 10 based on 5 ratings

About Santosh Tatke

Santosh Tatke is a Sr. Support Architect at Adobe Systems. He specializes in ADEP (formerly LiveCycle) technology stack and works closely with customers, solution consultants and partners to troubleshoot, analyze and resolve technical challenges during POC, implementation, deployment or upgrade. He is a Certified LiveCycle ES2.5 Process Management Expert.
This entry was posted in ADEP, Adobe LiveCycle ES2 (9.0.x), Adobe LiveCycle ES3, Document Services, General Interest and tagged , , , . Bookmark the permalink.

One Response to How to Deal with LiveCycle DSC Classloading Problems

  1. great articles and stylish website, keep up with the good work guys. lista de emails lista de emails lista de emails lista de emails lista de emails