Acrobat/Reader X: how to set the default font and font size in the Typewriter tool

Issue

If you are using the Typewriter tool in Acrobat/Reader you may notice that the default font and font size changes according to the font style already used in the PDF document.  The default font for the Typewriter tool should be set each time you finish using the tool and close Acrobat/Reader.  You may wish to reset/set the default font and font size to some custom value.

Solutions

You can set the commenting font and font size in the “Commenting” section in the Preferences.

You can also select the “Comment” Tab between “Tool” and “Share”, right-click on the comment in the “Comments List” that has your desired font setting, and then select “Properties…”.  Check the box that says “Make properties default” and click OK.

Workaround

If this still does not work, then you can set the default font and font size in the registry.  Please note that editing the registry can lead to corruption on your system and should only be attempted by experienced users or administrators.

We cannot provide support for any issues that may occur due to editing the registry, so we would recommend to do a full registry backup before making any changes.

To change the font:

1. Close Acrobat/Reader
2. Start—>Run—>Regedit
3. Navigate to: HKEY_CURRENT_USER\Software\Adobe\Adobe Acrobat\10.0\Annots\cAnnots\cFreeText_003aFreeTextTypewriter\crichDefaults\cfontFamily
4. Click the cfontFamily key on the left.
5. Double-click the a0 key on the right.
6. Change the a0 value to the font name you require.
7. Save

To change the font size:

1. Close Acrobat/Reader
2. Start—>Run—>Regedit
3. Navigate to: HKEY_CURRENT_USER\Software\Adobe\Adobe Acrobat\10.0\Annots\cAnnots\cFreeText_003aFreeTextTypewriter\crichDefaults
4. Double-click the dtextSize key on the right.
5. Change the dtextSize value to the font size value you require.
6. Save

Additional information

In Adobe Acrobat, if you want instructions to enable the Typewriter tool you should refer to the following post:

http://blogs.adobe.com/dmcmahon/2011/09/17/acrobatreader-x-how-to-enable-the-typewriter-tool/

In Adobe Reader, if you cannot find the Typewriter tool you should refer to the following post:

http://blogs.adobe.com/dmcmahon/2011/09/10/adobe-reader-fill-out-a-pdf-form-or-type-text-on-a-pdf-file-using-adobe-reader/

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

Acrobat/Reader 10: Save button not working for PDFs referenced from long URLs

Issue

If you are using Adobe Acrobat/Reader in Firefox/Chrome to view PDF files from long URLs you may notice that  the Save button is not working as expected.  It may be disabled (greyed out), or it may be enabled, but clicking on the button does not bring up the Save dialog to save the PDF to the local file system.

In some organisations the PDF files may be loaded from complex applications which require long URLs to serve parameters with the PDF.  For example:

http://helpx.adobe.com/content/dam/kb/en/837/cpsid_83709/attachments
/Acrobat_Enterprise_Administration.pdf?timestamp=t1115222011102&a=1234567890
123456789012345678901234567890123456789012345678901234567890123456789
&dkmtid=doc&ext=.PDF#FDF=http://server/XML.xfd

The URL above will show the PDF, but the Save button will not work as expected:

Reason

This is an issue with some versions of Adobe Acrobat/Reader 10 in Firefox/Chrome, and will be resolved in a later update for Acrobat/Reader.  The issue occurs when the URL contains more than 259 characters, as Firefox attempts to use this URL as the file-name in the Save dialog.  Such a long URL can exceed a file system limit and therefore the Save dialog does not appear.

Workarounds

  • Use shortened URLs to avoid the issue.
  • Use Acrobat/Reader in Internet Explorer.
  • Use Acrobat/Reader 9 with Firefox/Chrome.

Solution

This issue does not happen with the latest version of Acrobat/Reader 11, and will be fixed in a future release of Acrobat/Reader 10.

reference: (183411841/3319248)

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

CQ5.5: javax.jcr.RepositoryException: Unable to register data store in cluster

Issue

