These warnings in the log may also be accompanied by an Error 500 if you are attempting to call the LC services through a browser/web application.

Reason

This issue can occur when you are attempting to access the services with a user account that does not exist in the LiveCycle database, especially when you are migrating applications from one LiveCycle environment to another (e.g. ES2 to ES3). User accounts that were used by applications in the 1st environment will also need to be available in the 2nd environment.

Solution

Try whichever of the following solutions is applicable to your environment: (contact your LiveCycle administrator if you do not have sufficient privileges)

If you have installed ES3 SP1 (10.0.3) to your LiveCycle ES3 server and Workbench ES3 you may encounter a problem creating new processes. Selecting the menu item to create a new process does not have any effect. If you look in the Workbench log file (C:\Users\<YOUR_USER_NAME>\Workbench ES2\.metadata\.log) you may notice the following exception:

ES3 SP1 includes some feature enhancements in Process Management. This involved addition of new columns and tables to the existing ES3 DB schema and hence requires a DB re-initialization when running LCM.

Solution

You should always read the installation steps in the ES3 SP1 readme (link below) before attempting the installation. In this case, you will need to re-run LCM and select the step to initialize the database.

In LiveCycle ES it is possible to track the dependencies of parent forms to form fragments and vice versa using the functionality in Workbench ES.

In LiveCycle ES2 it is also possible to view the form fragments used by a parent form in Workbench > Form Design > Properties:

It is not possible to track the dependencies from a form fragment to see in which parent forms the fragment is used. This is due to the architectural changes related to the new application model in LiveCycle ES2.

In LiveCycle ES3 it is again possible to track the dependencies of parent forms to fragments and vice versa.

Solution

If you have a requirement to track the dependencies from fragments to parent forms in LiveCycle ES2, then you can do this using the LiveCycle API using code similar to below:

If you are installing and deploying patches for LiveCycle ES2 using the command line version of LiveCycle Configuration Manager (LCM) you may encounter an error similar to the following while deploying components:

com.adobe.livecycle.lcm.core.LCMException[ALC-LCM-030-200]: Failed to deploy component /opt/adobe/adobe_livecycle_es2/deploy/adobe-usermanager-dsc.jar. at com.adobe.livecycle.lcm.feature.deployment.DeployDSCs.deployDSCFiles(DeployDSCs.java:419) at com.adobe.livecycle.lcm.feature.deployment.DeployDSCs.deployDSCs(DeployDSCs.java:151) at com.adobe.livecycle.lcm.headless.HeadlessLCMImpl.deployDSCFilesLFS(HeadlessLCMImpl.java:285) at com.adobe.livecycle.lcm.cli.DeployLCComponentsCLI.executeCommandLineImpl(DeployLCComponentsCLI.java:96) at com.adobe.livecycle.lcm.cli.LCMCLI.execute(LCMCLI.java:298) at com.adobe.livecycle.lcm.cli.LCMCLI.main(LCMCLI.java:344)

and the LC logs may contain the following exception messages:

Component: com.adobe.PDFServices version: 9.0.0.2.20120202.1.312922
introduced a new service, it should not be patched

This problem occurs if the order of operations in LCM is incorrect. For example, if you run the deploy components step (DSCs), before configuring and deploying the new EARs. This can occur when using the command line LCM as you call each operation separately. It can also occur using the UI LCM if you run the tool twice in succession and select to deploy components in the 1st run before deploying the EARs in the 2nd run.

Solution

You should re-run the LCM steps ensuring to configure and deploy the EARs first, before deploying the components.

If you load the same XDP file in Designer ES2 and goto PDF Preview, you may notice the same message as a warning in the log, but the PDF will be correctly rendered and displayed:

Failure to automatically determine column '5' width

Reason

This exception is occurring because of a problem in the Form design. If you have a table in your form design with, let’s say 4 columns, you should check this table to ensure you don’t have a row with more than 4 fields defined. This can occur especially when you have created the field objects first, and then converted a whole collection of objects into a table later on. The extra (5th) field, can exist in a 4-column table if it has a width of “0”.

If you are attempting to configure Adobe LiveCycle server using the LiveCycle Configuration Manager (LCM) with an Oracle database, you may encounter the following exception during the DB configuration step:

