Manage shared libraries

 

+

Search Tips   |   Advanced Search

 

Shared libraries are files used by multiple applications. Each shared library consists of...

• symbolic name
• Java class path
• native path for loading JNI libraries

Isolated shared libraries each have their own class loader, enabling a single instance of the classes to be shared across the applications. Each application can specify which isolated shared libraries that it wants to reference. Different applications can reference different versions of the isolated shared library, resulting in a set of applications sharing an isolated shared library.

With isolated shared libraries, some applications can share a single copy of library A, v1 while other applications share a single copy of library A, v 2, for a total of two instances in memory.

Guidelines...

• Associate a shared library with an application to load the classes in a local class loader, which can be an application-wide or module-wide.

• Associate an isolated shared library with an application to load the classes in a separate class loader.

• Associate a shared library with a server to load the classes in a server-wide class loader.

  This class loader is the parent of the application class loader, and the extensions class loader is its parent. Associating a shared library with a server associates the file with all applications on the server.

• Do not associate an isolated shared library with a server if we want a separate class loader for a shared library.

  If we associate the shared library with a server, WAS ignores the isolation setting and still adds files in the shared library to the appserver class loader. That is, associating an isolated shared library with a server associates the file with all applications on the server. WAS ND v7.0 does not use an isolated shared library when you associate the shared library with a server. Associate an isolated shared library with an application.

Instead of using the admin 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.

 

Use the admin console to define a shared library

1. Create a shared library.

   On a single-server product, we can define a shared library at the cell, node, or server level.

   On a multiple-server product, we can define a shared library at the cell, node, server, or cluster level.

   Define a library at one of the these levels does not automatically place the library into a class loader. You must associate the library with an application, module, or server before WAS loads the classes represented by the shared library into a local or server-wide class loader.

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

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

     If you enabled the setting...

     Use an isolated class loader shared library for this shared library

     ...associate the isolated shared library with an application 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.

 

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 no longer displays in the list.

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

 

Related concepts

Class loaders

 

Related tasks

Set native libraries in shared libraries

 

Related

Shared library settings