Upgrading to 2.1 from 1.3
The following is a list of changes, new features and
upgrades in TMX4J 2.1. The changes are compatible with Version 1.3.
-
DBCS Enabling: the classes included in the
core JMX JAR files are double-byte character set enabled code, although GVT
has still not been executed.
-
Modified the internal structure of the
TMX4J packages. The package for the NT platform and the Solaris paltform has
been merged together and included in one single compressed file for
making easier the download.
-
Added the Java Flexible Logging Toolkit (JFLT) facility that provides the ability to specify
which (user-defined) log mechanism to use for message logging
in the TMX4J libraries. This is useful in environments in which the JMX-based
application is already developed for using a specific logging
toolkit and/or the configuration is changed through an external
mechanism. In this way it is possible to "capture" and integrate the TMX4J
message logging with the application runtime environment (for instance
writing logging to the same physical device, such as
a console, file, or socket). For convenience, all the JFLT packages have been
included in one new separate JAR file (
jflt.jar
) that should
be specified on the CLASSPATH
(but see note on
CLASSPATH setting
below).
-
Added new optional property keys to
the jmx.properties
configuration file to allow user to set the logging mechanism using the
new logging facility (see the configuration file keys description).
-
Changed the error logging message text
to be more concise and interpretable by an end user (message logging is
intended to be viewed by end users, systems administrators and support
personnel among others). In particular, no more information about
the stack trace are printed on the logfile when an exception
occurs. Developers may however catch all the Java exceptions thrown
inside the TMX4J code in their JMX-based applications and print the stack
trace together with considerably more complex, verbose and detailed
information than message entries when needed.
-
Upgraded the JAR file (log.jar)
containing the Logging Toolkit for Java (JLog) with version
2.1.2. Note that the default TMX4J logging mechanism is still
based on JLog.
-
Changed a wrong comment about log
levels values in the jmx.properties file (you need to set
log level property to 4 for getting high verbosity instead of
1).
-
Changed from Java 2 SDK SE version
1.2.2 to Java 2 Platform, Standard Edition, version 1.3.0 (Java 2
SDK SE 1.3.0 IBM) to build the TMX4J software.
-
Testing on more platforms: core JAR files
work on all Java platforms, but the TMX4J 2.1 has been tested on several
platforms. Click here to see the list of tested platforms.
-
Added com.tivoli.jmx.tools.Version,
which displays the version of the TMX4J. The manifest of the
jmxx.jar and jmxc.jar files was modified to
specify the name of this program as entry-point class (adding an
appropriate Main-Class header). With the manifest prepared in
this way, you can launch the tool and print the TMX4J version simply with
a command of this form:
java -jar jmxx.jar
or
java -jar jmxc.jar
(only in the case jmxc.jar
is in the same directory of jmxx.jar
)
-
Added missing file uninstall_service.bat for uninstalling the the
TMX4J Sample Agent (Windows NT service).
-
Bug fix: calling the queryMBeans or queryNames
MBean server's method with a non-null QueryExp parameter,
if setMBeanServer
method has not been invoked on that parameter prior to the MBeanServer method call an InvalidApplicationException is thrown.
-
Bug fix: the
serialization/deserialization of several JMX classes did not work
properly. In particular
ModelMBeanInfoSupport
and Notification
classes were changed
internally to add the code to
support the deserialization.
-
Bug fix: the MBean server
invoke
method did not work properly when the invoked
MBean method wants a parameter that is a class loaded by a class loader
different from the class loader that has loaded the MBean
(phew...).
-
Bug fix: in some remote circumstances the
MBean server
createMBean
and instantiate
methods could used wrong class
loaders for loading the parameter types (that is the array of
Class
objects that represent the signature of the constructor to
be invoked).
-
Bug fix: the abstract
startListener
method of com.tivoli.jmx.http_pa.Listener
class (HTTP adapter extension
service) was hanging.
-
Bug fix: problem using Netscape 6.0 with the HTTP Adaptor.
-
Bug fix: an exception occurred when trying to access
MBean's attributes or operations just after having been registered in the MBean
server but before the
postRegister
termination.
-
Added answer to a frequently question about thread-safe in the Tivoli JMX implementation (see FAQ).
-
Enhanced and updated documentation, FAQs, and Javadoc.
Upgrading to 1.3 from 1.2
The following is a list of new features and upgrades in TMX4J 2.1:
-
Added a tool to test if a Java™
class is a JMX-compliant MBean.
-
Monitors enhanced with thread
pool and a better scheduling activity.
-
Error handling of JMX daemon and NT service improved.
-
Internal descriptive messages have been included in catalogs for supporting the localization of the TMX4J into different languages.
-
There have been some changes to the property keys specified in the jmx.properties file.
-
A bug in MLet service fixed: <ARG> tags in the m-let text
file are parsed correctly now.
-
The query mechanism of the MBean server has been modified for fixing a
problem in the filter mechanism.
-
Other minor modifications and bug fixed.
-
All documentation and examples have been updated.
-
Support for IBM's Java 1.3.0.
-
TMX4J offers new free Commercial License.
Upgrading to 1.2
from 1.1
The following is a list of bugs fixed in the previous TMX4J 1.2:
-
HTTPADAPTOR: If an attribute of an MBean is writable
but not readable, the string "unreadable" is displayed as current
value of the attribute. Previously an MBeanInfo error page was displayed.
-
HTTPADAPTOR: If an exception is thrown when an attempt
to get the value of an attribute of an MBean is done, a message notifying this
exception is displayed as value of the attribute. In the previous version a
page with a message error was displayed.
-
HTTPADAPTOR: If an exception is thrown when an attempt
to invoke a method of an MBean is done, a message notifying that an exception
has been thrown is displayed as value of the operation. In the previous version
the message "unable to invoke the method" was displayed.
-
HTTPADAPTOR: The invocation of overloaded methods works
properly; the previous version did not allow invoking all the available
methods.
-
HTTPADAPTOR: The creation of MBeans now allows using
all the class loaders in the default loader repository. The previous version
worked only with the default class loader.
-
MODELMBEAN: The current implementation of the
RequiredModelMBean allows using, as managed resource or target objects,
instances of classes loaded through MLets. The previous version was able only
to use classes loaded by the default class loader.
-
SAMPLES: To simplify the usage of the TMX4J control
Program, the StartRmiDaemon.bat has been changed in order to launch the
rmiregistry. The previous version required the user to run the rmiregistry.
This approach was error prone, in fact the rmi stub was not found if the CLASSPATH
was not set properly.
-
SAMPLES: The tmx4jcp.bat can be run without parameters
in order to display the help. The previous version threw a
NullPointerException.
-
SAMPLES: Fixed a wrong usage of the MBeanAttributeInfo
constructor in the MBean_Dynamic MBean. A description was used instead of the
type.
In TMX4J 1.2 duplicate
MBean interface names were not allowed. For example, given the following
interface and class definitions:
package org.public.specification;
public interface ResourceMBean {
void a();
int b();
}
package com.tivoli.implementation;
public interface ResourceMBean extends
org.public.specification.ResourceMBean {
String c();
}
package com.tivoli.implementation;
public class Resource implements ResourceMBean {
...
}
An attempt to create an
instance of com.tivoli.implementation.Resource
via the MBeanServer, or register an existing instance with the MBeanServer,
would result in a NotCompliantMBeanException.
In TMX4J 1.3 no exception would be thrown and the Resource management interface
would be the union of the methods declared by the ResourceMBean interfaces in org.public.specification and com.tivoli.implementation.
The jmxx.jar file
distributed with TMX4J 1.3 includes the VerifyMBeanCompliance
tool to test if a Java class is a JMX-compliant MBean. If the class is an MBean
the tool determines its type (standard or dynamic). In order to use this tool
you have to type the following command:
java
com.tivoli.jmx.tools.mbeanvalidator.VerifyMBeanCompliance java_class_name
In the case of a standard
MBean it displays all information about the attributes and operations exposed
for management too.
The property names for the
keys used for configuring the logging have been changed as described below. The
new property include has been added. The values for these keys must be
specified in the jmx.properties file.
WARNING:
the following keys are used only by the JlogManager
(see below)
JmxLog: to enable/disable
the writing of the log file.
JmxLogFile: the
location and name of the log file.
JmxConsoleLog: to
enable/disable the log on console.
JmxMaxLogFiles: the
maximum number of log files.
JmxMaxLogFileSize:
the maximum size of each log file (in kilobytes).
JmxLogFormatter: to
enable the writing of the thread id for each log entry.
Jmx<comp>LogLevel:
control the number of messages logged to the log file.
<comp>
may be: Core, Monitor, Timer, Utils, Loading,
Relation, and ModelMBean
BootstrapPropsURL: refers to the
URL location where the bootstrap configuration file will be searched for.
include:
allows inclusion of another property file from within the jmx.property.
See comments included in
jmx.properties to get more information about message log configuration. See also
the following note.
Starting with TMX4J v 2.1, the following new keys have been
added (see JFLT documentation for more details):
LogManager: controls which logging mechanism is used. It must be the fully-qualified name of a class implementing the JFLT logging manager
interface (com.tivoli.jflt.LogManager
). It follows a list of possible
LogManager
implementations:
com.tivoli.jmx.utils.logging.jlog.JlogManager
: this is the default
TMX4J logging manager; it writes messages using a Logging Toolkit for Java
specialization (JLog);
com.tivoli.jflt.buffering.CircularBufferManager
: log messages are not
written to an output device as they are logged but they are held in a circular
buffer until the setManager method is called;
your.company.logging.xyzManager
, etc.: log messages are written
according to custom logging mechanisms.
JmxUserLogLevel: using this key you can change the log level
for all the JFLT-based user code in the current JVM.
Monitors enhanced
To address the problem of a long running Monitor observation
blocking all the other monitors in the JVM, a pool of threads has been
developed for handling the observations without affecting the scheduling. The
thread pool is configurable through some new keys to be added in the
jmx.properties file. To get more information about JMX Monitors see the TMX4J
FAQ.
Last Updated: 11/21/2001