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
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.
