Logging From JavaScript

24. November, 2011

Logging is a recurring issue in JavaScript. There are a  couple of frameworks which support you. I’ve picked out two:

Some pros and cons:

log4javascript is very powerful. It contains lots of options, it has timers, several appenders (in page or using a popup window), the console supports tons of filters. If you know log4j, you’ll find almost everything replicated. If you need fewer options, there is even a lite version.

Despite the many options, log4javascript is still simple to set up and use (so it’s not like log4j in every respect). The default setup needs 3 lines of code (not counting the script element to load the framework).

There are two minor points: The console is pretty big and the in-page version can’t be moved.

Blackbird is a really small logging framework. No frills, just the basics. So no exception logging, for example. A profiling option is the most complex feature. In the world of the logging frameworks, it’s the iPhone: Nice look and only the useful features. The console is always in page, it sits in one of the four browser corners, it can be hidden and shown with F2.

My main complaint about Blackbird is that you can’t use the mouse to move the console. Also disabling the framework needs several lines of code. A single variable would have been more comfortable.

 


Smart Thoughts About Logging

13. July, 2011

Archanaa Panda wrote a good piece on logging and how to avoid some of the many pitfalls: High Performance And Smarter Logging

While the article is about log4j, most of it (except for the “if (log.isDebugEnabled)” part) still applies even if you’ve already moved to slf4j. I especially like that she enumerates all the various goals that you try to achieve with logging.

 

 


Debugging BIRT: How do I enable logging for OSGi/Equinox?

12. July, 2010

If you ever tried to enable logging for OSGi (Equinox) because starting the BIRT engine fails for mysterious reasons, you will have noticed that BIRT removes all osgi.* options from the System.properties before it launches (see ).

Instead, it expects these options in config.ini (which must be in the current folder):

# Specify the file with the debug options. See the .options file in the org.eclipse.osgi*.jar for examples
osgi.debug=/path/to/file/with/debug.options
# Change the classloader. Possible values are: "app", "fwk", "boot" (default)
# app: Use the current SystemClassLoader
# boot: Use the boot classloader
# fwk: Use the classloader which was used to load OSGi.
#osgi.parentClassloader=fwk

Use fwk if you see errors because of missing XML parser classes. The Java runtime has a private static field which contains the XML parser factory and if you touch any XML code before you start OSGi, then that field will be set and OSGi will be forced to use this XML parser — only the default boot classloader can’t see the parser. Bummer.