Liberty Gen client EJBRMI call to EJB NLS PStep name gives "CORBA BAD

Products

Gen Gen - Run Time Distributed

Issue/Introduction

Gen 8.6 Java EJB server is deployed to a Liberty Application Server server instance.

Gen 8.6 Web Generation client is also deployed to a separate Liberty server instance to the EJB server.

The client is using remote EJBRMI to call the server and so the client commcfg.properties files has:
*=EJBRMI Y fqdn:2809 server_ear_file
(fqdn is the Fully Qualified Domain Name of the Liberty EJB server instance host)

Trying to call an EJB which has a Procedure Step (PStep) name containing NLS characters results in this error:
[Function: EJBRMIDynamicCoopFlow.processException.EJBRMI.Exception]javax.ejb.EJBException: nested exception is: java.rmi.RemoteException: CORBA BAD_OPERATION 0 No; nested exception is: org.omg.CORBA.BAD_OPERATION: : vmcid: 0x0 minor code: 0x0 completed: No

Calling any other EJB server which does not have NLS characters in the Procedure Step (Pstep) name is successful.

Environment

Gen 8.6 plus "Add Support for Liberty Application Server (Phase 2)" PTFs which provide the remote EJBRMI support (Gen 8.6 Solutions & Patches)

Cause

This was found to be due to an issue with IBM's Liberty CORBA implementation, and how NLS characters are handled when present in a corbaname URL.
The problem only occurs when the client is running under a different Liberty instance than the Liberty EJB server instance.

The problem can occur with any type of Gen client application i.e.

Web Generation
Web View
Java Proxy JSP
Java Proxy APP
Java Proxy XML

Resolution

The Gen runtimes have been updated to address "CORBA BAD OPERATION" communication errors between a client and a server.
However, similar CORBA errors may be encountered for these scenarios:

Using JDK 21 with Liberty under Windows and either the client or the server is deployed to separate Liberty instances on Windows.
This is due to the change in Default Charset in JDK 18 and above.
Using any JDK version with Liberty and either the client or the server is deployed to separate Liberty instances on Linux or separate Liberty instances on different OS platforms e.g. Linux and Windows.

In such cases the following solutions have been tested successfully:

Deploy the client application to the same Liberty EJB server instance.
For each Liberty server instance being used.
If the file wlp/usr/servers/<server-name>/jvm.options does not exist (see first Open Liberty doc. link in Additional Information) create it and add this single line or if the file does already exist just add the line:
-Dfile.encoding=iso-8859-1
Also please see NOTE in Additional Information.
Similarly if using a Liberty client to run a Gen Proxy APP application or Gen Proxy XML application.
If the file clients/client_name/client.jvm.options does not exist (see second Open Liberty doc. link in Additional Information) create it with these lines or if the file does already exist just add the lines:
-Djava.awt.headless=false
-Dfile.encoding=iso-8859-1
The first line is only required for running the Gen Proxy APP application and is unrelated to the NLS character problem.
Also please see NOTE in Additional Information.
Do not use the EJBRMI communication type and instead use Web Services.

Additional Information

NOTES:
Initially when the problem was found using JDK 21 on Windows the encoding setting "-Dfile.encoding=COMPAT" was tested successfully.
However it was not successful when tested on Linux.
The Linux server had a locale already set to UTF-8. The COMPAT encoding looks at the OS and locale settings to determine how to set the file.encoding property.
Since the locale was already UTF-8, the file.encoding property continued to be set to UTF-8 even when using the COMPAT encoding. So that is likely why using COMPAT had no effect.

For the suggestion to use a file encoding of iso-8859-1, some users may need to use different values, for example:

Western European customers may need to use encoding iso-8859-15 to pick up the Euro symbol.
Users of Cyrillic characters may need to use encoding iso-8859-5.
Turkish users may need to use encoding iso-8859-9
If only the Windows platform is being used with JDK 21 then the encoding COMPAT can likely be used successfully.

To determine the default charset of the JDK this command can be used:
java -XshowSettings -version

Liberty documentation references:
Open Liberty > Docs overview > Reference > Server configuration
Open Liberty > Docs overview > Reference > Directory locations and properties