Archive for June, 2012

Restarting CRX Server without stopping a JBoss Server Instance

Since the release of ES3, the CRX Server comes integrated with the LiveCycle Document Services.(NOTE: SA Installer should be run on an existing LiveCycle Document Services Installation in order to get the benefits of CRX Server and Correspondence Management Solution)

The CRX wars namely, crx-explorer_crx.war and crx-launchpad.war are bundled inside the core EAR, i.e. adobe-livecycle-jboss.ear.

There are times when a restart of the CRX Server is required due to some changes in configuration/settings or issues related to bundle activation.
Since the wars are bundled inside the core ear, the whole of JBoss server instance needs to be restarted to get things done.
This ultimately consumes time and things on the doc-services side also get blocked due to some task pending at CRX end.

Let’s handle the two issues separately,

i. Issues related to Bundle Activation

There is an easy way out where one can just shutdown the CRX server and Restart it again without interfering with the LiveCycle Server Instance.

Go to, http://localhost:8080/lc/system/console/vmstat (Snapshot at the end of the post)
It has two buttons,
a. Restart – Clicking on this will restart all the bundles and the framework.
b. Stop – Clicking on this will stop all the bundles and the framework.
In order to start the framework and the bundles, Just refresh the browser or hit the above mentioned URL again.
The LiveCycle services running under the Jboss server instance won’t be affected at all.

The above settings solves the issue of Bundle Activation because it restarts CRX LaunchPad. But it doesn’t start the whole of CRX due to which changes in repository.xml or don’t get reflected.

ii. Changes in Configuration/Settings like repository.xml,, etc.

For such changes to get reflected, the best way is to re-deploy the CRX war.
JBoss provides a seamless way of doing that through JMX Console.
a. Go to http://localhost:8080/jmx-console. (For more information on JMX-Console handling I’ll write a separate blog post)
b . Once inside JMX-Console, search for jboss.web.deployment section.
c. Click on the link named war=/crx.
d. Now you can stop and start the war by clicking on the respective “Invoke” buttons to get the settings and configuration reflected. This won’t affect the other LiveCycle Document Services running in parallel.

Bookmark and Share

Customizing ports on Jboss for running multiple server instances

Many a times we need to run multiple JBoss server instances on the same sever, e.g. Vertical Cluster setups. At times when some other application has taken control of port 8080, then need arises to switch JBoss server instance to run on some other port.

Below mentioned are the ways one can follow to configure different ports on multiple JBoss server instances without going for changing 10s of ports which is firstly time consuming and also hard to maintain.

Jboss 4.x.x

JBoss by default uses 8080 for Http connection and 8443 for SSL connection.

So, in case one needs to switch port 8080 and it’s set of related ports of a server instance to something else, then Jboss provides another set of 3 pre-configured ports to choose from, i.e. 8180, 8280, 8380.

To change the default port settings,
a. Go to \\Livecycle_Installation\JBoss\server\Server_Instance_Name\conf\jboss-service.xml
b. Look for the following mbean instance:

<mbean code=”” name=”jboss.system:service=ServiceBindingManager”>
<attribute name=”ServerName”>ports-01</attribute>
<attribute name=”StoreURL”>${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml</attribute>
<attribute name=”StoreFactoryClassName”></attribute>

c. The above mentioned mbean code, is commented by default to allow users to use 8080.
Uncomment the above said mbean code and the server instance will be ready to run on ports-01, which is 8180.
This also take care of the other related ports and increment their value with 100, i.e. SSL port related to ports-01 will be 8543.

If one wants to use any other port. Just change the value for the attribute “ServerName” to ports-02(8280) or ports-03(8380). These are pre-configured ports by JBoss.
For any new custom port other than the ones talked above, one will have to add new configurations to the file, specified in the path given for the attribute “StoreURL”.

For more information please refer the following doc,

Jboss 5.x.x

JBoss 5 also comes with a set of 4 predefined ports, 8080, 8180, 8280 and 8380.
By default, any server instance is bind to run with 8080(for http) and 8443(for https).

But in order to run with the other ports mentioned above, one can start the server with the following command,

run -c server_instance_name -Djboss.service.binding.set=ports-01

The above command will start the JBoss server instance with port 8180.
The related port values will as well get incremented with 100.

If one wants to configure a custom port other than the ones mentioned, then one’ll have to edit the pre-configured bindings(or add new) in following file,

For more information please refer the following doc,

Bookmark and Share

BeanShell scripting via LiveCycle Workbench

Adobe Livecycle Workbench provides a great tool for executing BeanShell scripts.

BeanShells sripts allow executing a piece of code on the fly. The best part of BeanShell scripting is that it doesn’t have unnecessary syntactic sugar which complicates and increases the learning curve. Rather one can simply use his/her java skills and write down the code and run it on the fly on a LiveCycle running server.

This mostly comes handy when one wants to execute a code quickly on the server but wants to avoid creating a project in an IDE and going through all the hassles of collecting the dependent jars in class-path and thereafter instantiating ServiceClientFactory and providing server details to connect.

Since the script gets executes within VM, hence it doesn’t require the pre-requisites such as providing the dependent jars or server detail configurations.

The following example demonstrates a simple “Hello World” code written in BeanShell script and executed on the LiveCycle server.

I’ve written a cookbook recipe for invoking various User Manager APIs through BeanShell scripting which one can find at,

1. Connect the Workbench to a running LiveCycle server.

2. Create a new Application. Specify the name of the Application and click on Finish button.

3. Create a New Process under the Application.

4. Mention the Process name and click on Finish button.

5. A Process SwimLane will be opened on the right side. Drag the Activity Picker and attach it to the “Default Start Point”.

6. Once done, a “Define Activity” pod comes up. Enter the Activity name and search for “execute script” in the Find box.

Else, the Execute Script activity can also be found by navigating to “Foundation->Execute Script 1.0” under Service tab.

Click OK.

7. Once done there will be a new window opened on the left side with the name “executeService Operation”. Click on the button in the Input box.

This will open up a Text Area where the code to be executed can be written.

8. Enter the code with proper imports and click on OK button. Then click the Save button on the top left corner or press CTRL+S.

9. Goto the Applications tab in the left top corner. Right click on the relevant process and click on “Invoke”.

Click OK on the screen where it asks “Check in all files”. Click OK on the next screen where it notifies of “No Input Variables”.

10. Look into the server logs of the application server on which LiveCycle server is running. The output will be printed in the INFO level logs.

The above was a simple example to show the working of BeanShell script in LiveCycle through Workbench.

But in Enterprise world the script would be interacting with inputs from different processes and returning processed results to further joining processes.This can be achieved through patExecContext object which is explicitly available to the script.

An example can be found at,

Bookmark and Share