Configure class loaders and libraries for Java EE applications
By default, each application can access a set of provided APIs and its own internal classes and libraries. We can override the default settings, and configure class loading for each application.
Each Java EE application has its own class loader in a running Liberty profile server. The Liberty profile assumes some default settings for all Java EE applications, so they can access the supported specification APIs (for example the servlet APIs if the servlet feature is enabled), and the IBM APIs. By default, each application can access these provided APIs and access its own internal classes and libraries. If we have to override the default settings and configure class loading for the application, complete one or more of the following tasks.
If we use configuration to override the default settings, we cannot deploy the application by dropping it into the "dropins" directory.
Subtopics
- Use a Java library with a Java EE application
Include Java libraries in an application.
- Share a library across multiple Java EE applications
Libraries can be shared across multiple Java EE applications. All the applications can use the same classes at run time, or each application can use its own separate copy of those classes loaded from the same location.
- Provide global libraries for all Java EE applications
Put the JAR files for those libraries in a global library directory, then specify use of global libraries in the class loader configuration for each application. The global libraries cannot be used by other applications, for example, by OSGi applications.
- Access third-party APIs from a Java EE application
By default, Java EE applications do not have access to the third-party APIs available in the Liberty profile. To enable this access, the application must be configured in server.xml, or an included file.
- Remove access to third-party APIs for a Java EE application
By default, Java EE applications do not have access to the third-party APIs available in the Liberty profile. We can also remove access explicitly in server.xml, or an included file.
- Overriding a provided API with an alternative version
If an application provides (or uses a library that provides) classes that are also available in the Liberty profile, by default the classes from the Liberty profile are used. To change this so the application uses the alternative versions of these classes, the application must be configured in server.xml, or an included file.
Parent topic: Administer the Liberty profile manuallyTasks:
Defining a utility project as a shared library
Set a web project to use shared libraries