Deserialization error submitting forms to AEM Forms JEE

Found an interesting bug (feature?) in AEM Forms 6.2 where you can’t submit your forms to an AEM Forms JEE Workflows server, even after configuring the DSCConfigService.

The errors you will see are similar to the following:

25.11.2016 09:55:14.210 *ERROR* [14.2.208.49 [1480028113565] POST /content/forms/af/[link-to-your-form]/jcr:content/guideContainer.af.submit.jsp HTTP/1.1] com.adobe.aemds.guide.servlet.GuideSubmitServlet Could not complete Submit Action due to An exception occurred processing JSP page /libs/fd/afaddon/components/actions/lcprocess/post.POST.jsp at line 79
org.apache.sling.api.scripting.ScriptEvaluationException: An exception occurred processing JSP page /libs/fd/afaddon/components/actions/lcprocess/post.POST.jsp at line 79
	at org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSlingScript.java:416)
...
Caused by: org.apache.sling.api.SlingException: An exception occurred processing JSP page /libs/fd/afaddon/components/actions/lcprocess/post.POST.jsp at line 79
	at org.apache.sling.scripting.jsp.jasper.servlet.JspServletWrapper.handleJspExceptionInternal(JspServletWrapper.java:683)
...
Caused by: com.adobe.aemds.guide.service.GuideException: Deserialization not allowed for class sun.util.calendar.ZoneInfo (on Fri Nov 25 09:55:14 AEDT 2016)
	at com.adobe.aemds.guide.addon.service.impl.GuideLCServiceConnectorImpl.invokeProcess(GuideLCServiceConnectorImpl.java:196)
...

Deserialization not allowed for class sun.util.calendar.ZoneInfo?? – that never happened in 6.1 or below…

Turns out you need to add the sun.util.* packages to the Deserialization Firewall config in OSGi (I didn’t even know that was a thing…). It is mentioned in the Adobe help but is very vague as to why.

The direct link to it on Publish would be similar to:

http://localhost:4503/system/console/configMgr/com.adobe.cq.deserfw.impl.DeserializationFirewallImpl

Just add a new package in the Whitelisted classes or packages prefixes and add the sun.util. package to it. Note the trailing period after “util”.

deserialization_firewall.png

Advertisements

PurgeProcess.bat fix

Update

This bug should be fixed in Core | Quick Fix 1048-010

There is a command line tool in AEM Forms JEE that allows you to purge processes from the system. It can be found in <install-dir>/sdk/misc/Foundation/ProcessPurgeTool folder.

Problem is, it doesn’t work. It throws an error similar to:

UNEXPECTED ERROR!!! See the stack trace below for details.
 java.lang.NoClassDefFoundError: org/apache/commons/httpclient/protocol/SecureProtocolSocketFactory
 at com.adobe.idp.workflow.ProcessPurgeTool.getSoapClientFactory(ProcessPurgeTool.java:197)
 at com.adobe.idp.workflow.ProcessPurgeTool.purgeProcess(ProcessPurgeTool.java:291)
 at com.adobe.idp.workflow.ProcessPurgeTool.main(ProcessPurgeTool.java:457)
 Caused by: java.lang.ClassNotFoundException: org.apache.commons.httpclient.protocol.SecureProtocolSocketFactory
 at java.net.URLClassLoader$1.run(Unknown Source)
 at java.net.URLClassLoader$1.run(Unknown Source)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 ... 3 more

Solution: you have to add %THIRDPARTY_DIR%\commons-httpclient-3.1.jar; to the SOAP_LIBS path in the batch file or shell script.

Windows Batch file

@ECHO OFF
SETLOCAL

IF NOT DEFINED LIVECYCLE_SDK_HOME (
ECHO Please set LIVECYCLE_SDK_HOME environment variable.
ECHO It should point to the LiveCycle SDK root directory.
ECHO For example: set LIVECYCLE_SDK_HOME=&amp;amp;quot;C:\Adobe\Adobe_Experience_Manager_forms\sdk&amp;amp;quot;
GOTO end
)

