Why another logging framework?

Of course we know (maybe better than anyone else) that as3commons is just one of many solutions out there to do logging. For us this question is easy: We want a solution without compromises. Our goal is to provide logging so you never need to think about choosing something else. We took our time and feel confident to have some fine piece of software waiting for you. And here is why:

Performance

When we prepared the release 2.0 of the logging framework we built it from ground up new having one main goal: Become the fastest and smallest logging library.

Doing that is not an easy thing! For an idea of the extent we have thought this through, it is better to go into examples:

• We use the method signature "info(message:*, args:Array=null)" instead of "info(message:*, ...args:Array)".
  In case you have no parameters to pass its about 10x faster since no array has to be instantiated.
• We do not create unnecessary object instances during logging.
  There is no LogEvent class that gets instantiated or polluted. This result in the fact that we need to pass down all properties to targets but its as fast as it gets.
• We do not compare levels!
  A level comparison is quite a bit slower than the null check for a reference. We check each level seperately for its target, therefore we not just have a failsafe but also a very fast way of logging.
• We do not iterate through a list of appenders!
  If you have just one appender (a quite common case) then iterating through a list is overhead. We have a special linked list called MergedTarget that sends out log requests at a very high speed in case you need more than one target to send to.
• Most classes are final.
  Final classes are faster than non final ones. We designed our code that most of the classes you will get in touch with are final and stripped down so much that there is no good reason why you would want to extend them.

And that are just the basics. You can find similar, not always intuitive, performance tricks all over the library.

Size

AS3 projects usually run in the web and not just JavaScript libraries need to reduce their carbon footprint. In fact most ActionScript 3 projects transfer much bigger .swfs through our wires.

We are now at a "silent" configuration size of ~2kb. Other libraries managed to be smaller than as3commons. But we came to the conclusion that it is hard to do that without seriously sacrificing either performance or functionality. Yet we always keep an eye open and if we catch a bit that can be removed here or there, you can be sure it will be gone in the next release.

To keep the codebase small we make a excessive use of "function" and "constant" files. Many ActionScript 3 developers seem not to be aware of it but constant files are actually Singleton constructs. They are smaller than writing function files.

As our most prominent example we have LOGGER_FACTORY. Okay, its a little uncommon to use a constant like this, but: In case someone just wants to use the class LoggerFactory then the singleton logic will not be compiled into the final swf and therefore automatically stripped out.

So: Unless your setup or configuration actually needs a certain part of code, its not included. This helps us keep our library slim and tender!

Super-Easy

Aside from regular access to our loggers, which is very fast and good for developers who know what they do. We also have a simple way to access our logging system.

With calls like info("hi"); you directly have a set of methods that you can use with one measly import org.as3commons.logging.simple.*. This way even designers can use the logging system without bothering too much about performance. And in case you wonder where the log statements are, we even offer a way to display the class/file position for you to find it easily (as it takes quite a bit performance to implement that, its not activated by default).

We also designed the system in a way that no exceptions are thrown and null references should never be a problem. Setups have to work even if you misstyped something or if some connection is dropped or a process returns null. That way you are a little protected against people to make mistakes with it.

Quality to the detail

What is a framework good for if you could write it in 2 minutes by yourself? There are a couple of details that take a long time to do by yourself.

Take for example the FirebugTarget: We not just send out a string over the ExternalInterface. Every property that you assigned in your message string is converted to a object so it stays inspectable for you. It took us a while to get there, and very few (if any?) of our competition actually thought that far.

Aside for well-thought-out implementations, like the former mentioned, we also have a good set of utils that can improve your daily life a lot like the tiny util captureUncaughtErrors(loaderInfo);. Once applied it will send all errors that were not caught by your application to the logging system.

We have a big set of unit tests for many parts of our libraries. However - we are humans and errors happen but if they do we usually answer and/or fix bugs within a day.

Documentation is tough and we are not masters but our asdoc is a lot more thorough than your average flash project. Most classes have meaningful and useful documentation. Take a peek for yourself:Online API Docs

Flexibility in configuration

Our setup process is quite minimalistic yet offers a great deal of flexibility.

Within our setup process we have super-low-footprint setups that just propagate to one specific target. Log4j-like systems can be found in our .swc as well. But to be honest we are much more comfortable with our one process that is far more flexible than this antiquated approach and implemented a regular expression based setup.

Integrations

Outputs
There are many, awesome logging and debugging panels out there. Therefore we decided to not implement our own panel, instead you can choose out of the box in as3commons of the output panel of your choice, may it be MonsterDebugger, Alcon or Arthropod.

Independence
You might wonder why we took the time to implement connectors to so many other logging frameworks. Well the reason is simple. You might use one or another framework right now, and to make it easy for you to catch all those other frameworks we created targets in both directions. That way you can use the configuration in as3commons or in the logging framework of your choice. We already offer connections to all the big players in the flash market like Flex or Swizframework.

Future

Sure, we are not yet were we want to be. There are a lot of ideas how to make this system better. Some of our plan you can find in our issue tracker Future Enhancements I you have any idea or want to help, feel free to contact us.