If you are installing and starting a new CQ instance you may experience the following exception:

*ERROR* [FelixStartLevel] org.apache.jackrabbit.core.RepositoryImpl failed to start Repository: Unable to register data store in cluster.
javax.jcr.RepositoryException: Unable to register data store in cluster.

Caused by: java.net.UnknownHostException: <server_hostname>: <server_hostname>
at java.net.InetAddress.getLocalHost(InetAddress.java:1360)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:211)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.<init>(Socket.java:375)
at java.net.Socket.<init>(Socket.java:218)
… 56 more

Reason

This typically happens if the name returned by the “hostname” command cannot be resolved.

Solution

Add the following entry to /etc/hosts (replacing <server_hostname> with the hostname of the server where the CQ instance is running):

127.0.0.1 <server_hostname>

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

CQ5.5: NullPointerException for wcm-mobile-core after installing SP1 or SP2.1

Issue

If you have installed CQ 5.5 SP1 or SP2.1 and restarted the instance you may notice the following exception in the logs on startup:

ERROR [Background Update com.day.cq.wcm.cq-wcm-mobile-core (219)] com.day.cq.wcm.cq-wcm-mobile-core [com.day.cq.wcm.mobile.core.impl.redirect.RedirectFilter]
The bindStats method has thrown an exception (java.lang.NullPointerException) java.lang.NullPointerException
at com.day.cq.wcm.mobile.core.impl.redirect.RedirectFilter.bindStats(RedirectFilter.java:173)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:227)
at org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38)
at org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:591)
at org.apache.felix.scr.impl.helper.BaseMethod$NotResolved.invoke(BaseMethod.java:548)
at org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:472)

Reason

This error is caused by an issue in the mobile redirect servlet in SP1 and SP2.1.  It will only affect this servlet, which gathers usage statistics on various categories of mobile devices.

Solution

If you do not require a fix for this servlet you can ignore this error.  The issue is currently scheduled to be fixed in the next service pack for CQ5.5.  If you require an urgent solution to this issue you can contact support through Daycare.

reference: (CQ5-18788/NPR-2071)

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

CQ5.5: Invalid links to DAM assets containing spaces in the file-name

Issue

If you are using the CQ5.5 authoring environment to add links to DAM assets through the rich-text editor dialog by drag-and-drop, then you may notice that some of these links will be marked invalid after clicking OK on the dialog.

A invalid link appears like the “banking” text below, whereas a valid link appears like the “investors” text.

You may also see errors similar to the following in the error.log:

*ERROR* [0:0:0:0:0:0:0:1 [1344244721052] GET /libs/wcm/core/content/pageinfo.json HTTP/1.1] com.day.cq.wcm.core.impl.servlets.PageInfoServlet Request path does not resolve to a resource: /content/dam/geometrixx/documents/GeoSphere_D%20a%20tasheet.pdf

Reason

The links are marked invalid when the assets in DAM contain spaces, or other characters such as !%$üäö, in the file-name (e.g. GeoSphere_D a tasheet.pdf).  Such file-names are being parsed by a URL encoder and the characters get converted by a URL encoder at the wrong place.

Workaround

You can workaround this issue by creating the link with the in-place editor, and also creating the link manually using the link button in the rte dialog, and selecting the document through the browse function. Only drag&drop directly onto the text in the rte dialog is not working.

Solution

This is a product issue with the rich-text widget and has been fixed in later product versions.

If you wish to resolve this issue in CQ5.5 you should contact support through Daycare and request hotfix “cq-5.5.0-hotfix-2390-1.zip”.  This hotfix has dependencies on other components, so the support team can advise you on installation order and requirements.

reference: (37103/NPR-2390)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 8.0/10 (1 vote cast)

CQ5.5: MCM emails contain URLs to author instead of publish

Issue

If you are using the Newsletter feature in MCM to send emails to lists of contacts you may notice that the URLs for assets in the email are pointing to the author instance, rather than the publish instance.  The links to the author instance will not work for external users, so the assets in the email will not show up.

