Main Index  Release Notes  TMX4J Base  TMX4J Extensions  FAQ 

 

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.

java -jar jmxx.jar   or
java -jar jmxc.jar   (only in the case jmxc.jar is in the same directory of jmxx.jar) 


 Upgrading to 1.3 from 1.2

The following is a list of new features and upgrades in TMX4J 2.1:


 Upgrading to 1.2 from 1.1

The following is a list of bugs fixed in the previous TMX4J 1.2:


 MBean introspection algorithm

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 VerifyMBeanCompliance tool

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 jmx.properties file

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.


 The jmx.properties file (UPDATE)

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.


 
Main Index  Release Notes  TMX4J Base  TMX4J Extensions  FAQ 

Last Updated: 11/21/2001