Known issues and limitations

Known issues and limitations exist in a WebSphere® Application Server Network Deployment cell that includes IBM® Modernized Runtime Extension for Java™ (MoRE) .

Installation

The following information discusses known issues and limitations when you install WebSphere Liberty and Java.

Liberty and Java SE 17 can be installed with Installation Manager only.
Java SE 21 can be installed with Installation Manager only.
Only one installation of Liberty is allowed on a system with MoRE.
Only one installation of Java SE 17 is allowed on a system with MoRE.
Only one installation of Java SE 21 is allowed on a system with MoRE.

Administrative console

The following known issues and limitations are for the administrative console in WebSphere Application Server Network Deployment.

No administrative console page exists for managing Liberty installations on a node. The only way to manage Liberty installations on nodes is to use administrative tasks.
When a user adds new members to an existing managed Liberty cluster through the administrative console, the server versions that are shown in the wizard are incorrect.
Managed Liberty clusters are not listed in the cell topology. To access the cell topology, click System administration > Cell > Local Topology.
If a node has multiple Liberty installations, the Version, Location, and Bits columns in the Java SDK pages for both servers and nodes are blank for Java 17 and Java 21. This condition is also true if a node had multiple Liberty installations at any point in the past. Users can still retrieve this information by using wsadmin commands. You can correct this bug in the Admin Console for version 9.0.5.25 nodes; first, uninstall all versions of Liberty from the node, then install a single version of Liberty.
Applications on a managed Liberty server do not have the application edition function. These applications are not displayed on the Edition control center when MoRE is installed.
A null error might occur at the end of the creation wizard. If such an error happens, look at step 4 of the creation wizard. A null error can occur if a value is set for the Container-managed authentication alias setting for a JDBC provider or a JDBC data source.
You can do one of the following workarounds:
- Use the AdminTask command.
- Create a data source without providing a value for the setting, and save the data source. Then, provide a value for the Container-managed authentication alias setting and save the data source.
To resolve this limitation, delete and re-create any servers that were created in version 9.0.5.24 or earlier.
The Isolate this resource provider checkbox on the JDBC provider > Specific provider page applies only to WebSphere Application Server traditional servers. For managed Liberty servers, the JDBC provider is isolated by default and cannot be set to nonisolated.
When you add a bus member to a bus, the administrative pages display a menu for you to select a server to add. This list includes managed Liberty servers, which can be selected. However, they are not valid as members of a service integration bus. If a managed Liberty server is selected, it looks like it is added to the bus, but no messaging engine is available, and the server does not participate on the bus.
The Edition Control Center page in the Applications navigation section is intended for WebSphere Application Server Network Deployment traditional only applications currently. However, with MoRE installed on the deployment manager, managed Liberty server applications are also being displayed on the page when they are supposed to be.
In the current version, the Runtime operations > Applications page does not display the accurate status of applications that are installed on managed Liberty servers. Status information is sourced from ODC, which has limited support for retrieving managed Liberty server application statuses. The deployment manager cache also fails to reflect the actual application state reliably. As a result, users might see incorrect or outdated application statuses in the page.
In the current version, the Application details view in the All Applications page does not display accurate information for Liberty applications. To access the details of a Liberty application, click Applications > Application types > WebSphere Enterprise Applications, then click an application link.
If you want to create a first cluster member, you must first save and synchronize the server. This requirement applies whether you use an existing managed Liberty server as a server template, or convert an existing managed Liberty server. Otherwise, when you attempt to create the cluster member, the following error message is displayed:
```
Errors occurred during creation of the cluster members: ADMG9212E: Exception caught executing createClusterMember command: 
com.ibm.websphere.management.cmdframework.CommandValidationException: ADMG9254E: The type of server, MANAGED_LIBERTY_SERVER, 
is not appropriate for the specified cluster type, APPLICATION_SERVER.
```
On the Servers > Clusters > WebSphere Application Server clusters page, the ImmediateStop button in the cluster collection table is disabled when a managed Liberty server cluster is selected.
When you use the administrative console, you can create a managed Liberty server by using the All servers or WebSphere application servers pages.
- Servers > All servers
- Servers > Server Types > WebSphere application servers
You can also create managed Liberty servers as cluster members during cluster creation. To do so, do one of the following steps.
- Under Create the member using an application server template, choose the default-managed-liberty-server template.
- In step 2 of the cluster wizard, under Create the member using an existing application server as a template, select an existing managed Liberty server.
You cannot start or stop applications that are installed on a managed Liberty server by clicking Start and Stop on the Enterprise applications page. The following error displays, regardless of the actual state of the application. To start the application, start the server. Applications are started when the managed Liberty server starts and remain running until the managed Liberty server is stopped.
```
Server server_name on node node_name that contains application_name has not been started.
```
The state of a managed Liberty server appears to be Not started when the actual status is Started.
Heap dumps cannot be generated for managed Liberty servers through the console. To generate a heap dump, use SSH to access the WebSphere Application Server Network Deployment instance. In the command line tool, run the following commands.
```
$ cd <WLP-INSTALL-DIR>/bin
$ export WLP_USER_DIR=<PROFILE-ROOT>/config/cells/<cellName>/nodes/<nodeName>/managedLiberty/usr
$ ./server javadump <SERVER-NAME> --include=heap
```
EJB, CORBA, and Indirect namespace binding types are not configurable on the Specify binding type settings page when the scope contains only managed Liberty servers.
To view the Specify binding type settings page, click Environment > Naming > Name space binding, select a scope from the Scope list, and then click New. The selected scope can be a cell, a node, or a single server.