Caused by: java.lang.UnsupportedClassVersionError:(oracle/jdbc/OracleDriver) bad major version at offset=6 at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:258) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:151) at java.net.URLClassLoader.defineClass(URLClassLoader.java:589) at java.net.URLClassLoader.access$400(URLClassLoader.java:123) at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:1034) at java.security.AccessController.doPrivileged(AccessController.java:279) at java.net.URLClassLoader.findClass(URLClassLoader.java:491) at java.lang.ClassLoader.loadClass(ClassLoader.java:631) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:597) at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:130) at com.adobe.livecycle.cdv.validator.DBValidator.validateDB(DBValidator.java:174)

Reason

This error can occur if you are not using the correct Oracle DB driver, or the correct Java JDK for your platform.

Solution

You should check the Oracle DB driver and JDK version required in the relevant platform matrix. With LiveCycle ES2 for example the platform matrix is located here:

If you are installing/uninstalling patches or service packs for LiveCycle ES you may encounter the following exception in the server log:

Caused by: javax.ejb.EJBException: Unexpected Error
java.lang.NoSuchMethodError: com.adobe.pof.omapi.POFQuery.addFilter(Ljava/lang/String;Ljava/lang/String;IJ)Lcom/adobe/pof/omapi/POFFilter;
at com.adobe.idp.event.util.EventDBHelper.getNewAsynchEventIDs(EventDBHelper.java:5704)
at com.adobe.idp.event.notification.NotificationManagerImpl$2.doInTransaction(NotificationManagerImpl.java:375)
at com.adobe.idp.dsc.transaction.impl.ejb.adapter.EjbTransactionCMTAdapterBean.execute(EjbTransactionCMTAdapterBean.java:342)
at com.adobe.idp.dsc.transaction.impl.ejb.adapter.EjbTransactionCMTAdapterBean.doRequiresNew(EjbTransactionCMTAdapterBean.java:284)
at sun.reflect.GeneratedMethodAccessor231.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.in

This exception will usually occur following the EAR deployment.

Reason

When you install/uninstall patches for LiveCycle ES they will update files included in the EARs and also the DSC component files which are then deployed as services. The versions of the EARs and components deployed must match, otherwise you will see this exception. If the versions do not match, then the components may be referencing Java methods which were added/modified in the later patch, and therefore not available in the EARs or vice versa.

This exception will often occur directly after the updated EARs are deployed but the components have not yet been updated, as these are two separate steps in LCM. Even after deploying the updated components the exception may still occur, as they are still loaded in the cache.

Solution

Ensure you have successfully completed deployment of the updated EARs and components. If the error is still occurring, then restart your application server and perhaps even clean the application server temp files before restarting. This should refresh all of the deployed services in the cache and the error should not occur.

If you have installed a patch or service pack for LiveCycle ES you may need to uninstall this at a later date, or you may have a requirement to document this process fully as part of your installation/configuration documentation.

This information is outlined in the readme file provided with each patch or service pack, and I will just expand on that giving some more detail here. In this example I will discuss uninstalling LiveCycle ES Update 1 SP4 (8.2.1.4), to go back to LiveCycle ES Update 1 SP3 (8.2.1.3) on Windows.

Preparation

Before installing/uninstalling any patch you should take note of the current versions installed so you can verify your steps have been successful later. Take a screenshot of the About screen, and the Service Management screen from the AdminUI.

AdminUI > About screen (note the Patch version “SP4″ and Service Pack version “8.1.5192.1.284202.47”, and the Patch level of each deployed component “SP4″):

Before running through the uninstallation process it would advisable to make a backup of your existing configuration in case any unexpected problems should arise. To do this, you should make a copy of the entire LiveCycle installation directory (excluding the MySQL folder if it exists within the LiveCycle directory).

You should also take note of the following configuration properties from AdminUI > Settings > Core System Settings > Configurations:

Location of temp directory

Global document storage root directory (Changing this value will result in data loss unless you also manually move the data)

Location of the Adobe Server Fonts directory

Location of the System Fonts directory

If you have LiveCycle Content Services ES installed, you should also have the location of the Content Services root directory which you entered during the original installation/configuration process.

Uninstallation

1. It is possible to leave your application server running for the moment, however you should stop your application server (JBoss, WebSphere, Weblogic) if possible.

2. Delete any files listed in <LiveCycle_HOME>\patch\SP4\backup_SP4\FilesAddedDuringServicePack_RemoveOrReplaceToRevert.txt from the <LiveCycle_HOME> directory. These are new/updated files which were added with this service pack/patch. To go back to a pre-SP4 state, we need to remove these files.

3. Copy all files under <LiveCycle_HOME>\patch\SP4\backup_SP4\ and paste them into their corresponding folder under the <LiveCycle_HOME> directory. This will overwrite the files which were updated by SP4 and restore them back to the SP3 state. This can include files in the configurationManager, deploy, LiveCycle_ES_SDK, and jboss folders.

