32 Troubleshooting
So you've compiled, built and tested and the application doesn't work. What do you do next? This chapter covers some of the things to check and some of the techniques that can be used to diagnose problems.
I've built my application but it doesn't run
Run a debug version
The debug build of the XUI libraries output much extra debug and diagnostic information. If you are having trouble with your application the first thing you should consider is using the debug libraries.
The debug log will also summarizes the number or errors and warnings encountered when running the application. The summary is output to the console when the application exits ( this requires a recent JDK ).
The NetBeans log file may also provide additional debug information (they are stored under your user profile), but this should normally be a last resort.
Check the classpath
The classpath is often a source of problems for Java applications. Either a file or resource is missing from the classpath or some other object is loaded instead of the intended resource. Typically such problems manifest themselves as ClassNotFoundException or FileNotFoundException .
If you are using third party resources it is also worth checking the documentation for dependancies as one Jar may depend upon another. Worse still there are sometimes version dependancies (for example on the Servlet jar).
As a fallback and as a way of reducing dependancies you may be able to extract the classes you need from a Jar and use only those classes that you absolutely require. However this is a fairly drastic measure and should be used as a last resort.
Check the case
Remember Java is case-sensitive and even if Windows isn't, your paths may still need to be in the right case. If you are loading resources from Jars then the file names and paths must be in the correct case.
Check the log
Quite often the problem that stops your application running correctly is buried a few layers down. The debug log will immediately show many errors but it may appear that some are unrelated.
An example of this occurs when you try to invoke an event handler. The event is invoked dynamically and if there is a problem finding or invoking the method then a fairly generic error is generated saying that there was a failure invoking the method. While this effectively masks the real cause of the error it should give you enough information to know where to begin debugging.
Debug
If you have the type of problem described above it is usually a good idea to step through your event handlers. You may also want to put a breakpoint on your class's constructor to ensure that it is setup properly.
Since XUI is an open source framework you can also include or reference the source code in your project. With the debug libraries you can then set breakpoints within the library or at the point of any exception. Tracing back along the stack should help you locate and diagnose the problem.
Isolate the problem
If all else fails follow the divide and conquer rule and split your application into smaller parts. Keep splitting until you can isolate the problem and reliably reproduce the problem. Once you know the exact location of the problem finding the exact cause should only be a small step.
Only part of my page is appearing
Check the paths
Sometimes a page can embed other pages (via the include element), files or graphics, these resources must be located by the framework in order to display the application properly. In debug mode the framework outputs the names of the files it attempts to load. Several attempts may be made to load a file from various points on the classpath so you may get multiple warnings about a file not being loaded. In any case if the page is not displaying properly or if images are missing then a good point to start is by checking the log for warnings and errors messages.
Normally a XUI application points to the application's root folder and the pages, resources, and lang folders. The classpath may also point to other folders or Jars. A file should be addressable via the classpath so you may also need to include the part of the path that is not included in the classpath if your resource is located in a child folder (e.g. the path/file reference should be images/myimage.gif for a file such as x:\myapp\resources\images\myimage.gif when the framework runs the application from the x:\myapp\ folder ).
If you have a more elaborate classpath it is also worth checking that you don't have other versions of the file higher up on the classpath. Again checking the debug log will tell you exactly which file was loaded.
Check the build
Sometimes with multiple layers of an application it is possible that parts of your application are not up-to-date. You can do a clean build to resolve some of these issues but you may still have parts of your application that are not compiled or built. With dynamic loading and invocation via reflection a missing component may not be obvious as the cause of a problem. A quick check of the filesystem should reveal anything missing from the build following a clean.
Check the XML is properly formed
Carousel relies heavily on XML and while this is very useful it can provide a source for numerous problems. Carousel itself and XUI allow the XML parser to be replaced and the two can use different parsers so errors can emerge in certain rare situations.
Perhaps the biggest cause of problems is hand-coding of XML. It is very easy to make hard to locate errors in XML when hand-coding. Even something so simple as a missing space or a missing quotation mark can lead to parsing errors. Ultimately these parsing errors can lead to failures or partial failures such as pages only appearing in part.
To rectify these problems first off avoid using editors like notepad as they don't provide any explicit support for XML. There are several excellent XML editors available and many are available as free open source applications. As a minimum you should be able to check that the XML is well formed.
Next you should follow the divide and conquer approach and comment out sections of the offending XML file till you locate the section that causes the fault. Java is case sensitive and therefore it is important that elements, attributes and values are spelled correctly and are in the right case.
Finally, even if you don't want to use Carousel's built-in editors you should be able to use Carousel to build a sample or fragment of what you are trying so as to check the syntax. once you have the right syntax and structure you can modify the fragment to your needs and simply paste it into your own file.
The 3d effect on buttons is missing
Check the Look and Feel.
Depending upon the look and feel you have chosen for the application buttons and other controls will have different appearances. Some look and feels allow more customization than others. In the default look and feel (and on later JDKs) setting the style on a component such as a button will override the default settings. The run-time appearance may then be significantly different from that shown within the editor since the editor does not modify the look and feel.
If you want something closer to the look and feel used within the editor you can choose the Windows look and feel within the editor (for Windows systems; on other systems you will have to set the LAF explicitly). The Windows LAF preserves the 3D appearance of components such as buttons. For more information see "Setting the system look and feel" on page 114
If you were logged in you could rate this article or add a comment.
