How to migrate from WebSphere MQ Everyplace version 1 to the WebSphere MQ Everyplace version 2.0 trace
mechanism
To migrate from version 1 of the product to version 2.0 of the product:
- Review the documentation presented in the Java programming reference material,
particularly the following classes
- com.ibm.mqe.MQeTrace
- com.ibm.mqe.MQeTraceHandler
- All classes in the com.ibm.mqe.trace package
- Stop using the com.ibm.mqe.MQeTraceInterface class. This class
is deprecated in version 2.0. Change your code to implement the com.ibm.mqe.MQeTraceHandler interface instead.
- Stop using the com.ibm.mqe.MQe.setTraceHandler() method. Use
the com.ibm.mqe.MQeTrace.setHandler() method instead.
- Stop using the com.ibm.mqe.MQe.getTraceHandler() method. Use
the com.ibm.mqe.MQeTrace.getHandler() method instead.
- Stop using the com.ibm.mqe.MQe.trace(...) methods. Use the com.ibm.mqe.MQeTrace.trace(...) methods instead.
- Remove any dependencies your code has on examples.trace.MQeTraceResource string resource bundle classes. This class has been removed from version
2.0 of WebSphere MQ Everyplace. The version 2.0 trace mechanism does not provide a simple resource
bundle in the examples.trace package to use when decoding trace information.
Access to WebSphere MQ Everyplace product trace data is provided through the com.ibm.mqe.trace.MQeTraceRenderer, com.ibm.mqe.trace.MQeTracePoint and com.ibm.mqe.trace.MQeTracePointGroup classes.
- Consider whether trace information can be left in binary format, using
the com.ibm.mqe.trace.TraceToBinaryFile or similar classes provided
by the WebSphere MQ Everyplace product.
- Consider instantiating a trace collection handler, and setting it into
the MQeTrace class, but setting the filter in the MQeTrace class
to discard or collect information as desired.
- Consider that IBM service staff may ask for capture of trace information
to diagnose the cause of problems reported. Allowing the setting of the MQeTrace
filter may be easier than allowing the configuration of a collection trace
handler.