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: SECJ0305I error in WebSphere log when using an email endpoint


When using an email endpoint in LiveCycle ES2 on WebSphere, you may notice the following error in the server log each time the email endpoint is invoked, or scans for new emails:

00000020 RoleBasedAuth A   SECJ0305I: The role-based authorization check failed for naming-authz operation NameServer:bind_java_object. 
The user UNAUTHENTICATED (unique ID: UNAUTHENTICATED) was not granted any of the following required roles: CosNamingWrite, CosNamingDelete, CosNamingCreate.
00000020 EmailReaderIm E getEmailSourceLock NO_PERMISSION exception caught


This error is repeatedly sent to the server log due to missing permissions for the CORBA naming service groups in WebSphere.

Here is the configuration with the missing privileges:


By making a small change in the WAS admin console you can resolve these errors.  You need to add the privileges for “Cos Naming Write”, “Cos Naming Delete” and “Cos Naming Create” to the CORBA naming service groups.

Open the WebSphere administration console

Goto Environment > Naming > CORBA Naming service groups

Add the following privileges “Cos Naming Write”, “Cos Naming Delete” and “Cos Naming Create”

Restart the WebSphere application server for the changes to take affect

Here is the correct configuration:

reference: (182724546/2998051)

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