9 Troubleshooting

This chapter explains how to use the debug class to print debug messages. It also describes some common problems and suggests how to solve them.

Printing Debug Messages

The class com.sun.jaw.reference.common.Debug provides methods for printing debug messages. Options provided by this class enable you to specify:

The trace level
The destination of the debug messages printed

All the classes of the Java Dynamic Management Kit use the Debug class for printing debug traces. You can use the Debug class in your own code for printing debug traces for your own classes.

TABLE 9-1 Methods for Specifying the Trace Level
Function	Action
`Debug.setOnAll()`	Enables all traces
`Debug.setOn(int l)`	Enables a specific trace level
`Debug.setOffAll()`	Disables all traces
`Debug.setOff(int l)`	Disables a specific trace level

The trace levels are listed in the API reference information for the com.sun.jaw.reference.common.Debug class.

Specifying the Destination of Debug Messages

To specify that debug messages are logged to a file, specify this system property:


`DEBUG_OUTPUT=filename`

where filename is the name of the file, including the path, to which you want debug messages to be logged.

If you do not specify this system property, debug messages are printed to the terminal.

Starting the Default Base Agent in Debug Mode

Before starting the default base agent in debug mode ensure that:

It is not already running. For information on how to stop the default base agent, refer to Appendix E.
The class path of this agent specifies the location of the Java Dynamic Management Kit classes.

To start the default base agent in debug mode, type:


`prompt java -DDEBUG com.sun.jaw.impl.base.Main`

For the Solaris operating environment, a command is provided to enable you to start the default base agent in debug mode without starting the Java interpreter explicitly. To use this command, type:


`prompt% /opt/SUNWconn/jaw/bin/jaw debug`

The debug messages printed are shown in CODE EXAMPLE 9-1.

Default debug is on

Repository configuration done

cmf: Initializing domain defaultDomain

cmf::addObject: name= defaultDomain:com.sun.jaw.reference.client.mo.FrameworkMO

RepositorySrv::register: addNewDomClassMoi dom = defaultDomain name = defaultDomain:com.sun.jaw.reference.client.mo.FrameworkMO

addNewDomClassMoi: register: ClassName = com.sun.jaw.reference.client.mo.FrameworkMO

Repository.register: name= defaultDomain:com.sun.jaw.reference.client.mo.FrameworkMO

Got domain = defaultDomain

RepositorySrv:: tab == null for dom = defaultDomain cla = com.sun.jaw.reference.client.mo.MetaDataSrvIfMO

Metadata service not found, adding com.sun.jaw.impl.agent.services.light.MetaDataSrv

cmf::newObject: load com.sun.jaw.impl.agent.services.light.MetaD ataSrv, name= defaultDomain:com.sun.jaw.reference.client.mo.Meta DataSrvIfMO

RepositorySrv:: tab == null for dom = defaultDomain cla = java.lang.ClassLoader

cmf::getClass: use default loader for loading com.sun.jaw.impl.agent.services.light.MetaDataSrv

cmf::getClass: was able to load com.sun.jaw.impl.agent.services.light.MetaDataSrv

...

Setting the Class Path

Make sure that the CLASSPATH environment variable specifies the correct location of:

The Java classes of the Java Dynamic Management Kit
Compiled m-bean classes
Compiled c-bean classes

Threads With Native Methods

If a native library is not multithread-safe, using JNI to call routines implemented in the native library can cause the Java virtual machine to fail. To avoid multithreading problems with native libraries, include the Synchronized clause in your Java calls to functions in native libraries.

If a call to a routine implemented in the native library causes the Java virtual machine to fail:

Remove, if possible, all the dependencies on the Java Dynamic Management Kit.
Try to reproduce the problem in a standalone Java program to verify that the problem is not related to the Java Dynamic Management Kit.
Debug your native library by using a debugging tool.

Getters and Setters in a C-Bean

If you want getter and setter methods in an m-bean to be present in c-beans generated by mogen, they must conform to the JavaBeans component model. For example, the following method is not a getter method as defined by the JavaBeans component model:


`getX(A a, B b)`

Therefore, mogen does not generate this method in a c-bean. If you want to define a method that gets the value of several attributes, and if you want that method to be present in a c-bean generated by mogen, define the method as an action by including the perform prefix in the method name:


`performGetX( A a, B b)`

Missing Value Change Events

A VALUE_CHANGE_EVT event is emitted only when properties are changed through the framework, as described in "Setting a Property" on page 50. If a property is modified by its setter method, the framework is not informed and no event is sent.

Adaptor Client Local Exceptions

The getObject method of an adaptor client is successful only if all the c-bean classes are present at a location defined in the CLASSPATH environment variable of the manager. If a c-bean class is not present, a LocalException is thrown. A LocalException at the client wraps a ClassNotFound exception thrown at the agent.

9

Troubleshooting

Printing Debug Messages

Specifying the Trace Level

Specifying the Trace Level at the Command Line

Specifying the Trace Level in the Code of a Class

TABLE 9-1 Methods for Specifying the Trace Level

Specifying the Destination of Debug Messages

Starting the Default Base Agent in Debug Mode

Setting the Class Path

Threads With Native Methods

Getters and Setters in a C-Bean

Missing Value Change Events

Adaptor Client Local Exceptions