Previous Next Contents Index


11

Dynamic Loading Services

The dynamic loading services enable you to develop dynamically extensible agents. An agent uses the class loaders to obtain new classes from an arbitrary location. The library loader loads native libraries into the framework.

Class Loaders

Class loaders enable Java Dynamic Management agents to obtain Java classes, m-beans and applications from remote servers or .jar files. The downloaded classes, m-beans and applications can then be loaded into the agent's framework. The Java classes must be present on the machine on which the server is running. You can implement your own class loaders for specific applications. The following class loaders are supplied with the Java Dynamic Management Kit:

The Java Dynamic Management Kit enables you to add a class loader to an agent in either of the following ways:

The Java Dynamic Management Kit allows an agent to contain more than one class loader. This enables you to specify a particular class loader to be used for loading a class, so that you can load classes from a number of different servers.

RMI Network Class Loader

The RMI network class loader enables you to obtain classes from a remote class server. The network class loader must be added to an agent before it can be used. The network class loader must be assigned an object name that contains information on the remote class server. To use the network class loader, you add it to an agent. When you add a network class loader to an agent, you must assign it an object name. The object name you assign to a network class loader must contain configuration information that the class loader requires, as explained in "Object Name of an RMI Network Class Loader" on page 150.

M-Let Service Class Loader

The management applet or m-let service enables an agent to obtain m-beans from a remote .jar file. The agent does this by loading an m-let text file, which specifies information on the m-beans to be obtained. The information on each m-bean is specified in a single instance of a tag, called the MLET tag. The location of the m-let text file is specified by a URL. When an m-let text file is loaded, an instance of each m-bean specified in the file is created.

Bootstrap Service Class Loader

The bootstrap service simplifies the distribution of new releases of an application (namely an agent or a manager) from a central server. It is a standalone Java program that enables you to load an application from a remote .jar file. To obtain a new version of an application, all you have to do is run the bootstrap service on the system that requires the application to be loaded and run. Information on the application is contained in an m-let text file. You specify the URL of the m-let text file when you run the bootstrap service.

Loader Repository

All Java Dynamic Management Kit class loaders running in the same Java virtual machine register with the loader repository. When an agent tries to load a class where no class loader has been specified, the agent looks in the framework's class loader, the system (using the class path) if no class loader is defined for the framework and finally in the loader repository. The loader repository contains pointers to all of the class loaders that have registered.

FIGURE  11-1 Operation of the Class Loaders

Instantiating a Remote M-Bean Using a Specific Class Loader

The Java Dynamic Management Kit allows an agent to contain several instances of a class loader, provided that every instance is registered with the repository. This enables, for example, each class loader to be connected to a different remote server. Therefore, by using a specific class loader, an application is able to specify the remote server to be used for loading a particular class. In this way, the application can load classes from a number of different servers.

To use a particular class loader, make sure that the request to create an object specifies that class loader. The class loader must be identified by its object name. If you do not specify the class loader, the Java Dynamic Management Kit uses the framework classloader, the system (using the class path) if no class loader is defined for the framework and finally the loader repository. If the class is not found by the loader repository, then the class is not available within the Java virtual machine.

The methods for instantiating a remote m-bean are the same as those for instantiating any other m-bean, as described in Chapter 4 "Operations on M-Beans". When an agent invokes a method to instantiate a remote m-bean, all of these conditions must be satisfied:

Implementing a Class Loader

The class loader provided by the Java Dynamic Management Kit extends the abstract class java.lang.ClassLoader. The class java.lang.ClassLoader is provided by the Java Development Kit (JDK). The Java Dynamic Management Kit does not define any new interfaces for its class loader. However, to be able to load native libraries in addition to classes, a class loader must implement the com.sun.jaw.reference.agent.services.LibraryLoaderIf interface.

Library Loaders

