logoTop pad
logoBottom
Home
History
Table of Contents
Prerequisites
Installation
Creating a new project
Creating a new MIDlet
Running/Debugging
Packaging for deployment
Advanced
Reference
FAQ
Troubleshooting
Support
For EclipseME developers
License


Eclipse Ready Logo
SourceForge.net Logo
spacer


Troubleshooting

Yes, sometimes things are broken. If EclipseME 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.

  1. Collect basic configuration information
  2. Give a detailed description of exactly how to reproduce the problem
  3. Include the workspace log file
  4. Isolating the command line of the launched executable
  5. Enable Logging for UEI Device Discovery
  6. Using the wireless toolkit directly
  7. Collect preverification information
  8. Check to see if it's already been reported

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 EclipseME plugin. From the About Eclipse Platform dialog, press the Feature Details button and note the version of the EclipseME feature.
  • The platform EclipseME is being run on, such as Windows XP (c) or Debian Linux.
  • The windowing system EclipseME 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 EclipseME generated for a particular WTK invocation. When you run Eclipse, add the arguments

-vmargs -Declipseme.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 -Declipseme.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 EclipseME development environment. Eclipse is the IDE, EclipseME 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 J2ME device. EclipseME'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.

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

EclipseME 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. EclipseME doesn't really "know" about devices - all it "knows" about are toolkits.

A good example of this is the OTA launch feature of EclipseME 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.

Collect preverification information

While the new internal preverifier is a step in the right direction, it is still a work in progress. If you encounter errors while using the new preverifier, we would appreciate any information that you can provide to help improve the functionality. If you encounter errors, the more of these troubleshooting steps you can try and questions you can answer the more help your information will be. Until the preverifier has had a bit more time to mature, we would ask that you bring these discussions to the user's mailing list so that all users may benefit from the discussions.

Questions to answer

  • What is the error that occurs when using the code?
  • What emulators or devices does the error occur on?
  • Does the error occur for multiple devices or just one?
  • Does the error occur when using the external preverifier for the device?

Information to provide

  • The answers to the questions above.
  • The source code of the class that is causing the error if possible.
  • The class file of the class that is causing the error if possible.
  • The preverified output of the class that is causing the error if possible.

Check to see if it's already been reported

While any developer would rather that a bug be reported multiple times than not be reported at all, before entering a bug report, please check the current list at SourceForge to see if somebody has already reported your problem or a similar problem. I try to keep the number of outstanding bugs fairly short, so it won't take too long for you to look through, and if somebody has already reported something similar, there may be a work-around.



Copyright © 2005, http://www.eclipseme.org. All rights reserved.