IF NOT EXIST &amp;amp;quot;%LIVECYCLE_SDK_HOME%\client-libs\common\adobe-livecycle-client.jar&amp;amp;quot; (
ECHO The LIVECYCLE_SDK_HOME environment variable seems to point to a wrong directory.
GOTO end
)

SET SDK_COMMON_DIR=%LIVECYCLE_SDK_HOME%\client-libs\common
SET THIRDPARTY_DIR=%LIVECYCLE_SDK_HOME%\client-libs\thirdparty
SET SOAP_LIBS=%THIRDPARTY_DIR%\activation.jar;%THIRDPARTY_DIR%\axis.jar;%THIRDPARTY_DIR%\commons-codec-1.3.jar;%THIRDPARTY_DIR%\commons-collections-3.1.jar;%THIRDPARTY_DIR%\commons-discovery.jar;%THIRDPARTY_DIR%\commons-logging.jar;%THIRDPARTY_DIR%\dom3-xml-apis-2.5.0.jar;%THIRDPARTY_DIR%\jaxen-1.1-beta-9.jar;%THIRDPARTY_DIR%\jaxrpc.jar;%THIRDPARTY_DIR%\log4j.jar;%THIRDPARTY_DIR%\mail.jar;%THIRDPARTY_DIR%\saaj.jar;%THIRDPARTY_DIR%\serializer.jar;%THIRDPARTY_DIR%\wsdl4j.jar;%THIRDPARTY_DIR%\xalan.jar;%THIRDPARTY_DIR%\xbean.jar;%THIRDPARTY_DIR%\xercesImpl.jar;%THIRDPARTY_DIR%\commons-httpclient-3.1.jar;
SET CLASSPATH=process-purge-tool.jar;%SDK_COMMON_DIR%\adobe-livecycle-client.jar;%SDK_COMMON_DIR%\adobe-workflow-client-sdk.jar;%SDK_COMMON_DIR%\adobe-jobmanager-client-sdk.jar;%SDK_COMMON_DIR%\adobe-usermanager-client.jar;%SOAP_LIBS%

CALL java -cp &amp;amp;quot;%CLASSPATH%&amp;amp;quot; com.adobe.idp.workflow.ProcessPurgeTool %*

:end
ENDLOCAL

Korn Shell script

#!/bin/ksh

if [ &amp;quot;$LIVECYCLE_SDK_HOME&amp;quot; == &amp;quot;&amp;quot; ] ; then
  echo &amp;quot;Please set LIVECYCLE_SDK_HOME environment variable.&amp;quot;
  echo &amp;quot;It should point to the LiveCycle SDK root directory.&amp;quot;
  echo &amp;quot;For example: export LIVECYCLE_SDK_HOME=/home/Adobe_Experience_Manager_forms/sdk&amp;quot;
  exit 1
fi

export SDK_COMMON_DIR=$LIVECYCLE_SDK_HOME/client-libs/common
export THIRDPARTY_DIR=$LIVECYCLE_SDK_HOME/client-libs/thirdparty
export SOAP_LIBS=$THIRDPARTY_DIR/activation.jar:$THIRDPARTY_DIR/axis.jar:$THIRDPARTY_DIR/commons-codec-1.3.jar:$THIRDPARTY_DIR/commons-collections-3.1.jar:$THIRDPARTY_DIR/commons-discovery.jar:$THIRDPARTY_DIR/commons-logging.jar:$THIRDPARTY_DIR/dom3-xml-apis-2.5.0.jar:$THIRDPARTY_DIR/jaxen-1.1-beta-9.jar:$THIRDPARTY_DIR/jaxrpc.jar:$THIRDPARTY_DIR/log4j.jar:$THIRDPARTY_DIR/mail.jar:$THIRDPARTY_DIR/saaj.jar:$THIRDPARTY_DIR/serializer.jar:$THIRDPARTY_DIR/wsdl4j.jar:$THIRDPARTY_DIR/xalan.jar:$THIRDPARTY_DIR/xbean.jar:$THIRDPARTY_DIR/xercesImpl.jar:$THIRDPARTY_DIR/commons-httpclient-3.1.jar
export CLASSPATH=./process-purge-tool.jar:$SDK_COMMON_DIR/adobe-livecycle-client.jar:$SDK_COMMON_DIR/adobe-workflow-client-sdk.jar:$SDK_COMMON_DIR/adobe-jobmanager-client-sdk.jar:$SDK_COMMON_DIR/adobe-usermanager-client.jar:$SOAP_LIBS

