Posts tagged "service"

CQ5.5: When to restart CQ after installing a service pack


If you are installing a service pack (SP) on top of CQ5.5 you will see a dialog recommending to restart the instance after you have run the SP installation:

Do not restart the instance at this point, as the contents of the service pack are still being extracted and installed in the background.  Restarting at this point could result in unknown problems, and you may have to repeat the SP installation.


You can monitor the log output in error.log and wait until the log no longer has new “BundleEvent STARTED” entries, before restarting the instance.  This usually takes 2 – 5 minutes depending on server specifications.

Monitoring log output may not be a good solution for large enterprise organisations which may have many CQ instances to update, and may need to use some kind of automated install script or process documentation.  In this case, you can either add a pause to the installation documentation (e.g. 15 or 30 minutes), or use a script to check for installation completion as described under 2 below.

1. Monitor the log output to figure out when to restart

The release notes for SP2.1 do contain instructions relating to this process (

Quickstart Install Process

  1. Login to Package Share and download SP2 package:
  2. Back in Package Manager – Install package
  3. After the package install is done – the PackageManager tells you to restart. DO NOT RESTART. The actual install of the package only starts now in background, given that the packages have been placed in /install folders. The best way to follow the process of the install is to tail the error.log
    The background install starts with “ Extracting day/cq550/update:cq-update-pkg:5.5.8” and stops with bundles been restarted – best seen by “BundleEvent STARTED” log entries.
  4. After the error.log goes quiet with “BundleEvent STARTED” messages
  5. Restart the instance
  6. The Welcome Screen should now show the updated Version String: Adobe CQ, Version Service Pack 2

2.  Use a script to automatically check for installation completion

You can use the script below which polls the server to check when the SP contents have been extracted, and then waits another few minutes for the relevant bundles to be started.  You can use the script on its’ own, or you could integrate it into existing scripts which you use to automatically install the CQ servicepack.

1. use a script similar to the following (designer for CQ5.5 SP2.1, you may need to adjust the cq-update-pkg version for other service packs)

until [ $res -eq 0 ]
    curl -u admin:admin -D- http://<cq_server_hostname>/etc/packages/day/cq550/update/ 2>/dev/null | head -1 | grep -q “HTTP/1.1 200”
    if [ $((count++ % 10)) -eq 0 ]
     echo “Waiting for service pack installation to finish…”
    sleep 1
sleep 300
echo “Service pack installation complete. You can restart the instance now.”

2. start the script in a terminal
3. install SP2.1
4. check the script output and await the completion message

5. restart the instance

reference: (39810/CQ5-22648)

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

CQ 5.5 Update 1: Service unavailable – AuthenticationSupport service missing. Cannot authenticate request.


CQ 5.5 Update 1 is now available on PackageShare.  If you have installed CQ 5.5 Update 1 you may encounter the following error in the error.log after restarting the CQ instance:

*ERROR* [0:0:0:0:0:0:0:1%0 [1340016598398] GET / HTTP/1.1] handleSecurity: AuthenticationSupport service missing. Cannot authenticate request.


After installing the Update 1 package, an info dialog appears which advises to “restart the instance”.  If you restart the instance immediately after the dialog appears, you will run into this problem.  Even after the dialog appears, the package keeps on installing behind the scenes.  This process is interrupted if the instance is restarted at this point.

You should wait until the installation has completed before restarting CQ5, checking the activity in error.log.  Once the error.log becomes quiet (after approx. 5 mins) it is safe to restart the instance.


After installing Update 1 check that all OSGi bundles have the status “ACTIVE” in the OSGi console.  Start any bundles that do not have the “ACTIVE” status and this should resolve the issue.

If the issue persists, you may have to reinstall CQ5 from a fresh copy, install the update 1 package, restart (wait until error.log shows no more activity) and finally reinstall your installed packages manually.

reference: (CQ5-18534)

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

CQ5.5: NullPointerException trying to reference an OSGi component/service using SCR annotations


If you are trying to reference an OSGi service or component using the SCR annotations, like the SlingRepository in the code below, then you may encounter a NullPointerException when you try to use these objects.

  * @scr.component immediate="true"
  * @scr.service interface="SampleService"
 public class SampleServiceImpl implements SampleService {
      * @scr.reference
     private SlingRepository repository;

Another symptom of this problem is that your SampleService component may not show up or register correctly in the CQ5 Web Console “components” tab (http://<server>:<port>/system/console/components).


The SCR annotations are deprecated in the latest builds of Apache Felix.

You should note that CRXDE and CRXDE Lite are both configured to automatically resolve these annotations and build the relevant XML files for you.  In other IDE environments you will have to include the maven-scr-plugin to resolve these annotations and build the XML files yourself.


To correctly reference these objects in the latest versions you should use the following syntax (note: you will have to explicitly import the Felix scr classes):

 import org.apache.felix.scr.annotations.Component;
 import org.apache.felix.scr.annotations.Service;
 import org.apache.felix.scr.annotations.Reference;


 public class SampleServiceImpl implements SampleService {

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

LiveCycle ES: how to uninstall a patch or service pack


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 (, to go back to LiveCycle ES Update 1 SP3 ( on Windows.


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”):

AdminUI > Services > Applications and Services > Service Management screen (note the Component Versions “8.1.5192.1.284202.47”, “8.1.5193.1.279333.70”, etc…):

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.


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

AdminUI > About screen:

AdminUI > Services > Applications and Services > Service Management screen:

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.

reference: (182873522)

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

LiveCycle ES2: service version not updated when patching DSC components


If you are patching DSC components through Workbench and using version numbers to track your updates, you may notice that the version of the service does not get updated.  The service has actually been updated and the new functionality should be available.


This is a product issue in LiveCycle ES2 where the service version number does not get updated correctly when deploying an updated component.  You can check the version numbers in Workbench after deploying the component, or you can check in AdminUI > Services > Applications and Services > Service Management:

The version numbers for the services can be updated in the component.xml file included with your DSC component JAR file.  The following line is used to define the service version number:

      <auto-deploy service-id=”Log” minor-version=”0″ major-version=”1″ category-id=”neo-onboarding”/>


This issue is fixed in ES3 (LiveCycle 10).  There is a patch available for LiveCycle ES2 SP2 ( and LiveCycle ES SP4 (, so contact enterprise support if you require one of those patches.

With the fix, the service versions will be updated correctly as follows:

reference: (182724548/2749526)

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

LiveCycle ES2: using password protected WSDL


When you try to load a password-protected WSDL using the WebService service in LiveCycle ES2 (, the following exception occurs: thrown: Server redirected too many times (20)


This is a bug in LC ES2.  Update to LiveCycle ES2 SP1 or later.  Contact Enterprise Support if you require a patch for LiveCycle ES2 (

reference: (2466491)

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

LiveCycle PDFG7: how to remove the SQL service after uninstalling


If you have uninstalled PDF Generator 7.2.2 you may notice that the SQL service has been left behind.  You will need to remove this service manually to do a completely clean uninstallation.


 In order to remove the SQL service in Windows, you can follow these instructions:

Run Regedit or regedt32.

Find the registry entry: HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services

Find the service there and delete it.

You may wish to look at the keys and see what files the service was using and perhaps delete them also.

Note:  You will have to reboot before the list gets updated in server manager.

Additional Information

 Some programs change the permissions to make it more difficult for you to delete them. For these you will have to right click on the “service” in regedit, go to permissions and grant the administrator full control before the service can be deleted.

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

LiveCycle ES: “ALC-WKS-005-029: A problem occurred in the Submit Service” error submitting a form in Workspace


 When you are trying to submit a form in Workspace with LiveCycle ES you may receive the following error in the Workspace UI:

Task 101 has failed to submit. (ALC-WKS-007-072)

and the following exception in the server log:

2009-06-24 11:51:12,968 WARN [] 
ALC-WKS-005-029: A problem occurred in the Submit Service. Please review the submit orchestration for this process.
ALC-WKS-005-029: A problem occurred in the Submit Service. Please review the submit orchestration for this process.
at com.adobe.workspace.AssemblerUtility.createMessageException(
at com.adobe.workspace.tasks.DocumentSubmitServlet.doPost(
at javax.servlet.http.HttpServlet.service(
at javax.servlet.http.HttpServlet.service(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(


 This is due to an incorrect configuration in the submit service settings.


 The submit service for the form variable should have the following configuration:

reference: (181013769/2365358)

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