Archive for July, 2012

Troubleshooting Common LiveCycle Configuration Errors

- Shishir Pandey, Software Engineer @ Adobe

The following lists the common configuration errors, why they occur, and steps to troubleshoot them.

  • Error: Component: com.adobe.xxx version: 10.0.3.20120511.1.316647 introduced a new service, it should not be patched
    Reason: This issue generally occurs when order of operation in Configuration Manager is incorrect after applying a patch. That is, the deployment of the component is performed before configuring and deploying of the EAR files. It usually occurs in command line execution because each step is run separately in this mode.
    Workaround: Re-run the Configuration Manager and ensure that configuration and deployment of ear is done before deploying components.
  • Error: In case of Weblogic, a “null” folder gets created after deploying EARs.
    Workaround: Stop the managed-server first, followed by the node manager, and finally stop the admin-server. Restart them in reverse order. You will see a folder Adobe gets created in the Weblogic domain.
  • Error: The following error occurred while executing this line: java.lang.OutOfMemoryError: Java heap space
    Reason:  This issue generally occurs if the XMX setting is missing from the server configuration.
    Workaround:  Increase the XMX value for the server or restart the server, and re-run Configuration Manager.
  • Error: weblogic.management.NoAccessRuntimeException: Access not allowed for subject: principals=[], on Resource AdobeService Operation: set , Target: EnableSSL at com.adobe.livecycle.bootstrap.bootstrappers.CoreBootstrapper.bootstrap(CoreBootstrapper.java:60)
    Reason:  This error generally occurs due to missing JMX policies in case of Weblogic during the Initialize LiveCycle step of the Configuration Manager.
    Workaround: Configure JMX as described in Creating JMX policies for database initialization. Restart the server and re-run the Initialize LiveCycle step.
VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 7.0/10 (4 votes cast)

Creating web applications using HTML5/JavaScript Remoting Client SDK with LiveCycle Data Services

- Harpreet Singh, Technical Support @ Adobe

LiveCycle Data Services 4.6 provides a HTML5/JavaScript library that lets you develop client applications that call remoting destinations in Data Services using plain HTML and JavaScript with no Adobe Flash involved.

You can use the JavaScript APIs that do not require compilation against services-config.xml. Remoting only needs destination-to-channel mapping, and the channel information (URL, ID) from services-config.xml. Therefore, instead of compiling against the services-config.xml, you create your own ChannelSet, and assign a component (RemoteObject) before using the component. Alternatively, if your browser supports the HTML5 WebSockets, you can use a WebSocket channel, instead of a RTMP channel in Flash, for real-time communication.

  1. Set up the channel(s).
    var channel = new flex.client.channels.Channel("my-amf","http://localhost:8400/RemotingHtmlLcdsApp/messagebroker/amf");
    var amfChannel = new flex.client.channels.Channel("my-nio-amf","http://localhost:2080/nioamf","flex.client.channels.Channel.HttpMode.REGULAR");
    var wsChannel = new flex.client.channels.Channel("my-nio-amf-websocket","ws://localhost:2080/nioamfwebsocket");
  2. Create a channel set.
    var channelSet = new flex.client.channels.ChannelSet([ channel,amfChannel ]);
  3. Create and initialize a RemoteObject with channelSet and destinationId.
    var remoteObject = new flex.client.rpc.remoting.RemoteObject("EchoService");
    remoteObject.setChannelSet(channelSet);
  4. Add the result and fault handlers for the remoteObject.
    remoteObject.addEventListener(flex.client.rpc.events.ResultEvent.RESULT, function(resultEvent) {
    result = resultEvent.getResult();
    alert(result);
    });
    remoteObject.addEventListener(flex.client.rpc.events.FaultEvent.FAULT, function(faultEvent) {
    var fault = faultEvent.getFaultString();
    alert(fault);
    });
  5. Make the remoting call and call the disconnect on remoteObject.
    remoteObject.invoke("echo");
    remoteObject.disconnect();

Download the sample code from here. Access the JavaScript reference here.

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

Platform Combinations Supported by LiveCycle

Siddharth Jain, Quality Engineering Manager @ Adobe

