Archive for October, 2012

LiveCycle ES3 SP1: Gemfire errors in server log after installing patches on top of 10.0.2


If you are using TCP locators in a LiveCycle cluster with ES3 (10.0.2) and have installed a service pack or patches on top of this version, you may notice some errors in the server log similar to the following:

com.adobe.livecycle.cache.CacheRuntimeException: Error loading cache configuration
at com.adobe.livecycle.cache.adapter.GemfireCacheAdapter.getCacheContainer(
at com.adobe.livecycle.cache.adapter.GemfireCacheAdapter.createRootRegion(
at com.adobe.livecycle.cache.adapter.GemfireCacheAdapter.init(
at com.adobe.livecycle.cache.adapter.GemfireCacheAdapter.<init>(
at com.adobe.livecycle.cache.adapter.CacheAdapterFactory.getCache(

Caused by: com.gemstone.gemfire.SystemConnectException: Attempt to connect to distributed system timed out

If you have a UDP-based cluster caching mechanism, you are not affected by this issue.


This issue occurs when the Gemfire version on the server is different from the Gemfire version used by the TCP locators.  Gemfire.jar and are delivered in two different places in the LC installation – 1. Core EAR 2. /lib/caching directory.

Gemfire version was used for LC ES3 (10.0.2).  To address some known issues a new Gemfire version ( was used in later versions and patches.  This newer Gemfire version was used for the Core EAR, but unfortunately not included for updating the caching directory.

To verify the issue, compare the Gemfire version in the GFLocator.log file for your TCP Locator with the Gemfire version in the Gemfire logs for your application server at the following location:

  • JBoss: <adobe_temp_dir>/adobejb_<server_name>/caching/Gemfire.log
  • Weblogic: <adobe_temp_dir>/adobewl_<hostname>/caching/Gemfire.log
  • WebSphere: <adobe_temp_dir>/adobews_*/caching/Gemfire.log

You will find that Gemfire on the LiveCycle server has a higher version.


This issue has been addressed in SP2 and later patch versions.

Note: the patch installer will only update the default caching directory (<lc_install_dir>/lib/caching) on the machine where LC is installed.  If you are running LC on various machines, and/or use custom caching directories, you will need to update the 2 Gemfire files for your TCP locators manually.  All TCP locators need to be restarted before starting LC servers.


For existing patches you can use the following workaround to fix the issue on your LiveCycle installation.

  1. Stop the LiveCycle server(s).
  2. Stop the TCP Locator(s).
  3. Go to <LC_INSTALL_DIR>/deploy folder.
  4. Open adobe-core-<appserver_name>.ear.
  5. Go to TCP locator installation directory. Typically the default location is <LC_INSTALL_DIR>/lib/caching.
  6. gemfire.jar and can be found here.
  7. Replace the two files above in the TCP locator with the same files from the core ear.
  8. Repeat the replacement procedure (steps 5 – 7) for each TCP locator.
  9. Start TCP Locator(s).
  10. Start LiveCycle server(s) in the Cluster.

Verify the Gemfire versions in GFLocator.log and Gemfire.log files. You should see the same Gemfire version in both files.

reference: (183615151/3327651)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 7.7/10 (3 votes cast)

Acrobat 10.1.4: Acrobat/Reader hangs while scanning


If you are scanning documents with Acrobat/Reader 10.1.4 using any mode (Grayscale/Color/BW),  Acrobat/Reader may hang when scanning is about to complete.


This is an issue in the 10.1.4 update and will be addressed in future versions.  It is also being discussed in our forums:


Install the patch for Acrobat and Reader 10.1.4 (Windows only).

  • Log in to your Windows computer as an Administrator.
  • Click the following link to download the patch file:
  • When prompted “Do you want to open or save this file?,” click Open.
  • Extract the file using a ZIP tool to a location on your local computer.
  • Double-click the AdobeAcrobatReaderPatch10.1.4_3314564.exe file to begin the update.
  • When a prompt notifies you that the update is complete, restart your computer.


 Install the patch for Acrobat and Reader 10.1.4 in silent mode (Windows only).
  • Log in to your Windows computer as an Administrator.
  • Click the following link to download the patch file:
  • When prompted “Do you want to open or save this file?,” click Open.
  • Extract the file.
  • Open the command prompt “As Administrator.”
  • Type the path to the patch file executable, and add the -silent flag on the command line. For example:
    AdobeAcrobatReaderPatch10.1.4_3314564.exe -silent
    Silent mode suppresses all dialog boxes so you do not get a message indicating that the update is complete. The executable creates a log file “AcroPatchApplication1014.log” in the temp directory (%temp%).
  • When the update is complete, restart the computer.

reference: (3314564)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 5.8/10 (4 votes cast)

Acrobat XI: new tab-stop feature available for rich-text fields


With the latest release of Adobe Acrobat/Reader XI there is a new feature available for structuring text in rich-text fields in XFA-based forms.  You can now add/modify tab-stops in rich-text fields using new UI components.  Adding tab-stops in rich-text fields allows for better formatting and table-like structuring of the text, which is a much requested feature from customers and users.


You download the sample file tabstops_richtext_field_dyn.pdf to see how this feature works.

1. Open the sample file in Acrobat/Reader XI.

2. Place the cursor in the large rich-text field.

3. Press CTRL+E on the keyboard to bring up the Form Field Text Properties toolbar.

4. Click the button “More…”

5. You will see the new Tabs dialog where you can create/modify the tabs in the field.

6. From here you can create/modify/delete the defined tab-stops, and change the alignment (Left, Right, Center, Decimal), or the position.


You can now also use the key combination CTRL+TAB on the keyboard to tab between tab-stops in the rich-text field.

The measurement units for the tab stops are inherited from the units defined in the Preferences (Edit > Preferences > Units & Guides > Page & Ruler Units):

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 8.5/10 (2 votes cast)

CQ5: new page/site buttons disabled in WCM siteadmin


If you are using WCM siteadmin and wish to create a new page/site using the available buttons, they may appear disabled so that you are unable to click on them.  Firstly, you should check your permissions for these actions and/or check with an administrator or admin account.  If these problems persist it may be related to an issue in your repository structure.


These buttons can also be disabled if there is an invalid Page node in the /content tree.  A cq:Page node must have a child named jcr:content of type cq:PageContent, otherwise it is invalid and can lead to this issue.  The root /content node is not of type cq:Page and therefore does not require a jcr:content child of type cq:PageContent, but every other Page node below /content should have this structure.

It seems that if the invalid node is a top-level page/site in the content tree (e.g. /content/geometrixx) then it will affect the site actions for all other top-level nodes, and other nodes in that specific tree.
If the invalid node is a sub node (e.g. /content/geometrixx/en/services), then it seems to only affect the site actions for that level in that tree.

Such invalid nodes can appear in the tree if they were created outside of WCM (i.e. using CRXDE, or Content Explorer), or by importing a package containing such invalid nodes.


Check your content tree for such invalid page nodes, and repair the nodes as required, by creating a jcr:content child node of type cq:PageContent.

reference: (37890)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 10.0/10 (4 votes cast)