The EJB, CORBA, and Indirect options are disabled when the selected scope contains managed Liberty servers only.
Warning: The options are not disabled, a known limitation, if both of the following situations occur.
- The managed Liberty server is not saved or synchronized before you try to create a namespace binding.
- The selected scope lists only managed Liberty servers.
The terminate option is available for both the managed Liberty server type and the web server type on the All servers page. Neither is supposed to be available.
The Runtime operations deployment target and Runtime operations applications pages are not supported for managed Liberty servers.
The Dynamically update the run time when SSL Configuration changes occur checkbox has no effect on managed Liberty servers.
Starting in 9.0.5.24, a message is displayed in the administrative console that states this limitation.
In the Java Dumps and Cores page of the administrative console, the generation of Java cores and system dumps is not supported for managed Liberty servers.

WebSphere Application Server Network Deployment configuration

The following known issues and limitations are for Liberty configuration.

The limitation is for the xmlBinding-4.0 feature.
- The xmlBinding-4.0 tools are provided with a Liberty installation, but not with MoRE and WebSphere Application Server traditional. If you need the xjc or schemagen tools, you can find them in the Liberty installation.
- The xmlBinding-4.0 feature does not support the WebSphere Application Server traditional JAXB implementation, XLXP. However, you can use alternative Jakarta EE 10 implementations with the jakarta.xml.bind.ContextFactory JVM property.
For the Jakarta Persistence 3.1 feature, persistence-3.1, the following limitations apply.
- Only the built-in provider, EclipseLink, is supported.
- Configuring the defaultPersistenceProvider attribute of the jpaService class is not supported. EclipseLink is the default provider.
- The following AdminTasks commands are not applicable to managed Liberty servers:
  - listSupportedJPASpecifications
  - showJPASpecLevel
  - modifyJPASpecLevel
- For the AdminTask listSupportedJPASpecifications command, the returned list includes only the JPA versions applicable to WebSphere Application Server traditional servers.
- For the AdminTask showJPASpecLevel and modifyJPASpecLevel, the following error occurs if a managed Liberty server is targeted:
```
CWWJP8818E: This command is not supported for ManagedLibertyServer components.
```
- An administrative console page is not provided to configure the defaultJtaDataSourceJndiName and defaultNonJtaDataSourceJndiName attributes of jpaService service class. You can configure these attributes with only the wsadmin command, as shown in the following example.
```
wsadmin>mls = AdminConfig.getid('/Node:<node>/Server:<server>')
wsadmin>liberty = AdminConfig.list('ServerComponent', mls)
wsadmin>AdminConfig.create('JavaPersistenceAPIService', liberty, [['defaultJTADataSourceJNDIName', 'jdbc/built-in-derby-datasource'],['defaultNonJTADataSourceJNDIName', 'jdbc/non-jta-derby-datasource']])
wsadmin>AdminConfig.save()
```
The limitation is for the messagingClient-3.0 feature. Administered objects for the default messaging provider can be defined for use in a managed Liberty server. Because MoRE does not support the messagingServer feature, these objects can be configured to connect only to a system integration bus that is hosted in WebSphere Application Server Network Deployment traditional. When you define objects in a managed Liberty server, the following restrictions apply.
- When you define ConnectionFactory objects for the default messaging provider, some properties can be specified but are not set in the object in a managed Liberty server. The following properties are not mapped:
  - Log missing transaction contexts
  - Manage cached handles
  - Share data source with CMP
  - Authentication alias for XA recovery
  - Mapping-configuration alias