4. Goto <LiveCycle_HOME>\licenses and edit each of the xxx.properties files. You will have a .properties file for each component installed, so you will need to perform the 2 steps below for each .properties file.

i). Delete the last PatchID section from the bottom of each file (in this case the entire SP4 section highlighted):

ii). Change the PatchVersion value at the top of the file to match the last PatchID now at the bottom (in this case SP3, as we just deleted SP4):

5. As we have now restored all the files in the <LiveCycle_HOME> directory, and have a backup of the SP4 configuration, we can now delete the EAR files in the <LiveCycle_HOME>\configurationManager\export directory.

6. Run Configuration Manager (LCM) and select the LC components you wish to configure.

7. Select the following tasks on the task selection dialog:

Configure LiveCycle ES

Deploy LiveCycle ES EARs (optional, you can also deploy the EARs manually once they are configured in the export folder, before initializing the DB)

Initialize LiveCycle ES database

Deploy LiveCycle ES components

Validate LiveCycle ES component deployment

8. Follow all the dialogs and check the values of the local folders which you noted in the preparation tasks.

9. Once LCM has successfully completed deploying the EARs and components, you should check the version numbers again in the AdminUI to ensure they now show the original version numbers (in this case SP3).

Note: if you see NoSuchMethodErrors in the server log, this would indicate that the DSC components do not match the version of the EARs deployed (e.g. the components are still SP4, whereas the EARs are SP3 or vice versa). Ensure you have successfully completed the EAR and component deployment, and you may need to restart your application server and perhaps even clean the application server temp folders to resolve such exceptions that appear in the server log.

If you are working with Content Services ES you may notice the following exception in the log files:

ERROR [org.alfresco.repo.admin.ConfigurationChecker] CONTENT INTEGRITY ERROR: System content not found in content store.ERROR [org.alfresco.repo.admin.ConfigurationChecker] Ensure that the 'dir.root' property is pointing to the correct data location.ERROR [org.springframework.web.context.ContextLoader] Context initialization failedorg.alfresco.error.AlfrescoRuntimeException: Ensure that the 'dir.root' property is pointing to the correct data location. at org.alfresco.repo.admin.ConfigurationChecker.check(ConfigurationChecker.java:312) at org.alfresco.repo.admin.ConfigurationChecker.access$000(ConfigurationChecker.java:72) at org.alfresco.repo.admin.ConfigurationChecker$1.execute(ConfigurationChecker.java:178) at org.alfresco.repo.transaction.RetryingTransactionHelper.doInTransaction(RetryingTransactionHelper.java:278) at org.alfresco.repo.transaction.RetryingTransactionHelper.doInTransaction(RetryingTransactionHelper.java:227) at org.alfresco.repo.admin.ConfigurationChecker.onBootstrap(ConfigurationChecker.java:182) at org.alfresco.util.AbstractLifecycleBean.onApplicationEvent(AbstractLifecycleBean.java:62)

Reason

This exception will occur when the data in the database is no longer synchronized with the data in the file system data store. Both must remain synchronized at all times, otherwise data loss will occur. It is part of the maintenance tasks to ensure that the following items are backed up regularly at the same time:

GDS document store (file system/network location)

Content Services data store (file system/network location)

Database schema

This information is described in detail with instructions in the LiveCycle Administration guide:

If the data in the Content Services data store is no longer synchronized with the data in the database, then this exception is thrown, as data integrity has been compromised. This can happen if another server/user has access to the file data store and makes changes, or if the data in the database is modified by another user/application.

It can also occur while performing configuration changes to your LiveCycle installation if the deployment of these changes quits unexpectedly leaving the database and local data stores out-of-synch.

Solution

To resolve this situation you will need to restore the components above from the last valid configuration.

If this is a fresh installation of LC content services, then you can drop the Content Services tables in the database, delete any content in the data store, and re-try the deployment. The following technote describes which tables you need to drop (i.e. it gives you the SQL commands to run):

The Content Services tables in the database get created while the adobe-contentservices.ear file is being deployed (not during database initialization). Once you have cleaned the DB and the data store, simply re-start the application server with the content services EAR file, and the tables will be re-created.

If you are running LiveCycle Configuration Manager (LCM) and deploying the components to a WebSphere server you may receive an error when it attempts to deploy the LCAs. If you check in the lcm.0.log you may see the following exceptions:

These errors can occur when the LiveCycle EAR files have not been deployed correctly to WebSphere. If you have deployed the EAR files manually after they have been configured in LCM, then you have forgotten to enable the “Generate Default Bindings” option while deploying the EAR files.