The library loader loads native libraries into the framework. The Java Dynamic Management Kit enables native libraries and m-beans to be loaded from the same remote server. A native library is loaded whenever a new m-bean class that includes native code is loaded. For information on how to implement an m-bean that includes native code, refer to "Including Native Code in an M-Bean" on page 143.

When the library loader is called, the m-bean provides the class for which a native library is to be loaded. Using this information, the library loader retrieves the class loader through which the class was loaded. The service then performs either of the following actions:

The library loaded depends on the hardware platform and operating system on which the library will run. For more information, refer to "Location of Native Libraries" on page 144. The native library can be loaded from the local file system or a remote server.

The Java Dynamic Management Kit allows an agent to load only dynamic native libraries (.dll for Windows, .so for Solaris). An agent is not allowed to load static native libraries.

Including Native Code in an M-Bean

To enable an m-bean to use a native library, include in the m-bean a call to the static loadLibrary method of the LibLoader class (instead of System.loadLibrary). The caller must include a reference to its Java class when it invokes the loadLibrary method. Such information is used by the framework for identifying the class loader that loads the class. CODE EXAMPLE 11-1 shows the signature for the LibLoader.loadLibrary method.   
CODE  EXAMPLE  11-1     Signature for the Libloader.loadLibrary method

public static void loadLibrary(Class aClass, String baseName, String libName)

CODE EXAMPLE 11-2 shows the code to include in an m-bean to use the library loader service of the Java Dynamic Management Kit.

CODE  EXAMPLE  11-2     Including Native Code in an M-Bean

public KernelStat(String mod, String inst) {
moduleName = mod;
instanceName = inst;
LibLoader.loadLibrary(this.getClass(), "", "stat");
}

Location of Native Libraries

The call to the static loadLibrary method of the LibLoader class also contains information on the location of the native library. This location depends on the operating system and architecture of the machine on which the library will run. The architecture-dependent location relative to the library base path is:
OSName/OSArch/OSVersion/lib/libraryName

The variable parts of this location are:

OSName

The name of the operating system under which the native library will run.

OSArch

The name of the processor architecture of the machine on which the library will run.

OSVersion

The version number of the operating system under which the native library will run.

libraryName

The name of the file that contains the native library. The file name extension depends on the specified operating system (.dll for Windows, .so for Solaris).

For example, the location of the stat native library for the SolarisTM 2.5 operating environment for a Solaris SPARCTM processor would be as follows:
Solaris/sparc/2.x/lib/libstat.so

The stat native library for the Windows NT 4.0 operating system for an x86 processor would be: 

WindowsNT/x86/4.0/lib/stat.dll

Security Manager

The Java Dynamic Management Kit provides an implementation of a security manager which allows the loading of native libraries coming from classes loaded over the network. The implementation is under com.sun.jaw.impl.agent.services.security.AgentSecurityManager.

To load native libraries successfully through specific class loaders, the active security manager running in the Java Dynamic Management agent must be programmed to accept incoming libraries. The security manager supplied with the Java Dynamic Management Kit is programmed to accept incoming libraries.

The active security manager running in the Java Dynamic Management agent should also be used when using the Java Dynamic Management Kit class loading services in a non-secure mode.

For secure operation of the class and library loading services, code signing and a specific security manager that extends the abstract class java.lang.SecurityManager are required. See "Code Signing" on page 145 for more information.

Code Signing

The Java Dynamic Management Kit supports code signing using the javakey utility of the Java Development Kit (JDK). For further information, see the JDK product documentation.

The Java Dynamic Management Kit enables you to run the class loading services in secure mode using the javakey utility for code signing. You must write a security manager that can use the javakey code signing capability and install it as the default security manager in the Java virtual machine in which the agent is running.

The security manager must:

Define your own security policy by implementing the check methods that are defined by the abstract class java.lang.SecurityManager.


Copyright 1998 Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, California 94303 U.S.A.
Copyright in French
Previous Next Contents Index