- When you define messaging-administered objects for use in a managed Liberty server, define them at server scope so that the definitions apply to only the server type.
When a client is connecting to a system integration bus from a managed Liberty server, the connecting client cannot be redirected automatically from a bootstrap server. So, the provider endpoints that are defined in the ConnectionFactory must include all hosts on which the targeted messaging engine can run. The connecting Liberty client attempts to connect to each endpoint in turn until a successful connection is made. If one or more endpoint is incorrectly configured, then the entire connection attempt might fail.
For the managedBeans-2.0 feature, when you install an application with a @Managed Bean annotation with an @Resource injection annotation in a stand-alone WAR module, an unexpected attribute might be added. WebSphere Application Server Network Deployment traditional adds an unexpected name attribute in the ibm-managed-bean-bnd.xml file when the target is a managed Liberty server.
You can add the extra name attribute in the following scenarios:
- The ibm-managed-bean-bnd.xml file contains an empty managed-bean element, which has no bindings.
- The ibm-managed-bean-bnd.xml file contains a managed-bean element that does not correspond to a managed bean.
- The application contains a web.xml file with a schema version that is less than 5.0.
The extra name attribute causes the application to fail to start with the following error:
```
CWWKC2256E: Unexpected attribute name 
encountered parsing element managed-bean in the 
xxxxx.ear : yyyy.war : 
WEB-INF/ibm-managed-bean-bnd.xml deployment 
descriptor on line 4.
```
You might be able to resolve the error by either removing the problematic element, since the element is providing no value, or upgrading the schema for the web.xml to version 5.0 or later.
Modifying or displaying the following providers for managed Liberty servers with wsadmin scripting or the administrative console is unsupported.
- JavaServer Faces (JSF) providers
- Java Persistence API (JPA) providers
- Java API for RESTful Web Service (JAX-RS) providers
Liberty does not support the Mail 2.1 MailProvider configuration. Only MailSessions configured with the built-in provider are migrated to managed Liberty servers.
If the MailSession has the same password set on both the store and transport configuration, the MailSession configuration is not supported on managed Liberty servers.

Liberty configuration migration

The following known issues and limitations are for Liberty configuration migration.

A managed Liberty server cannot be created if the server name has spaces in it.

The following limitation is for mail.

The mail-2.1 function in WebSphere Application Server Migration Toolkit currently does not map the Debug field from the mailSession.

The following limitations are for ports.

Only the HTTP endpoint that the WC_defaulthost and WC_defaulthost_secure ports define can be migrated.
When you migrate transport channel configuration settings for ports, note the following limitations:
- Only the TCP inbound channel for the WC_defaulthost_secure port is migrated. A new warning message is logged if the TCP inbound channel for the WC_defaulthost_secure port does not match the TCP inbound channel for the WC_defaulthost port.
- The TheadPool property is not migrated.

The following limitations are for virtual hosts.

Virtual hosts cannot be migrated when they limit access to certain hosts or ports.
If information is removed from the default virtual host so that the default virtual host can be added to another host, aliases cannot overlap.

The following limitation is for URL providers that represent electronically accessible resources.

Managed Liberty servers do not support custom URL providers. When an application runs on a managed Liberty server, the default URL provider must bind its URLs for them to be looked up through JNDI.

The following custom properties are ignored when you migrate data source properties.