Adobe  LiveCycle deployment involves many third-party software like Application Servers, Databases and Operating Systems. LiveCycle team certifies certain platform combinations for each release of LiveCycle. For example, the supported platform combinations for our latest LiveCycle ES3 SP1 offering can be looked at http://help.adobe.com/en_US/livecycle/10.0/supported_platforms.html. It provides details of third-party software along with the version details on which LiveCycle is certified and supported. Given that these third party software keep coming up with their latest offerings too, LiveCycle has a third party software patch support statement available at http://helpx.adobe.com/livecycle/kb/livecycle-third-party-software-patch.html.

Together, these two documents should help you figure out whether platform of your choice is supported by LiveCycle or not. In case, you need any clarification, contact Adobe Enterprise Support for guidance.

If you find that platform of your choice is not supported by LiveCycle, for example, you wish support for version X of a database vendor due to your project considerations while LiveCycle supports version Y, you should contact Adobe Enterprise Support who can guide you on next steps.

In addition, Adobe LiveCycle team has a process known as Customer Commit Request in which such a request can be routed to engineering for evaluation if the customer has committed to using LiveCycle by means of purchase or M&S. If engineering finds that there is feasibility to support such a platform for your identified use, it carries out testing on that platform for your use case on LiveCycle version you intend to use. If all goes well, LiveCycle team reverts back in positive and provides support to you for your specific requirement on your desired platform for that LiveCycle release.

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

Debugging LiveCycle – Working with logs (Part-1)

Ankush Kumar, Lead Software Engineer @ Adobe

Logs are the first thing that come to the mind when we run into an issue. Following are some tips on improving the logging on the application side as well as the application server side.

Enabling/Modifying Logging of Application Servers


JBoss

Jboss, which is bundled with LiveCycle has a pre-configured log4j configuration file. It is present as <Appserver Home>/server/<profile>/conf/jboss-log4j.xml. you can track new packages or existing packages at debug level by simply using the following command:

<category name=”com.adobe.mypackage”>

<priority value=”DEBUG”/>

</category>

From here, you can do the following configurations:

  • Change log file path
  • Change log entry structure
  • Specifying log rotation policy
  • Enable cluster logging

The following JBoss wiki can help you play around the logging file.

https://community.jboss.org/wiki/Logging


Weblogic

Weblogic logging can be configured from Weblogic administration console. There are separate administration consoles for each managed server. On Weblogic administration console, logging can be accessed at Environment > Servers > [Name of Managed Server or Admin Server] > Logging.

Here, you can define following configurations

  • Log file path
  • Rotation Policy

However, in the advanced section, you can define:

  • Log entry layout
  • Logging Level
  • Specify package level logging in “Logger Severity Properties” box:
    com.adobe.mypackage=Debug

Note that on Weblogic, if you are running into issues while deploying EARs, you may want to look into Domain logs and Adminserver logs. Both of these are created under <Weblogic Domain>/servers/<Admin Server>/logs.


Websphere

Websphere logs can be found at <Websphere Home>/AppServer/profiles/<Profile Name>/logs/<server name>. You can configure it from Websphere administration console at Websphere Application Servers > [name of server] > Logging and Tracing.

In JVM Logs, you can configure SystemOut and SystemErr logs for your server.

Here, you can configure:

  • Location of Log file
  • Rotation Policy

From Logging and Tracing, with few simple steps, you can enable the trace level logging for a specific package:

  1. Select “Change Log Detail Levels” from General Properties section.
  2. Under “Change Log Detail Levels” page, you can find a text box and tree beneath it with root node as “* [All Components] “.
  3. Expand Root node “* [All Components] > com.adobe.livecycle.*” and click “com.adobe.mypackage.*”.
  4. This will open a context menu. Go to Message and Trace Levels and choose finest from sub menu.
  5. Click Apply button and Save the settings to master configuration. Now you should be back to “Logging and tracing”.
  6. Select Diagnostic Trace link. This will open Diagnostic Trace Service page.
  7. Make sure File radio button is selected. Increase the Maximum File Size to 50 MB, and Maximum Number of Historical Files to 5.
  8. File Name text box shows “${SERVER_LOG_ROOT}/trace.log” by default. This means trace logs are getting created at default logs folder. You can change it by giving any absolute path where you want diagnostic logs to be written.
  9. Click Apply and Save the settings to master configuration.
  10. Restart the server. File specified at step 8 should get created.
VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 6.6/10 (7 votes cast)