WAS v8.5 > Reference > Troubleshooting tips > Troubleshooting the Liberty profile

Liberty profile: Runtime environment known restrictions

There are few known restrictions that apply when working with the Liberty profile runtime environment.

See also Liberty profile: Developer Tools known restrictions.

List of known issues and restrictions:

• General restrictions:
  • Minimum supported Java levels
  • The installation directory name and path cannot include non-ASCII characters
  • Change the JDBC data source at run time might result in JPA failures
  • Modifying the dataSource, jdbcDriver, connectionManager, and JDBC vendor properties at run time might result in JPA failures
  • An application that relies on a result being returned by getRealPath must be deployed as an expanded application, not as a WAR file
  • WAS full profile scripts do not work with the Liberty profile
  • Fileset restrictions
  • When you unpublish a shared library, it cannot be deleted until the server is stopped

• Restrictions specific to Liberty features:
  • beanvalidation-1.0 feature restrictions
  • jaxrs-1.1 feature restriction
  • jpa-2.0 feature restrictions
  • jsf-2.0 feature restrictions
  • jsp-2.2 feature restrictions

Minimum supported Java levels

Minimum supported level for the JDK from Oracle is Java™ 6 update 26. For the Java SDK from IBM , the minimum supported level is 6.0 (J9 2.6) SR 1.

On distributed platforms, 32-bit or 64-bit Java is supported.

For Windows and Linux systems, we can use either the JDK from Oracle or the JDK from IBM. If we are developing applications on Windows or Linux, and you plan to deploy those applications to a server running on the WAS full profile, you should use the JDK from IBM. For HP systems and Mac OS, use the JDK from Oracle.

The JDK from IBM is available in many IBM products. For example, WAS v7 includes the Java 6 JDK from IBM.

The installation directory name and path cannot include non-ASCII characters

Recent JVMs do not fully support use of non-ASCII characters with the -jar and -javaagent commands. You should use only ASCII characters in your install directory names and paths.

Change the JDBC data source at run time might result in JPA failures

If not specified through properties, OpenJPA detects and calculates the database dictionary type when the first entity manager is created and the database connection is made. This database dictionary type is used for all entity managers that are subsequently created. If the JDBC data source is changed while an application is running, the entity manager factory does not detect this change and continues to use the old dictionary for operations against the new data source. This can result in failures if the database is changed to a different vendor.

When you change a database to a different vendor, restart the application.

Modifying the dataSource, jdbcDriver, connectionManager, and JDBC vendor properties at run time might result in JPA failures

If we update the configuration of dataSource, jdbcDriver, connectionManager or any of the JDBC vendor properties lists (for example, properties.db2.jcc or properties.oracle) while the server is running, you might see J2CA8040E failures. These failures state that multiple dataSource elements cannot be associated with a single connectionManager. These failures are generated even if your configuration associates only one connectionManager with the dataSource element.

When you make updates to the configuration of any of these JDBC resources, restart the server.

An application that relies on a result being returned by getRealPath must be deployed as an expanded application, not as a WAR file

The Java EE specification states the getRealPath() method returns a null value if the content is being made available from a web archive (WAR) file. When you deploy a WAR file to the Liberty profile, the profile does not automatically extract the archive file into a directory structure. Therefore the application might fail to start. If wer application relies on a result being returned by getRealPath(), you must deploy the application as an expanded web application, not as a WAR file. For example, you can manually extract the WAR file and copy the expanded application to the dropins directory.

WAS full profile scripts do not work with the Liberty profile

You cannot use any of the scripts under the bin directory of the WAS full profile to administer the Liberty profile.

Fileset restrictions

The following restrictions apply to Filesets:

• Filesets do not recursively explore subdirectories of the base directory. For example the following instructions are not supported:

  <fileset dir="\temp" includes="**\a.jar"/> 
  <fileset dir="\temp" includes="a\a.jar"/> <fileset dir="\temp" includes="*\a.jar"/> <fileset dir="\temp" includes="a\b\a.jar"/>

• If we use symbolic links with Filesets, add a forward slash ("/") at the end of the dir attribute value. For example:
  <fileset dir="${ihc.home}/" includes="*.jar"/>

When you unpublish a shared library, it cannot be deleted until the server is stopped

When you unpublish a shared library from a server, the library JAR file is not immediately released from the server. Therefore the operating system does not know the file is no longer in use, and does not let you delete the file. When you next stop the server, the library JAR file is released and we can delete the file.

beanvalidation-1.0 feature restrictions

For the beanvalidation-1.0 feature, the following restriction applies:

• There is no support for bean validation inside OSGi applications.

jaxrs-1.1 feature restriction

For the jaxrs-1.1 feature, Liberty profile does not support JAX-RS third-party APIs in the developer tools as in the full profile.

jpa-2.0 feature restrictions

For the jpa-2.0 feature, the following restriction applies:

• There is no support for dynamic removal from at run time.

jsf-2.0 feature restrictions

For the jsf-2.0 feature, the following restriction applies:

• There is no support for dynamic removal at run time.

jsp-2.2 feature restrictions

For the jsp-2.2 feature, the following restriction applies:

• There is no support for the useInMemory configuration option to only store the translated JSP file in memory.

Related reference:

Liberty profile: Developer Tools known restrictions

Reference topic |