Liberty profile
The Liberty profile is a highly composable, fast-to-start, dynamic application server runtime environment.
Because the Liberty profile does not include a Java™ runtime environment (JRE), you have to install a JRE provided by either Oracle or IBM®.
For more information about supported Java environments and locations, see Minimum supported Java levels in the Liberty documentation.
- Deploy an application by dropping it into the dropins directory.
- Deploy an application by adding it to the server configuration.
- Web applications
- OSGi applications
- Java Persistence API (JPA)
- Bean validation
- Blueprint
- Java API for RESTful Web Services
- Java Database Connectivity (JDBC)
- Java Naming and Directory Interface
- Java Persistence API (JPA)
- JavaServer Faces (JSF)
- JavaServer Pages (JSP)
- Lightweight Directory Access Protocol (LDAP)
- Local connector (for Java Management Extensions (JMX) clients)
- Monitoring
- OSGi JPA (JPA support for OSGi applications)
- Remote connector (for JMX clients)
- Secure Sockets Layer (SSL)
- Security
- Servlet
- Session persistence
- Transaction
- Web application bundle (WAB)
- z/OS® security
- z/OS transaction management
- z/OS workload management
You can work with the runtime environment directly, or using the WebSphere Application Server Developer Tools for Eclipse.
On distributed platforms, the Liberty profile provides both a development and an operations environment. On the Mac, it provides a development environment.
On z/OS systems, the Liberty profile provides an operations environment. You can work natively with this environment using the MVS™ console. For application development, consider using the Eclipse-based developer tools on a separate distributed system, on Mac OS, or in a Linux® shell on z/OS.
Running the Liberty profile with a third-party JRE
When you use a JRE that Oracle provides, special considerations must be taken to run WebSphere eXtreme Scale with the Liberty profile.- Classloader deadlock
- You might experience a classloader deadlock which has been worked around using the following
JVM_ARGS settings. If you experience a deadlock in BundleLoader logic, add the following
arguments:
export JVM_ARGS="$JVM_ARGS -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass"