Manage shared libraries

Shared libraries are files used by multiple applications and consists of a symbolic name, a Java class path, and a native path for loading JNI libraries. We use shared libraries to reduce the number of duplicate library files on the system.

Suppose we have four applications that use my_sample.jar. We can define a shared library for my_sample.jar, and have the four deployed applications reference that library.

Isolated shared libraries each have their own class loader. Applications can specify which isolated shared libraries to reference. Different applications can reference different versions of the isolated shared library. Some applications can share a single copy of Library A, Version 1, while other applications share a single copy of Library A, Version 2.

We use the console to define shared libraries and their library files and to associate libraries with specific applications, modules, or application servers.

Associate a shared library file with an application or module to load the classes represented by the shared library in a local class loader, which can be an application-wide or module-wide class loader. Associate an isolated shared library file with an application or module to load the classes represented by the shared library in a separate class loader created for that shared library. Associate a shared library file with a server to load the classes represented by the shared library in a server-wide class loader. This class loader is the parent of the application class loader, and the WAS extensions class loader is its parent. Associating a shared library file with a server associates the file with all applications on the server. Do not associate an isolated shared library file with a server if we want a separate class loader for a shared library. If we associate the shared library with a server, the product ignores the isolation setting and still adds files in the shared library to the application server class loader. That is, associating an isolated shared library file with a server associates the file with all applications on the server. The product does not use an isolated shared library when you associate the shared library with a server. Associate an isolated shared library with an application or module.

Instead of using the console to associate a shared library with an application, we can use an installed optional package. You associate a shared library to an application by declaring the dependent library .jar file in the MANIFEST.MF file of the application. Refer to the J2EE 1.4 specification, section 8.2 for an example.

1. Create a shared library.

2. Associate each shared library with an application, module, or server.

   • Associate a shared library with an application or module that uses the shared library file.

     If we enabled the Use an isolated class loader for this shared library setting when creating the shared library, associate the isolated shared library with an application or module to use a separate class loader for the shared library.

   • Associate a shared library with an application server so every application on the server can use the shared library file.

3. Use an installed optional package to declare a shared library for an application.

4. Remove a shared library.

   1. Click Environment > Shared libraries in the console navigation tree to access the Shared libraries page.

   2. Select the library to be removed.

   3. Click Delete.

   The list of shared libraries is refreshed. The library file no longer displays in the list.

   
   

   Subtopics

   • Create shared libraries
   • Shared library collection
   • Associate shared libraries with applications or modules
   • Associate shared libraries with servers
   • Installed optional packages
   • Use installed optional packages
   • Library reference collection

   
   

   Related concepts

   Class loaders
5. Configure native libraries in shared libraries
6. Shared library settings