Java Dynamic Management Kit 3.2 Programming Guide | ||||
---|---|---|---|---|
![]() | ![]() | Chapter 14. M-Let, Bootstrap and Launcher Services | ![]() | ![]() |
The bootstrap service simplifies the distribution of new releases of an application (that is, 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.
When you use the MLET tag with the bootstrap service, only a limited set of parameters is permitted, as shown in the following syntax statement:
<MLET CODE=applicationClassfile ARCHIVE="archivelist" [CODEBASE=codebaseURL] > </MLET> |
The attributes are:
CODE=applicationClassfile
This mandatory attribute specifies the full Java class name, including the package name, of the application to be instantiated. The compiled .class file of the application must be contained in one of the .jar files specified by the ARCHIVE attribute.
ARCHIVE="archivelist"
This mandatory attribute specifies one or more .jar files containing the application itself and m-beans or other Java classes to be used by the application to be instantiated. One of the .jar files must contain the file specified in the CODE parameter. If archivelist contains more than one file:
Each file must be separated from the one that follows it by a comma (,).
archivelist must be enclosed in double quote marks ("").
All .jar files in archivelist must be stored in the directory specified by the code base URL.
CODEBASE=codebaseURL
This optional attribute specifies the code base URL of the application to be instantiated. It identifies the directory that contains the .jar files specified by the ARCHIVE attribute. Specify this attribute only if the .jar files are not in the same directory as the m-let text file. If this attribute is not specified, the base URL of the m-let text file is used.
To be able to run the application after loading it from the remote server, the application itself needs to implement the java.lang.Runnable interface. The bootstrap service can then load and instantiate the class and invoke the run() method provided by the interface. In an agent, the run() method is responsible for instantiating the framework and adding the adaptors and services required by the agent being loaded.
If you are using the bootstrap service to load an agent that uses the supplied base agent, you have to modify the code of the supplied base agent so that it implements the java.lang.Runnable interface. The base agent provided with the Java Dynamic Management Kit does not implement the java.lang.Runnable interface.
Besides implementing the java.lang.Runnable interface, the application needs to set the framework class loader to the class loader that loaded the application.
Example 14-9 shows the code required by an agent, if it is to be loaded using the bootstrap service.
Example 14-9. Loading an Agent Using the Bootstrap Service
public void run() { ... // Create an instance of Framework Framework cmf = new Framework((MoRepSrvIf)rep,null); // Set classloader for Framework cmf.setClassLoader(this.getClass().getClassLoader()); ... } |
Example 14-10 shows the code required by a client, if it is to be loaded using the bootstrap service.
Example 14-10. Loading a Client Using the Bootstrap Service
public void run() { ... // Create an instance of AdaptorClient. AdaptorClient adaptor = new AdaptorClient(); // Set classloader for AdaptorClient. adaptor.setClassLoader(this.getClass().getClassLoader()); ... } |
It is possible to load the classes provided in the Java Dynamic Management Kit, contained in a .jar file, at the same time that you load and run an application. To load Java Dynamic Management Kit in this way, specify the .jar file containing Java Dynamic Management Kit as one of the .jar files in the MLET tag.
The following packages need to be installed in the local file systems of all machines that use the bootstrap service and the corresponding classes must be accessible through the CLASSPATH environment variable:
com.sun.jaw.impl.agent.services.bootstrap.*
com.sun.jaw.impl.agent.services.bootstrap.internal.*
com.sun.jaw.impl.common.DefaultPaths
com.sun.jaw.reference.common.Debug
com.sun.jaw.reference.common.LoaderRepository
com.sun.jaw.reference.common.JawStaticMethodPermission
com.sun.jaw.reference.common.internal.CheckJawStaticMethodPermission
If you want to use the RMI adaptor, the files contained in the following packages are also required:
com.sun.jaw.impl.adaptor.generic.*
com.sun.jaw.impl.adaptor.generic.internal.*
com.sun.jaw.impl.adaptor.rmi.*
com.sun.jaw.impl.adaptor.rmi.internal.*
com.sun.jaw.impl.common.*
com.sun.jaw.reference.agent.cmf.*
com.sun.jaw.reference.agent.services.*
com.sun.jaw.reference.client.mo.*
com.sun.jaw.reference.common.*
com.sun.jaw.reference.common.internal.*
com.sun.jaw.reference.query.*
To run the bootstrap service, type:
prompt% java com.sun.jaw.impl.agent.services.bootstrap.BootstrapSrv secure applicURL [local-libdir] |
Where the secure flag (true or false) is only for backwards compatibility and has no effect, applicURL specifies the URL location of the m-let text file containing the information for loading the application and local-libdir is an optional parameter that specifies the local directory for storing native libraries before they are loaded into memory.
Note - The secure flag does not change the behavior of the bootstrap service, it is retained for backwards compatibility.
![]() | ![]() | ![]() |
M-Let Service | ![]() | Using the Library Loading Service |