Solution

When you deploy each EAR file ensure you select the option to “Generate Default Bindings” in the WebSphere console:

This is described in the documentation also for manually deploying the EAR files to WebSphere:

These errors and related non-functioning of the LiveCycle components deployed is usually the result of an operating system update for the bind name server. These updates are provided by opensuse.org and may have been installed in the OS by the administrators.

These updates will break the functionality in any running LiveCycle server as it affects the communication protocols.

Solution

You will need to restart the entire Linux operating system to allow the updates to be successfully propagated into all the relevant applications.

If you are using the generatePDFOutput operation of the Output service to process a dynamic PDF document (i.e. to flatten it), you may notice that images referenced by relative paths are missing from the resulting flat PDF file.

This problem will be accompanied by exceptions in the server log similar to the following:

DataManager E com.adobe.service.DataManagerImpl createFileDataBufferFromUrl TRAS0014I:
The following exception was logged javax.ejb.EJBException: An unexpected exception occured:
ALC-REP-018-000: Resource [/orange_haus.jpg] does not exist or you do not have sufficient rights to access it.
at com.adobe.repository.bindings.url.provider.RepositoryUrlDataProviderBean.getInputStream(RepositoryUrlDataProviderBean.java:249)
at com.adobe.url.EJSLocalStatelessRepositoryUrlDataProvider_d16709f6.getInputStream(Unknown Source)
at com.adobe.url.Util.openUrlStream(Util.java:105)
at com.adobe.service.DataManagerImpl.createFileDataBufferFromUrl(DataManagerImpl.java:211)
at com.adobe.service.DataManagerPOATie.createFileDataBufferFromUrl(DataManagerPOATie.java:54)
at com.adobe.service.DataManagerPOA._invoke(DataManagerPOA.java:91)
...
Caused by: com.adobe.idp.dsc.DSCRuntimeException:
ALC-REP-018-000: Resource [/orange_haus.jpg] does not exist or you do not have sufficient rights to access it.
at com.adobe.repository.commands.RepositoryUrlDataProviderCommand.execute(RepositoryUrlDataProviderCommand.java:178)
at com.adobe.repository.commands.CommandProcessor.execute(CommandProcessor.java:135)
at com.adobe.repository.bindings.dsc.RepositoryProviderServiceImpl.repositoryUrlDataProvider(RepositoryProviderServiceImpl.java:674)
... 15 more
...
XMLFormServic W com.adobe.service.ProcessResource$ManagerImpl log ALC-XTG-029-698: [495864]
InvalidSourceException Exception on URL: repository:///orange_haus.jpg Exception: javax.ejb.EJBException: An unexpected exception occured:
ALC-REP-018-000: Resource [/orange_haus.jpg] does not exist or you do not have sufficient rights to access it.
XMLFormServic W com.adobe.service.ProcessResource$ManagerImpl log ALC-XTG-016-649: [495864]
Error attempting to read from file
XMLFormServic W com.adobe.service.ProcessResource$ManagerImpl log ALC-XTG-029-461: [495864]
XFAImageService: Image cannot be resolved for node: StaticImage1.

Reason

You may have rendered the PDF initially using the images referenced by relative paths (i.e. they were available at these relative locations on the server at render-time). This image content is then stored in the PDF file for the initial page views. Static PDF files do not re-render and therefore the image content already stored in the PDF remains valid, so the images are always displayed. Dynamic PDF files can re-render later (where the relative paths to the images may no longer be valid), in which case Acrobat/LiveCycle will attempt to resolve the relative paths to the images again.

Acrobat can display the images without any problems, even if you force Acrobat to re-render the PDF document (by merging again with data). Acrobat recognizes that the image is referenced by relative path, discovers it cannot resolve the path anymore, and therefore picks up the image content which is stored in the PDF already.

LiveCycle however does not handle this correctly. This is a bug in the Output service for PDF files with a target version > 8.0. If the target version is < 8.0 then the images are retained.

Solution

This issue will be fixed in the next LiveCycle ES2 service pack (if there is one) and future versions (e.g. ES3). There is a patch available for LiveCycle ES2 SP2 9.0.0.2 (XMF-2.204, FRM-2.202, OPT-2.201), so contact your LC support representative should you require this patch.

The solution exposes a new option “Use Following Resources from PDF” in the generatePDFOutput advanced settings. If you set this option to “IMAGES”, it will include the image content from the PDF, rather than attempting to resolve the relative path.