Internal

Issue

If you are editing older XDP forms from LiveCycle Designer 7.1, or 8,  in Designer ES2, and you have hidden rectangle objects in the form design, you may notice that when selecting these hidden objects in the hierarchy, visible corners suddenly appear on these objects.  These hidden rectangle objects are created automatically when importing Word documents into Designer to create a form.

Reason

The problem is caused by the import from doc/PDF where the edge property for the rectangle is created and set to hidden, but no corners property is created.  When you create a new form in Designer (without importing), the edge and corner properties for a rectangle are always created together and the presence for both usually kept in synch.
It seems that when Designer finds a rectangle without a corner property it creates it automatically with visible corners.

Rectangle in XML after import from word:
               <rectangle>
                  <edge thickness=”0pt” presence=”hidden”/>
               </rectangle>

Rectangle in XML after selecting it on canvas:
               <rectangle>
                  <edge thickness=”0pt” presence=”hidden”/>
                  <corner radius=”5.08mm”/>
               </rectangle>

Rectangle in XML after manually fixing it in Designer (XML Source or Object Palette):
               <rectangle>
                  <edge thickness=”0pt” presence=”hidden”/>
                  <corner radius=”5.08mm” presence=”hidden”/>
               </rectangle>

Workaround

You can change the line style to “solid” and back to “none”, and then the corners property in XML is synchronized (presence=hidden) with the line edge property as expected.

Solution

This is an issue in LiveCycle Designer ES2 and will be fixed in Designer 10 and later versions.  If you require a quickfix for Designer 9 you should contact the enterprise support team.

The logic has now been changed, so that when Designer creates the corner property, it checks if the relevant edge is hidden, and sets the presence for the corners to match.

reference: (183589079/3322036)

Issue

After updating to LiveCycle Designer ES2 QF4 (9.0.0.2.20110401.1.827986), you may notice that you are no longer able to delete the default value in rich-text fields.  It is possible to edit the value, but when you delete it, the value will re-appear in the field after refreshing.  This only happens for rich-text fields and not standard text fields.

Solution

This is an issue in LiveCycle Designer 9.5 QF4 and has been addressed in later versions, including Designer 10.  If you require a quickfix for this issue in LiveCycle Designer 9 you should contact the enterprise support team.

Workaround

You can delete the default value by opening the XML Source tab and removing the value manually.

reference: (183571067/3318438)

Issue

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(GemfireCacheAdapter.java:164)
at com.adobe.livecycle.cache.adapter.GemfireCacheAdapter.createRootRegion(GemfireCacheAdapter.java:853)
at com.adobe.livecycle.cache.adapter.GemfireCacheAdapter.init(GemfireCacheAdapter.java:218)
at com.adobe.livecycle.cache.adapter.GemfireCacheAdapter.<init>(GemfireCacheAdapter.java:207)
at com.adobe.livecycle.cache.adapter.CacheAdapterFactory.getCache(CacheAdapterFactory.java:103)
…
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.

Reason

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

Gemfire version 6.5.1.17 was used for LC ES3 (10.0.2).  To address some known issues a new Gemfire version (6.5.1.35) 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.

Solution

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.

Workaround

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 GemFireVersion.properties 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)