Appendix C. Differences between trace in WebSphere MQ Everyplace version 1.2.6 or lower and version
2.0
The tracing mechanism for WebSphere MQ Everyplace version 2.0 differs from the mechanism
provided by version 1 of the product. The main objectives of these changes
are to:
- Allow static methods to use the WebSphere MQ Everyplace trace mechanism
- Allow dynamic filtering of trace before the expense of gathering all trace
data has been spent. Version 1 collected all information to be traced, then
if a trace handler wished to discard that information, the cost of its' collection
was wasted effort. Setting a filter in the com.ibm.mqe.MQeTrace class allows
user code to direct WebSphere MQ Everyplace product code not to collect the trace information
in the first place, reducing wasted memory and CPU cycles spent.
- Separate tracing functionality out from the WebSphere MQ Everyplace base class, allowing
tracing to occur without instantiating a WebSphere MQ Everyplace object.
- Remove the dependency of tracing code on a resource bundle in the examples.trace
package
- Remove the ability for users to modify the meaning of WebSphere MQ Everyplace product trace
points. Such user changes confused IBM service staff.
- Remove the ability for users to generate WebSphere MQ Everyplace product trace in non-English
language. Support of the product might require English trace information to
be collected and analysed.
- Provide a selection of optional, fully-supported trace information collectors
- Provide a trace collection mechanism which does not need to render binary
trace information into string information before storing data to persistent
storage. The necessity to retain many trace strings in the JVM creating the
trace information reduces the footprint of the WebSphere MQ Everyplace solution, while retaining
the ability to collect trace information in a more compact form on persistent
media.
- Retain a pluggable trace interface for extension by user code