Testing and debugging an application go hand in hand. The basic requirement to debug is to receive or view in real time messages from the system regarding the state of the execution stack. From logging simple messages to viewing the state of the execution stack, this chapter will help you debug and test both on the client side and the server side of development.
Logging Overview
There are two areas of logging in an application’s life cycle. The first is application- and compiler-generated messages, and the second is developer-created messages. To be effective in debugging and testing, you need to learn both areas and how they overlap. Most logging is something that is done during development, and should be disabled when put into production, but that doesn’t mean certain critical messages shouldn’t be taken out of live production applications.
If you are using the Flex server for compiling Flex applications, the compile-time errors will be output to the server’s standard out stream, either a console or log file, depending on your J2EE application server. The Flex server uses a specific version of the Apache Group’s log4j tool, which can cause errors if another log4j is found in the classpath. To debug, and not just watch log messages line by line for a Flex application, the Flex Builder or fdb debugger is required.
| Tip | A common problem is defined in the “Log4j error on Flex startup” Adobe Flex TechNote, located at http://www.adobe.com/go/tn_19249.
It is important to note that if you deploy an application with standard Flash trace() method calls, anyone who views your SWF application with a Flash Debug Player can view the log messages. |
The following sections touch on what, when, and how logging works for Adobe Flex applications.
