# Troubleshooting

Yes, sometimes things are broken. If MTJ does not appear to be working properly, We are happy to have you report it here. You can help us enormously, however, if you do a little legwork before entering a bug report.

- Collect basic configuration information
- Give a detailed description of exactly how to reproduce the problem
- Include the workspace log file
- Isolating the command line of the launched executable
- Enable Logging for UEI Device Discovery
- Using the wireless toolkit directly

## Collect basic configuration information

Please collect the following basic configuration information:

- Version number of Eclipse that you are running. Select Help / About Eclipse Platform and note the Version and Build id.
- Version number of the MTJ plugin. From the About Eclipse Platform dialog, press the Feature Details button and note the version of the MTJ feature.
- The platform MTJ is being run on, such as Windows XP (c) or Debian Linux.
- The windowing system MTJ is running on, such as Windows XP (c), GTK or Motif.
- Manufacturer and version number of the JDK you are using. (e.g. Sun JDK 1.4.2_03)

This helps tremendously in attempting to recreate the bug.

## Give a detailed description of exactly how to reproduce the problem

The more detail you provide, particular step-by-step detail, the better. In particular, provide as many of the Preference settings as you can, along with a step-by-step description of what you did, what you expected, and what happened. If there's a bug in the code, I have to be able to isolate the part that's faulty, which means I have to be able to do what you did. It sounds elementary, but many times it's the exact sequence you did things, or some non-obvious interaction between settings that trigger a problem.

## Include the workspace log file

As you know, Eclipse stores settings and other state information in your workspace. By default, your workspace is stored in the directory named workspace within your Eclipse installation directory. You also can specify a particular non-default workspace directory using the -data command line option when invoking Eclipse.

Within the workspace directory, there is a subdirectory named .metadata. This, in turn, may contain a file named .log. Unix users, remember that files that being with the character "." are hidden by default. You will need to use the "-a" option to ls in order to see them.

The .log file contains valuable debugging information, particularly exception traces. One way to help me isolate a problem is to close Eclipse, delete this file, then run Eclipse, cause your problem to happen, and then close Eclipse again. Now look to see if a .log file has been created. If it has, include this file as part of your report.

If you have the Plugin Development Environment loaded, this same information can be more easily obtained by opening the "Error Log" view. If you don't have the PDE loaded, this view is not available.

## Isolating the command line of the launched executable

Sometimes it is necessary to know exactly what command line MTJ generated for a particular WTK invocation. When you run Eclipse, add the arguments

-vmargs -Dmtj.dump.launch=true

to your Eclipse command line. This will cause extra debugging information to be placed into your .metadata log file. Then include the log information as described above. If you have more than one system property to be set, you only need to specify -vmargs once before them all.

## Enable Logging for UEI Device Discovery

If you are having trouble importing a UEI-based toolkit, add the arguments

-vmargs -Dorg.eclipse.mtj.toolkit.uei.debug=true

to your Eclipse command line. This will cause extra debugging information to be placed into your .metadata log file. Then include the log information as described above. If you have more than one system property to be set, you only need to specify -vmargs once before them all.

## Using the wireless toolkit directly

There are a number of parts that make up your mtj development environment. Eclipse is the IDE, mtj is a set of plugins that provides a bridge between that IDE and a Wireless Toolkit (WTK), and a WTK is a development environment provided by a vendor to allow you to develop for a Java ME device. mtj's goal is simply to allow you to use the Eclipse IDE in a convenient way while developing your MIDlet, instead of having to use the WTK directly.

mtj itself doesn't have much logic specific to the implementation of the various devices being emulated or the features that they provide. All of that function is implemented in the WTK. In many cases, you may find that by eliminating Eclipse and mtj you may find further information that can be used to solve your problem. Simply load up and run your MIDlet directly using the WTK without Eclipse or mtj.

mtj doesn't provide direct support for loading your MIDlet onto any device whatsoever - it's completely device agnostic, merely allowing you to use the Eclipse IDE to "operate" the compile-and-debug features of your WTK. mtj doesn't really "know" about devices - all it "knows" about are toolkits.

A good example of this is the OTA launch feature of mtj which is simply a link to the capabilities of the WTK to allow a MIDlet to be loaded "Over The Air", in much the same way that a real device normally would. OTA debugging vs. direct debugging doesn"t really make that much difference in most situations when you're debugging your MIDlet. It is useful, however, to make sure that your JAD settings are all correct, and to allow you to simulate a few special conditions that arise once in a while.