The supplied server runs as a stand-alone Java program. However, it is implemented as an m-bean. This enables it to be integrated with a Java Dynamic Management agent and managed through the adaptorMO interface.
Note - The class and library server does not support JAR files or ZIP files.
|
java [options] com.sun.jaw.impl.server.rmi.NetClassServerImpl
|
If there is no RMI registry running on the machine where the server is started, the server starts the registry and registers itself.
Options
You can specify the following system properties:-DDEBUG
-Dclasspath=classpath
-Dlibpath=libpath
-Dport=portno
-Dservice=servicename
-Ddirfile=directivefile
| CODE EXAMPLE 12-1 Starting the Class and Library Server |
Retrieving and Updating Search Paths
When you start the server, you have to specify the search paths for locating:
host = hostname
An example of the object name of a class loader is given in CODE EXAMPLE 12-2.
Adding an RMI Network Class Loader Through a Manager
The supplied class loader is implemented as an m-bean. This enables it to be managed through the adaptorMO interface. To add a class loader through a manager, you include in the manager code that requests the class loader to be added to the agent. The c-bean that the adaptorMO interface requires for managing a class loader is supplied as the Java class com.sun.jaw.impl.agent.services.loader.rmi.NetClassLoaderMO. Therefore, the manager you develop must contain the code required for instantiating this class.
If your manager needs to obtain c-beans from a remote class server, you have to instantiate a class loader in the manager. For more information, refer to "Class Loader" on page 87.
Directly Adding an RMI Network Class Loader
To add a class loader directly to an agent, include in the agent the code required for instantiating the com.sun.jaw.impl.agent.services.loader.rmi.NetClassLoader class.
| CODE EXAMPLE 12-3 Instantiating a Network Class Loader in Agent Code |
Instantiating a Remote M-Bean Using the RMI Network Class Loader
The methods for instantiating a remote m-bean are the same as those for instantiating any other m-bean, although it is necessary to specify the object name of the class loader to be used.
| CODE EXAMPLE 12-4 Instantiating a Remote M-Bean Through a Manager |
CODE EXAMPLE 12-5 shows code for instantiating a remote m-bean using the RMI network class loader through an agent. In this example, the class RemoteClass is stored on a remote class server. The RemoteClassON is the object name given to the m-bean to register it with the repository. The NetClassLoaderON is the object name of the class loader to be used.
| CODE EXAMPLE 12-5 Instantiating a Remote M-Bean Through an Agent |
Using the Library Loading Service
The RMI network class loader implements the LibraryLoaderIf interface to allow the loading of dynamic native libraries. The basic operation of the service is described in "Library Loaders" on page 142. The library loading service provides a versioning capability based on a version number stored in the libversion file and the libpath parameter in these classes:
| CODE EXAMPLE 12-6 Starting the Class and Library Server |
The library path contains two library directories, libs1 and libs2. These are located in the /class_server/lib/ directories. The directories, libs1 and libs2 must contain a user created libversion file to enable library versioning. CODE EXAMPLE 12-7 shows an example hierarchy for the libraries on the RMI network class server.
| CODE EXAMPLE 12-7 Library Hierarchy in the RMI Network Class Server |
Libpath in RMI Network Class Loader
The library path property specifies the directory into which the required library will be copied before the RMI network class loader loads it into memory. CODE EXAMPLE 12-8 shows the code to set the directory property of the network class loader instantiated in CODE EXAMPLE 12-3.
| CODE EXAMPLE 12-8 Setting the directory property |
Basename
The basename is the first unique directory name where the libraries are stored on the server. Each directory referred to by a basename contains a libversion file. Basenames enable you to maintain versioning control on any number of libraries. The basenames on the class server and the class loader must be identical for the library loading service to operate correctly.
Loading a Library From the Local File System
CODE EXAMPLE 12-9 shows an example hierarchy for the libraries on the agent host.
| CODE EXAMPLE 12-9 Library Hierarchy on the Agent Host |
Local libraries are loaded by invoking the LibLoader.loadLibrary method. The LibLoader.loadLibrary method is invoked by a class that was loaded through the network class loader. The LibLoader.loadLibrary method is described in "Including Native Code in an M-Bean" on page 143. CODE EXAMPLE 12-10 shows two methods of loading the same library.
| CODE EXAMPLE 12-10 Loading a Library From the Local File System |
Loading a Library From the Class Server
Libraries are loaded from the class server using the LibLoader.loadLibrary method. CODE EXAMPLE 12-11 shows code for loading two instances of the same library using the basename to differentiate between the two. CODE EXAMPLE 12-11 also shows code for loading libraries into two different operating environments.
| CODE EXAMPLE 12-11 Loading a Library From the Class Server |
Security Manager
The security manager supplied with the Java Dynamic Management Kit is programmed to accept incoming libraries. For further information, refer to "Security Manager" on page 145.
When running the RMI network class loader in non-secure mode, you must use the security manager provided with the Java Dynamic Management Kit to be able to load native libraries.
Code Signing
The RMI class and library loading service supports class signing, enabling it to ensure that only classes from a trusted source are downloaded over a network. This involves:
