These release notes contain:
The Java Dynamic Management Kit version 4.0 is compatible with the Java Management Extensions Instrumentation and Agent Specifications, v1.0, Public Release 2. This is the very latest release of the JMX specification at the time the Java Dynamic Management Kit is shipping (December 1999).
The corresponding document can be viewed on-line once the documentation package has been installed (see "Overview of the Product Documentation").
For historic reasons, the previous version of the JMX specification was identified as "Draft 2.0," First Public Release (August 1999).
The Java Dynamic Management Kit version 4.0 is officially supported for development platforms under the following configurations:
Solaris 2.6 and Solaris 7, both SPARC and Intel Platform Editionswith Java 2 SDK, v1.2.2 Reference Implementationor JDK 1.1.8 Reference Implementation
Windows NT 4.0 service pack 5 on Intel platformwith Java 2 SDK, v1.2.2 Production Release for Windows NTor JDK 1.1.8 Production Release for Windows NT
Deployment platform configurations are unsupported. However, the Java Dynamic Management Kit components are 100% Java code and should run with minimal modifications on environments with compliant Java Runtime Environment for Java 2, v1.2.2 or JDK 1.1.8. Many other configurations have been tested and are known to work reliably.
Due to major architectural changes, including the JMX compatibility, there is no backwards compatibility between version 4.0 of the Java Dynamic Management Kit and previous releases (3.2, 3.0, 2.0). Code developed for previous releases will most likely need to be ported in order to take advantage of the new architecture. Agents and managers developed with different versions of the product are definitely incompatible at the communications level.
One notable exception to this rule is the SNMP interoperability. Due to the relatively stable protocol definition, SNMP can be used to connect different versions of the Java Dynamic Management Kit, to the extent that the protocol was implemented by those versions. Agents or managers must continue to run their original version of the product, but they may communicate through SNMP with entities relying on a newer version
You must run all communicating agents and managers with the same major version of the Java Runtime Environment, either all using JDK 1.1 or all using Java 2. The behavior of a manager running Java 2 and communicating with an agent running the JDK 1.1, or vice-versa, is undefined. Data integrity and behavioral integrity are only possible when both agent and manager run the same version of the Java environment.
Again, SNMP interoperability has the advantage over other protocols of being independent of the Java environment version. The SNMP protocol adaptor can, regardless of its Java version, receive and decode requests from any SNMP manager. And a manager implemented with the SNMP manager API can send request to any agent, without needing to know about its version compatibility.
When product version compatibility and Java version compatibility are respected, the Java Dynamic Management Kit offers full management compatibility across heterogeneous platforms. For example, a manager running on a SPARC server could manage a whole deployment of Windows NT PCs, controlling their availability and upgrading their Java-technology based software when needed.
The Java Dynamic Management Kit product includes both printable and on-line documentation.
The HTML documentation is available after an installation of the product that includes the documentation package. On the machine where you installed the product, open the following URL in any browser: file:/installDir/SUNWjdmk/jdmk4.0/JDKversion/index.html. This page contains links to all the product documentation supplied on-line with the Java Dynamic Management Kit. This includes:
Getting Started with the Java Dynamic Management Kit 4.0
Java Dynamic Management Kit 4.0 Tools Reference
Java Dynamic Management Kit 4.0 Tutorial
The Java Dynamic Management Kit API specification generated automatically by Javadoc
The Java Management extensions specification documents
Complete PostScriptTM and PDF versions of the above books are supplied on the CD-ROM of the product. These files are located in the docs directory at the common root of the CD-ROM. This directory also contains a PDF version of the full Java Dynamic Management Kit API generated by Javadoc using the MIF (maker interchange format) doclet. The MIF doclet formats the Javadoc API for the printed page, providing an automated conversion of the Javadoc appearance into a PDF file that preserves all of the cross-referencing.
The installation of the Java Dynamic Management Kit creates directories that certain services use by default. These directories are located under the main Java version-specific branch of the installed directories, meaning that both Java versions of the product can be installed and run simultaneously. The following table shows the name and usage of these working directories (we show only Solaris path names, Windows NT folder names are identical):
Table 3-1 Working Directories
Directory |
Description |
---|---|
installDir/SUNWjdmk/jdmk4.0/JDKversion/etc/conf |
Contains the template.acl file and is the default location for the jdmk.acl file for defining access rights in SNMP agents |
installDir/SUNWjdmk/jdmk4.0/JDKversion/etc/mibgen |
Contains the mib_core.txt file that is always used by default when "compiling" MIBs with the mibgen tool |
installDir/SUNWjdmk/jdmk4.0/JDKversion/tmp |
Solaris only: a storage area for native libraries loaded by the m-let service |
If you install the Java Dynamic Management Kit in the default directory on a Solaris platform, installDir will be /opt. In this case, you will need super-user privileges to write the acl.jdmk file in the etc/conf directory.
The following restrictions apply to Java Dynamic Management Kit 4.0, they can explain inconsistent behavior and suggest a workaround:
The MBean server delegate object exposes the read-only SpecificationVersion attribute of type String. This attribute currently returns "2.0 Second Public Release" when it should return the full version number of the JMX specification which is currently "1.0 Public Release 2".
InformRequest and Report PDUs are not supported.
The mibgen tool cannot handle the following constructs:
Nested groups - reports an error and fails to compile the MIB
Row status - doesn't cause an error or interrupt compilation, but no special support is provided for the semantics of RowStatus variables (as defined in RFC 1903).
Due to the limitations of the HTML protocol, the HTML adaptor does not provide the same management view as a connector. For example, you cannot set attributes individually in the MBean view--all setters are called every time the "Apply" button is selected, even if the content hasn't changed.
Also, the HTML adaptor can only represent a limited set of types through an HTML interface. Any attribute or operation which relies on an unsupported type does not appear. This means that some component functionality is inaccessible through the HTML adaptor.
The tutorial doesn't cover all of the sample applications found in the examples directory. All of the examples include detailed README files and well-commented code. In addition, certain topics can be found elsewhere:
Notifications are well covered in the JMX instrumentation specification
The MBean registration process is covered in the JMX agent specification
Proxy MBeans are introduced in Getting Started with the Java Dynamic Management Kit 4.0
The monitoring and timer services are covered in the JMX agent specification
When running the JDK 1.1.8 virtual machine with native threads and using an HTTP connector client, an unexpected java.lang.ClassCastException is sometimes thrown. The workaround to this problem is to deactivate the keep-alive feature of the java.net.HttpURLConnection class. You can do this by running your application with the following property definition on the command line:
$ java -Dhttp.keepAlive=false yourApplication |
The JIT (just in time) compiler of the Java virtual machine on the Windows NT platform can cause Java Dynamic Management application to fail. It is recommended to disable the JIT compiler on the Windows NT platform.
Using green threads when running with a Java virtual machine other than a production release is also a known source of errors. Avoid using this combination to minimize the risk of unexplained failures. Please refer to the JDK documentation for more information about native and green threads.