The Adobe Flex framework comes with it’s own logging system out of the box (mx.logging). For the most part, it works fine but is difficult to extend, primarily as a result of the intertwined use of singletons (the anti-pattern). Combine that with a desire to use an IoC framework” (Swiz in our case ) to enhance Flexunit4 testing capabilities, and the need for a new logging framework was justified.So roundpeg has developed our own logging system that meets the following objectives:
- enable multiple local and remote logging targets with independent log levels
- enable multiple log categories with independent log levels that can be configured at runtime
- provide a platform this is fully testable, i.e., not dependent on singletons
- support multiple logging formatters
- create a platform that can be configured using IoC.
The use of Swiz IoC to create all of our components, controllers, delegates, services, etc. lets us define a logger for any class or category is as easy as this simple declaration at the top of the class:
public var log:Logger;
The definition for log category name and log levels are configured in the Swiz Beans class. The creation of the log instance is performed by Swiz at startup time, where logging targets and default log levels are defined. This enables testing to assign a completely separate logging system to the log instance when tests are run.
Log Level UI
The logging framework includes a simple popup to control log levels for targets and categories at runtime. This is handy for debugging in the field or in staging. Here is a screen shot of the log level UI;
Once you have a reference to the loggingController, displaying the log level ui is a one-liner:
ApplicationFactory.instance.loggingController.showUI();
Notice how the logging controller is not a singleton but an actual instance, referenced by ApplicationFactory. The instance is created by Swiz and the targets and log categories are injected in during construction.
Logging Targets
It’s important to support multiple targets from the same logging framework to accommodate all environments. While developing code inside or outside the IDE, a socket logger provides an efficient way to view every logged detail. Socket clients can come in any language, in fact we use Java, Groovy, Air, perl, python, ruby and c/c++ implementations to keep all the developers happy. And if a client is not listening, the socket target defaults to trace statements that get shuffled to a local file when configured for debug statements.
For integration testing and application staging, the best target is a local connection. With the application in one browser and the log view in another browser on the same CPU you can view logs almost as detailed as using sockets. The local connection target also provides a good tool for application administrators and support people by giving them a view inside the application as users are trying to explain application problems.
The third type of logger is a web end-point. This is reserved for light logging during staging and production. So, the typical log level is INFO or WARN but never DEBUG. But when intermittent problems occur, the details are logged to a remote system to help debug complex problems. This has the added benefit of being able to self-escalate problems to support when they occur.
Related posts:
{ 1 comment… read it below or add one }
Hello Darryl,
the description of your logger is very intriguing.
Is it available for free download?