Reason

This is a documentation issue as there is some further configuration required to substitute the links in the newsletter email so they point to the publish instance, rather than the author instance.  This will be addressed in a later version of CQ.

Solution

To resolve this issue in the meantime you should do the following steps:

  1. login to the system console on author (e.g. http://localhost:4502/system/console/configMgr)
  2. in the configuration tab search for the “Day CQ MCM Newsletter” bundle and open it
  3. take note of the fake host name in “Lookup for Sender Host” field (by default it is –publish–), i.e. the field should have http://–publish– in it
  4. open CRXDE Lite and goto /etc/map/http
  5. create a Node named –publish– of type sling:Mapping
  6. add a String property sling:match with value –publish–.80
  7. add a String property sling:redirect with value of your publish instance host name or IP including port(e.g. http://publishhost:4503)
  8. click Save All

Now when you send the newsletter it should substitute the author URL with the publish URL.

reference: (37433/CQ5-15440)

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

Acrobat: “Insufficient data for an image” error after updating to 10.1.4 or 9.5.2

Issue

If you have updated Adobe Acrobat/Reader to the current version 10.1.4 or 9.5.2 then you may encounter the following error when opening some PDF files:

“Insufficient data for an image”

The PDF will open, but the contents may appear blurred, or not display at all.

Reason

This error occurs due to a problem in the Adobe Acrobat/Reader functionality used to display scanned documents and/or documents containing JP2K images.

Solution

This issue has been fixed with the latest version of Reader XI now available (http://get.adobe.com/reader).  We are actively working on a solution for previous versions and expect to have a fix available for Adobe Acrobat/Reader 10.1.x and 9.5.x in Q1 2013.
Update (08 Jan 2013): this issue has now been fixed in the latest updates for Adobe Acrobat and Reader 9.5.3 and 10.1.5 available from the Adobe site:
Reader updates
Acrobat updates

Workarounds

Changing the zoom settings should allow you to see the contents of the document.  Try reducing the Zoom factor, or click the button to “Fit one full page to window”.

You can make this change persistent (to avoid changing for every document) in Edit > Preferences > Page Display > Zoom > Fit Page.

You can also try saving the PDF again in Acrobat using the PDF Optimizer to optimize the PDF file using Standard settings, or the Reduced Size PDF option.

For those looking to roll-back to a previous version of Adobe Acrobat/Reader to avoid this problem, you can find archived versions here: ftp://ftp.adobe.com/pub/adobe/reader/.

Further Information

This issue is being discussed in detail in the following forum threads:

http://forums.adobe.com/message/4632375

http://forums.adobe.com/message/4632511

http://forums.adobe.com/message/4630822

reference: (3312912/3312904)

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

CQ5.5 SP1: MalformedPathException: ‘:redirect’ is not a valid path. Prefix must not be empty

Issue

If you have updated to CQ5.5 Update 1 and you attempt to access a user profile page, for example the admin profile, as follows:

http://<server>:<port>/home/users/a/admin/profile.form.html/content/geometrixx/en/toolbar/profiles/edit
or
http://<server>:<port>/home/users/a/admin/profile.form.html/content/geometrixx/en/toolbar/profiles/view

you will see the following exception in the error.log:

*ERROR* GET /home/users/a/admin/profile.form.html/content/geometrixx/en/toolbar/profiles/edit HTTP/1.1] com.day.cq.wcm.core.impl.WCMDebugFilter Exception:  org.apache.sling.api.scripting.ScriptEvaluationException:
    at org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSlingScript.java:385)

Caused by: java.lang.IllegalArgumentException: javax.jcr.RepositoryException: Failed to resolve path :redirect relative to node /home/users/a/admin/profile

Caused by: org.apache.jackrabbit.spi.commons.conversion.MalformedPathException: ‘:redirect’ is not a valid path. Prefix must not be empty

Reason

This issue is caused by a regression in the 2.1 version of Sling which has been integrated with CQ5.5 SP1: https://issues.apache.org/jira/browse/SLING-2518

The issue does not occur with the 2.0.10 version of Sling included with CQ5.5.

Solution

This issue will be resolved in the next release of CQ5.5 SP2.

reference: (37322/CQ5-18799)

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

CQ5.4: how to force a delay between workflow steps

Information

If you are using workflows in Adobe CQ5.4 you may wish to have a customized delay between certain workflow steps.  It is possible to cause a delay using the timeout functionality which has pre-defined values (immediate, 1h, 2h, 6h etc…), and then select the Auto Advance timeout handler to move the workflow to the next step.

In some cases you may also want to define your own delay intervals rather than use the pre-defined values.  This is possible in CQ5.4 by creating an overlay of:

/libs/cq/workflow/components/model/step/tab_common/items/timeout/items/timeout/options

to:

/apps/cq/workflow/components/model/step/tab_common/items/timeout/items/timeout/options

and then you can make a copy of one of the existing nodes (1h, 2h etc…), and change the values to suit your needs.  The value should be in seconds and not milliseconds.

This new value will then appear in the workflow step configuration dialog, under the list of timeout values, and the step will timeout after the specified interval.

reference: (37175)

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

CQ5: Loading an image from a resource in a custom image renderer

Issue

If you are using a custom image renderer to handle image renders, you may notice that you cannot create a valid Image object from a referenced Asset in the DAM.  You are probably using code similar to the following:

//Note c is an ImageContext object
Resource r = c.request.getResourceResolver().getResource("/content/dam/geometrixx/travel/train_station_woman.jpg");
Image i = new Image(r);
if (!i.hasContent()) {
    resp.sendError(HttpServletResponse.SC_NOT_FOUND);
    return;
}

In the example code snippet above, hasContent() will always return false.

Reason

You cannot simply create an image or a layer directly from an image/file resource as obtained from the resolver.  You must first use the Asset class to get a rendition of the image.  Then you can work with that.

Solution

Use code similar to the following

//Note c is an ImageContext object
Resource  r = c.request.getResourceResolver().getResource("/content/dam/geometrixx/travel/train_station_woman.jpg");
Asset a = r.adaptTo(Asset.class);
Layer layer = ImageHelper.createLayer(
      c.node.getSession(),
      a.getCurrentOriginal().getPath()
)

reference: (36895)

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

Adobe Reader cannot open Protected Mode due to a problem with your system configuration.

Issue

If you are starting Adobe Reader and have Protected Mode enabled, you may encounter the following dialog:

“Adobe Reader cannot open in Protected Mode due to a problem with your system configuration. Would you like to open Adobe Reader with Protected Mode disabled?”

Reason

This dialog appears when protected mode cannot be started due to environmental settings on your computer.  It can occur due to anti-virus software conflicts, and/or conflicts with accessibility tools or smart card software and drivers.

Troubleshooting

1. Unsupported configurations:

  • Installing Reader on a mapped network drive.
  • Running Reader on WinXP when the OS is installed in a public folder.
  • Launching Reader in XP-compatible mode on Vista and Win7.
  • Launching Reader by right clicking AcroRd32.exe and choosing Run As.
  • Using PKCS#11 smart cards in signature workflows. Some cards can work in the presence of custom protected mode policies. For a workaround, see below.
  • Collaborating in real time using the Collaborate Live feature.
  • Certain configurations of anti-virus software that have not yet white-listed AcroRd32.exe. See Anti-virus software conflicts below.
  • JS-invoked processes: Launching a process through JavaScript is not allowed with Protected Mode enabled.

2. Antivirus software conflicts:

By default, Adobe Reader X runs in Protected Mode. In certain situations Reader experiences compatibility issues with anti-virus software when that software intercepts some system calls for the Reader sandbox. In these cases, Reader could fail to open or crash after displaying an incompatible-configuration dialog.

For example, Protected Mode is known to be incompatible with:

  • Some Symantec Endpoint Protection configurations. Adobe recommends that users update to Symantec Endpoint Protection 11.0 RU6 MP2 or higher.
  • McAfee VirusScan Enterprise for certain actions in Reader. Known actions include the following:
    • Clicking Help or a Weblink from an embedded Flash widget such as a Portfolio navigator (Fixed 10.1).
    • Launching of some IME tools. Note: Disabling Buffer Overflow Protection can provide a workaround for many McAfee users.
    • Reader sometimes removes a user’s cached credentials when signing out of Adobe.com which could be an issue for a multiuser machine. Fixed 10.1.2 with MVE 8.8.

Adobe is working with anti-virus companies to resolve these problems.

3. Accessibility

For XP only: Accessibility features sometimes doesn’t work. The Read Out Loud feature is unsupported. Therefore, screen readers such as JAWS, Windows Eyes, and Windows Narrator aren’t always able to read PDF content. Much of the Accessibility menus involving things like quick check, change Reading options are removed. Keyboard navigation is not implemented.

Note: When a screen reader like JAWS, Window-Eyes, or Narrator is running when Reader is started for the first time on XP, Protected Mode is disabled. On Vista and Windows 7, screen readers do work normally.

4. P11 smart card workaround

The installation of some smart cards doesn’t work for Reader X users when in Protected Mode. Because Protected Mode sandboxes certain processes that make system calls, smart card installation can fail or result in the “unsupported configuration” dialog appearing. However, a simple workaround is available. Install the smart card software with Protected Mode turned off as follows:

  • Disable Protected Mode by going to Edit > Preferences > General and deselecting Enable Protected Mode at startup
  • Restart Reader
  • Install the smart card software according to the provider’s instructions
  • Re-enable Protected Mode
  • Restart Reader

5. Windows Permissions

You should also check the permissions on the Adobe Reader installation folder.  Protected mode will only work on Windows when the group “BuiltIn\Users” has the following permissions on the Reader installation folder (for a default installation C:\Program Files (x86)\Adobe\Reader 10.0):

  • Read & execute
  • List folder contents
  • Read

Further Information

http://helpx.adobe.com/acrobat/kb/protected-mode-troubleshooting-reader.html

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

LiveCycle ES: ALC-PDG-001-001 The Job Configuration either cant be obtained or is invalid

Issue

If you are using PDFG to process documents on your LiveCycle server you may encounter problems with the conversions accompanied by the following exception in the server log:

GeneratePDFIm A com.adobe.pdfg.logging.PDFGLogger log ALC-PDG-001-000-Job ID for the submitted createPDF job =CreatePDF-2012-07-23 12-05-26.643.docdfaed6-f564cb-14cb09-338b02-c5fd79-ba0c90

GeneratePDFIm E com.adobe.pdfg.logging.PDFGLogger log ALC-PDG-001-000-ALC-PDG-001-001-The Job Configuration either cant be obtained or is invalid.  Invocation error.

AWS  E com.adobe.workflow.engine.PEUtil logFailedFaultRouting An exception was thrown with name com.adobe.livecycle.generatepdf.client.InvalidParameterException message:ALC-PDG-001-001-The Job Configuration either cant be obtained or is invalid.  Invocation error while invoking service GeneratePDFService and operation CreatePDF2 and no fault routes were found to be configured.

WorkflowDSCIn E com.adobe.idp.workflow.dsc.invoker.WorkflowDSCInvoker logFailedFaultRouting An exception was thrown with name com.adobe.livecycle.generatepdf.client.InvalidParameterException message:ALC-PDG-001-001-The Job Configuration either cant be obtained or is invalid.  Invocation error. while invoking service GeneratePDFService and operation CreatePDF2 and no fault routes were found to be configured.

JobManagerBea E com.adobe.idp.jobmanager.ejb.JobManagerBean doOnMessage JobManagerBean:onMessage():Exception:ALC-DSC-003-000: com.adobe.idp.dsc.DSCInvocationException: Invocation error.  Reference     I org.apache.xml.security.signature.Reference verify Verification successful for URI “#d6f16633df10d6efd649f0d2becce92c”

FileResultHan A com.adobe.idp.dsc.provider.service.file.write.impl.FileResultHandlerImpl tryPreservingFiles FileResultHandlerImpl —– preserved- source —-\\server\WatchedFolders\folder\stage\Wx840560ff8bdc142771fc0a18\CreatePDF-2012-07-23 12-05-26.643.doc— to —\\server\WatchedFolders\folder\failure\CreatePDF-2012-07-23 12-05-26.643\CreatePDF-2012-07-23 12-05-26.643.doc

Reason

PDFG uses file settings to specify what type of PDF file you would like to be generated.  These settings are stored in the LiveCycle server and can be referenced in the AdminUI:

http://livedocs.adobe.com/livecycle/8.2/admin_pdfg/000006.html

This exception occurs when you are converting files using the API, an orchestration, or a custom service, but the settings you have defined do not exist on the LiveCycle server.  This may happen if you have custom conversion settings and then deploy an application/process, which references these settings from one environment to another.  We have also seen this issue when the name of the conversion settings was localized (as LiveCycle was installed on a non-English OS), and therefore the name defined in the service by default was no longer valid.

Solution

You should check your code or custom service to ensure you are referencing a valid PDFG settings file.  You may need to import a settings file in the adminUI, if you use custom settings in your code/service.

reference: (183454350)

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

LiveCycle ES2: XMLForm.exe terminated abnormally with error code {3}

Issue

If you are using LiveCycle to process PDF documents you may encounter problems displaying/converting forms or PDF documents, accompanied by exceptions similar to the following in the server log:

ProcessResour W com.adobe.service.ProcessResource doProcessExitCleanup BMC024: Service XMLFormService: Process ProcessResource@f1f45(name=XMLForm.exe,pid=0) terminated abnormally with error code {3}

XMLFormAgentW E com.adobe.livecycle.formsservice.logging.FormsLogger logMessage ALC-OUT-002-004: Unable to find service: XMLFormService, error: Connection to failed service.

Solutions

The error message “XMLForm terminated abnormally with error code {3}” can occur in various situations, and the relevant solutions are described below.

1. The LiveCycle font directory is not valid

In this situation you should see a warning or error in the server log during startup similar to the following:

FontManager   E com.adobe.fontmanager.FontManager loadFromFontDirectories ALC-FMR-001-009:FontManager: Null/Non-existent font directory : /opt/server   /resources/fonts

When configuring LiveCycle you can enter a directory where fonts are stored and can be used by LiveCycle.  If this directory is not valid when calling XMLForm it can result in the error code {3}.

You can modify the location of the font directories in the administration console under Settings > Core System Settings > Configurations.  You will need to restart the application server after modifying these settings.

Further details here:

http://help.adobe.com/en_US/livecycle/9.0/adminHelp/admin.htm?content=000006.html

2. The LiveCycle root directory contains “null” in the path

This can occur particularly on Weblogic installations.  You should explicitly set the path using -Dadobeidp.RootDirectory=<path> in the server startup script.

Further details available here:

http://blogs.adobe.com/dmcmahon/2009/05/10/livecyclees-the-application-has-failed-to-start-because-omnidynamic403_rt-dll-was-not-found/

3. Solaris 10 Update 10 has been applied

If you have recently applied Solaris 10 Update 10 XMLForm may start failing with error code {3}.  There is a compatibility issue between the compiler settings that Adobe uses to compile the XMLFormService and some additions that Oracle have made to Solaris to support GNU extensions to their ELF symbol versioning.  What this means is that Solaris no longer recognizes XMLFormService as a valid executable and will not run it.

The best solution here is to update Solaris to a more recent version that contains the fix.  Details on exact versions can be attained from Oracle.

A workaround is to disable the run-time linker check by removing the DT_VERSYM entry from the objects dynamic section in libstdc++.so.6.

To apply the workaround you should run the following command on the libstdc++.so.6 file found in ServicesNatives2/lib directory:

% elfedit -e 'dyn:delete versym' libstdc++.so.6 libstdc++.so.6-alt

The workaround should only be applied by a sysadmin in critical situations, as it is a system change that may cause other side-effects.  You should make a backup of the original file before making that change.  Further details here: https://forums.oracle.com/forums/thread.jspa?threadID=2294952

You can find further details here:

http://helpx.adobe.com/livecycle/kb/xmlformservice-terminates-error-code-3.html

4. WebSphere global security is turned on

In this situation you will most likely see the following exception also in the server log:

CSIServerRIBa W   JSAS0638E: [com.ibm.org.omg.CORBA._ObjectStub.signalStringValue] Client authentication required at the server but no principal information is present in the <server>:<port> method request from client {2}.

We have seen this issue occur when strict global security was turned on in WebSphere and the clientcertificateauthentication for the csiv2inbound property in the WebSphere configuration was set to “Required” instead of “Supported”, and when the transport was set to “SSLRequired” instead of “SSLSupported”.  Change these to “Supported”, as shown below, to resolve this issue.

<csiv2inbound basicauthentication=”Supported” clientcertificateauthentication=”Supported” identityassertion=”false” stateful=”true” transport=”SSLSupported” sslconfigalias=””/>

<csiv2outbound basicauthentication=”Supported” clientcertificateauthentication=”Supported” identityassertion=”false” stateful=”true” sessiongcinterval=”300000″ sessiongcidletime=”900000″ transport=”SSLSupported” sslconfigalias=””/>

Further details here:

http://blogs.adobe.com/livecycle/2012/05/livecycle-xmlforms-native-process-and-websphere-global-security.html

5. SELinux security is in “enforcing” mode

If LiveCycle is running on a server where NSA Security Enhanced Linux (SELinux) is in enforcing mode, XMLForm will terminate with error code {3}.

To correct this problem, change SELinux security to permissive mode.

6. Other native library problems

To investigate native library problems you should enable debugging on the XMLForm process as follows:

  • On Unix/Linux deployments locate <XMLFormService/bin>/XMLForm.exe shell script and edit using a text editor.
  • Navigate to end of the file and you should see an “exec” line.
  • Modify “exec” line to include Corba debug parameters and add ldd/env commands before “exec” line as shown below.
 ldd $myPath/bin/XMLForm > /tmp/XMLForm.ldd_dump.txt
 env > /tmp/XMLForm.env_dump.txt
 exec $myPath/bin/XMLForm $* ORBtraceLevel 40  -ORBtraceThreadId 1
  • After that either restart your app server or kill XMLForms process instance(s) if running.
  • Render a form using FormsService or OutputService and new instance of XMLForms process should get launched.
  • Analyze the ldd_dump.txt, env_dump.txt, StdOut and StdErr logs looking for errors related to loading native shared libraries and/or Corba debug messages.

You can find further details on debugging in XMLForm here:

http://blogs.adobe.com/livecycle/2011/11/debugging-form-rendering-issues-related-to-xmlforms-native-process.html

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

LiveCycle ES2: This scheduler instance (SchedulerName) is still active but was recovered by another instance in the cluster

Issue

If you are working with LiveCycle ES2 in a cluster you may notice the following message in the server log:

org.quartz.impl.jdbcjobstore.JobStoreSupport findFailedInstances “This scheduler instance (<SchedulerName>) is still active but was recovered by another instance in the cluster. This may cause inconsistent behavior”.

Reason

This exception often occurs when the clock times on the cluster nodes are not synchronized.  If the clock times on cluster nodes are more than 1.7 seconds out of synch you will start to see these Quartz messages in the log.

Solution

Synchronize the time on all cluster nodes and then restart the cluster.  The messages should no longer appear in the log.

reference: (1647846)

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