category
clientRerouteServerListJNDIName cloudscapeOldClasspath
connRetryIntervalDuringDBFailover
connectValidConnections disableBackendIdChecking
disableEndToEndClientMonitoringFeature
disableEndToEndMonitoringFeature
disableWASConnectionPooling enableClientInformation
enableHeterogeneousPooling
enableMultithreadedAccessDetection
enable2Phase
enableSQLJ fireCEEventOnSCE
informixAllowNewLine
jndiContextName
oracle9iLogTraceLevel
oracleLogFormat
oracleLogFileName
oracleLogFileSizeLimit
oracleLogPackageName
preTestSQLString
propagateClientIdentityUsingTrustedContext
resetConnectionByBackendDatabase
removeExistingOracleConnectionPoolIfExists
skipCheckForUnprocessedResults
socketIntervalTime socketProbeCount
supportsDynamicUpdates
validateAfterConnectionError
validateNewConnection
validateNewConnectionRetryCount
validateNewConnectionRetryInterval
validateNewConnectionTimeout useRRASetEquals
useTrustedContextWithAuthentication
unbindClientRerouteListFromJndi
cloudscapeOldDatabaseName
dbFailOverEnabled disableEndToEndMonitoringFeature
enableEndToEndClientMonitoringFeature
enableSQLJ fireCEEventOnSCE
informixAllowNewLine
jndiContextName
oracle9iLogTraceLevel
oracleLogFormat
oracleLogFileName
oracleLogFileSizeLimit
oracleLogPackageName
preTestSQLString propagateClientIdentityUsingTrustedContext
resetConnectionByBackendDatabase
removeExistingOracleConnectionPoolIfExists
skipCheckForUnprocessedResults socketIntervalTime
socketProbeCount supportsDynamicUpdates
validateAfterConnectionError
validateNewConnection
validateNewConnectionRetryCount
validateNewConnectionRetryInterval
validateNewConnectionTimeout
useRRASetEquals
useTrustedContextWithAuthentication
unbindClientRerouteListFromJnd

The following limitation is for trace logging.

The value of the traceFileName parameter must be a valid file name to be used by the binary scanner. An absolute file path cannot be specified for this parameter.

The following limitation is for the transaction manager.

The throwCheckedExceptions attribute cannot be migrated.

Application scanning and deployment

The following known issues and limitations are for application scanning and deployment.

Stand-alone web modules that are installed to managed Liberty targets do not expand on the file system. As a result, stand-alone web applications can read but cannot write to resources provided by the web modules.

Liberty servers and clusters

The following known issues and limitations are for Liberty servers and clusters.