set -f

java -cp $CLASSPATH com.adobe.idp.workflow.ProcessPurgeTool &amp;quot;$@&amp;quot;

Removing HPROF dump files

LC_bugRevisiting the topic of Livecycle consuming everything in its path, I found another issue that features in Livecycle ES4 SP1. The symptoms are the usual symptoms; lack of disk space, server crashing, etc. After hunting down all of the extra large files in your system you might find a number of very large files in the following path:

[livecycle_install_dir]/crx-repository/launchpad/felix/bundle33/dumps

HPROF Files

Heap dump off

To turn this feature off, do the following:

  1. Browse to the AEM system console: http://host:port/lc/system/console
  2. Locate the bundle
    org.apache.felix.webconsole.plugins.memoryusage
  3. Stop the bundle

You can then stop Livecycle, delete the HPROF files and restart Livecycle. The bundle should not restart, but its worth checking anyway.

How to make JavaScript debugger in Designer work again

LC_bugIf you find that you can not debug your form JavaScript from within Designer, there is a good chance that Acrobat Pro is not configured correctly for debugging.

LiveCycle Designer attempts to preview PDFs by hooking into the current Adobe ActiveX Control add-on that is enabled inside Internet Explorer. This can be either Adobe Reader or Acrobat Pro. Acrobat Pro is required if you want to debug your JavaScript from within Designer. If you never see the Preview PDF option in Designer or it is greyed out, then try enabling the Adobe PDF Reader add-on within IE.

My problem was that I could not debug JavaScript from within Designer natively. Every time I tried to Preview certain PDFs, Designer would hang and FormDesigner.exe was left running when I closed Designer.

After many hours of hair pulling, uninstalling and re-installing Workbench, Designer, Acrobat (argh!) and generally going in circles I found that only forms that contained the FormBridge XFO were failing. Form Bridge is a JavaScript “bridge” library used to communicate externally with Workspace or Flex applications (Guides). It adds a script object to the hierarchy called ContainerFoundation_JS. When Preview PDF was invoked from Designer with this script added to the form, it would lock up.

The fix

It seems that if you set your JavaScript preferences in Acrobat Pro to Break when an exception is thrown – you’re gonna have a bad time…

Only use the Ignore or Trace settings, never Break as this actually breaks. Breaks Designer.

Acrobat Pro Preferences

Clean up after yourself

During this process and having to re-install everything multiple times, I was pointed in the direction of the Acrobat and Reader cleaner. Not to be confused with the Creative Cloud cleaner. The fact that any software requires a cleaner tool and doesn’t automatically clean up after itself both on installation and un-installation is a rant I choose not to go into right now for pure sanity reasons. Also be aware that the cleaner tool does not clean everything. I found remnants of Acrobat in my roaming profile under Windows 7 that even I could not delete and I was the local Administrator. </mini-rant>

aemblog

Everything AEM aka CQ5 based on my experience listed here.

Adobe AEM The Right Way

Best practices, tips, and tricks for your Adobe AEM project

/home/bkondepudi

A WCM journey with Day/Adobe CQ

Technoracle (a.k.a. "Duane's World")

A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.

Adobe LiveCycle Blog

A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.

A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.

XFA@Mobile

A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.

Code Monkey

Ramblings of a Developer