All managed Liberty servers must be stopped before the configured Liberty installation can be switched. The setConfiguredManagedLibertyInstallationSecurity command does not verify that all managed Liberty servers are stopped.
After you migrate a node to version 9.0.5.26, start the node agent at least one time before you install a new Liberty installation. This action ensures that existing managed Liberty servers initially continue to use the existing Liberty installation. You can then use the setConfiguredManagedLibertyInstallationSecurity administrative task to control which Liberty installation is used.
The installation section is updated to state that Java 21 is an alternative or additional Java SDK to Java 17.
After you migrate a node to version 9.0.5.25 from either 9.0.5.23 or 9.05.24, start the node agent at least one time before you install Java 21. This action helps ensure that existing managed Liberty servers initially continue to use Java 17 after Java 21 is installed. Use the Admin Console or the setNodeDefaultSDK and setServerSDK admin tasks to control which version of Java a managed Liberty server uses.
The managesdk command line tool is limited to working with the WebSphere Application Server traditional Java 8 SDK.
The admin task setServerSDK -clusterName requires the Java SDK name or location to be uniform across the nodes of a cluster. If some nodes are nonuniform, the Java SDK selection can still be set individually.
When the MLS_JAVA_HOME variable is not defined or set and you issue the getUnusedSDKsOnNode('[-nodeName <nodeName>]') command, it fails with a com.ibm.wsspi.runtime.variable.UndefinedVariableException: Undefined variable MLS_JAVA_HOME exception.
Running the AdminTask.getSDKPropertiesOnNode command for a version 9.0.5.23 or 9.0.5.24 node using the sdkAttributes option always gives version and location attributes. For example, running the AdminTask.getSDKPropertiesOnNode(‘[-nodeName <nodeName> -sdkAttributes [[bits version]]') command returns the following output:
```
[[com.ibm.websphere.libertyJavaVersion 17] [com.ibm.websphere.liberty.JavaLocation /opt/liberty/wlp/java/17.0]]
```
After you start or stop a cluster, the cluster status might be incorrect even though the status of each of the individual members is correct.
When a node has members from multiple managed Liberty server clusters on it, the managed Liberty server configuration for the members might not be updated. To work around this issue, create a temporary node level WebSphere variable with any name and value and then save and synchronize the node. The workaround forces the regeneration of the configuration for all managed Liberty servers on the node. Alternatively, you can create a server level variable to limit the configuration regeneration to an individual managed Liberty server.
Applications in managed Liberty servers cannot be stopped and started when the managed Liberty server is running. Applications are started when the managed Liberty server starts and remain running until the managed Liberty server is stopped.
The Terminate, Submit Action, and Set mode buttons, plus the Maintenance mode status on the Middleware servers administrative console page are not available for managed Liberty servers.
Dynamic clusters are not supported for managed Liberty servers.
Static clusters for managed Liberty servers do not support the following capabilities:
- Authentication cache
- Back up clusters
- Logged out cookie cache
- Session replication
- Transaction log recovery
- Workload management
Routing by using the proxy server is not supported for managed Liberty servers.
Routing by using the on-demand router (ODR) is not supported for managed Liberty servers.
Routing by using the ODRLIB plug-in is not supported for managed Liberty servers.
Targeting managed Liberty servers from WebSphere Application Server Developer Tools for Eclipse is not supported.
Use of the high-availability manager (HAM) is not supported for managed Liberty servers.
Use of the logged-out cookie cache for session replication is not supported for managed Liberty servers.
Use of user-defined features is not supported for managed Liberty servers.

Application class loading and shared libraries

The following known issues and limitations apply to application class loading and shared libraries:

Application Class reloading settings are not supported.
Class loader settings are configurable only for an application, not for embedded web modules.
- The Class loader order setting, also known as class loader delegation in a managed Liberty server, defaults to parent-first and applies to all class loaders that support the application. For enterprise applications deployed as an EAR, the setting applies to the parent application EAR class loader. The setting also applies to all child WAR class loaders for embedded web modules. Class loader delegation is not configurable by using the administrative console, but can be configured by using administrative scripts.
- When you choose a class loader order, the parent-last order might not be the best choice for applications that are deployed to a managed Liberty server. Parent-last order is used to isolate application packages from packages made visible by the application server. Liberty class loaders restrict visibility to API packages that support Liberty features, with few exceptions.

The association (mapping) of a shared library to an application is called a library reference.

Shared libraries can be associated (mapped) to applications only. For enterprise applications deployed as an EAR, shared library references can be configured for the application EAR, but not for web modules (WARs) embedded in the EAR.
Shared library references are common or private according to the Isolated class loader setting of the referenced library. Common shared libraries support isolated class loading; private shared libraries do not.
The API type visibility class loader and shared library settings are not configurable. Applications and shared libraries cannot use managed Liberty server third-party API.
Shared libraries within the same scope must have unique names.

Applications

The following known issues and limitations apply to applications.

All modules in an application must be mapped to the same managed Liberty target. The target can be either a managed Liberty server or a managed Liberty cluster, and optionally to one web server.
Deployment is not supported for Jakarta EE 10 applications that use Java administrative programs that themselves use JMX APIs.
For Jakarta EE10 applications, installation of enterprise modules with JSR88 and customized modules is unsupported.
Adding a Jakarta EE 10 asset to a business-level application (BLA) to create a composite unit is unsupported. Modifying the BLA of the Jakarta EE 10 application directly, either by using the admin console or the AdminTasks, is not supported.
BLAs for managed Liberty server applications are no longer listed in the admin console under Applications > Application Types > Business-level applications.

Liberty features

The following known issues and limitations are for Liberty features.

For the Jakarta JSON Binding 3.0 feature, only the built-in JSONB provider is supported.
For the Jakarta JSON Processing 2.1 feature, only the built-in JSONP provider is supported.

WebServer plug-in

The following known issues and limitations are for the WebServer plug-in.

If a managed Liberty server is not in a cluster, do not specify the httpSessionCloneId session custom property for the managed Liberty server.

Default JMS provider

The following known issues and limitations are for the default JMS provider.

Administered objects for the default messaging provider can be defined in a managed Liberty server, either through the administrative console or through wsadmin commands. When you create ConnectionFactory objects, some properties can be specified but are not set in the object in a managed Liberty server. The following properties and commands are not mapped:

The administrative console properties

Log missing transaction contexts
Manage cached handles
Share data source with CMP
Authentication alias for XA recovery
Mapping-configuration alias

The wsadmin commands

logMissingTransactionContext
manageCachedHandles
shareDataSourceWithCMP
xaRecoveryAuthAlias

Liberty logging

The following limitation is for Liberty logging.

When WTP trace is enabled with a trace specification of com.ibm.config.eclipse.wtp=finer, trace output from the ArchiveTypeDiscriminatorImpl class and the openSpecificArchive method is written to the system output log file.

The output is produced during normal, nonfailing, operations when WTP trace is enabled. So, no error is produced. However, the output is not intended.

The following example is of the output.

[2/26/25 8:54:10:066 PST] 00000078 wtp           C org.eclipse.jst.j2ee.commonarchivecore.internal.helpers.ArchiveTypeDiscriminatorImpl openSpecificArchive Archive [ WSBankEJB_HTTPRouter.war ] characteristics:

Archive                               [ com.ibm.etools.commonarchive.impl.WARFileImpl@328224e1 ]
    Archive URI                       [ WSBankEJB_HTTPRouter.war ]
        isOpen                        [ true ]
        Absolute Path                 [ /opt/ibm/WAS/profiles/node4/config/cells/ndcell/applications/GarageSaleLibertyEAR_JEE7_JDK8_v90_4Q2022_10132022.ear/deployments/GarageSaleLibertyEAR_JEE7_JDK8_v90_4Q2022_10132022/WSBankEJB_HTTPRouter.war ]
        Binaries Path                 [ /opt/ibm/WAS/profiles/node4/installedApps/ndcell/GarageSaleLibertyEAR_JEE7_JDK8_v90_4Q2022_10132022.ear/WSBankEJB_HTTPRouter.war ]
        Resources Path                [ /opt/ibm/WAS/profiles/node4/config/cells/ndcell/applications/GarageSaleLibertyEAR_JEE7_JDK8_v90_4Q2022_10132022.ear/deployments/GarageSaleLibertyEAR_JEE7_JDK8_v90_4Q2022_10132022/WSBankEJB_HTTPRouter.war ]
        Archive Options               [ org.eclipse.jst.j2ee.commonarchivecore.internal.helpers.ArchiveOptions@7d9262f6 ]
            EAR ParentEarBinariesPath [ /opt/ibm/WAS/profiles/node4/installedApps/ndcell/GarageSaleLibertyEAR_JEE7_JDK8_v90_4Q2022_10132022.ear ]
            EAR AltBinariesPath       [ /opt/ibm/WAS/profiles/node4/installedApps/ndcell/GarageSaleLibertyEAR_JEE7_JDK8_v90_4Q2022_10132022.ear ]
            Use Java Reflection       [ false ]
        Manifest                      [ org.eclipse.jst.j2ee.commonarchivecore.internal.helpers.ArchiveManifestImpl@f6c539e3 ]
            Manifest classpath        [  ]
        Load Strategy                 [ org.eclipse.jst.j2ee.commonarchivecore.internal.strategy.DirectoryArchiveLoadStrategyImpl@84e57640 ]
    ArchiveImpl                       [ @(#) 1.30 WCCMBASE/ws/code/jst.j2ee.core.archive/src/org/eclipse/jst/j2ee/commonarchivecore/internal/impl/CommonarchiveFactoryImpl.java, WAS.prereq.ies, WASX.WCCMBASE, qq0934.23 8/17/09 07:28:11 [8/28/09 13:02:29] ]