Quick news

  • 2014-03-27: MongoDB Watchdog module ported to Drupal 8 at the Szeged Dev Days.
  • 2014-01-26: My post on the Symfony web profiler in Silex selected in Week of Symfony. w00t !
  • 2013-10-18: My first commit went into MongoDB today. And, guess what ? It's in JavaScript
  • 2013-09-20 to 29: Working on Drupal 8 EntityAPI at the extended code sprints during and around DrupalCon Prague
  • 2012-08-19: Working on Drupal 8 EntityAPI at Drupalcon Munich
  • 2012-06-15: Working on Drupal 8 EntityAPI at DrupalDevDays Barcelona
  • 2012-03-23: Working on the future Drupal Document Oriented Storage at DrupalCon Denver. D8 or later ? Bets are on Later

Rethinking watchdog(): Monolog vs log4php

Beyond Monolog, other packages provide advanced logging services. Apache log4php is another well-known logging solution, used (among others) by CMS Made Simple, SugarCRM, and vTiger CRM.

It is based on the famous log4j package from the Java world, and from uses of this package I have seen on customer sites, I feel that it carries a lot of useless baggage, and is - in my opinion - significantly less of a good match than Monolog for Drupal 8.

Monolog vs log4php : equivalences

There is some degree of equivalence between the Monolog and log4php components:

Purpose Monolog log4php Notes
Log an event Logger Logger Very similar
Store an event Handler Appender both can be chained, group, control bubbling (Monolog) / filtering (log4php)
Format an event representation Formatter Layout log4php layouts can format a group of events, Monolog formatters format an individual event
Massage event data Processor Renderer Not so similar. Monolog processors will often add extra data, while log4php Renderers are typically used to format non-string events as strings.

Monolog vs log4php : other points of comparison

Topic Monolog log4php Notes
Deployment Composer / Packagist Maven Drupal 8 already uses composer
Master repository Github Apache SVN Not so significant, but...
Namespace use Yes No
File layout/naming PSR-0 Non-compliant with PSR-0
Class loading PSR-0 autoloading require() instructions in package Would need tweaking our loading process
Configuration Nothing specified: use code XML, PHP, info This is probably the strongest argument for log4php
Langages used PHP PHP, XML, DTD, XSLT, YAML The non-PHP languages in log4php are mostly about integration and configuration
Repo size 4k LoC 27k LoC The log4php repo embeds lots of JavaScript libraries for its site. Monolog only has limited documentation as Markdown files.
Actual size: code + tests 3.7k LoC 7.8k LoC 0.4k lines of XML, DTD, XSLT, YAML in log4PHP
Actual size: code 1.7k LoC 3.7k LoC Less than 100 lines of non-PHP code(DTD) in log4php
Testing PHPUnit, with Mock objects PHPUnit, with Mock objects
Loggging destinations provided Amqp, ChromePHP, Cube, FirePHP, Gelf, MongoDB, Null, RotatingFile, Stream, [Native|Swift]Mailer, Syslog, Test Console, Echo, [Daily|Rolling]File, Mail[Event], MongoDB, Null, PDO, PHP trigger_event, Socket, Syslog Monolog Stream subsumes log4j Console, File, and Socket. Soon in Monolog: logstash Handler. My D8 patch for Monolog includes a DBTNG (PDO) Handler.
License MIT License Apache License, version 2.0

License

It may be a good idea to add the license(s) under which the software is distributed: GNU lesser GPL (Monolog) vs Apache (log4php) based on a quick Google search without even clicking through.

I'm not sure what your

I'm not sure what your argument is here, though the data is nice. The fact that Monolog can be imported by composer, is relatively small, and is PSR-0 compliant basically ensures that it will be chosen over log4php.

Make sure we're doing the right thing

@Cweagans: that's part of the idea: having seen log4php in some biggish projects, I want to make sure that once we include Monolog, as I've been pushing for, developers in such environments will have reasonable argument to justify that choice to customers who would have mandated log4php.

More generally, this series is about exposing why I've chosen to be promoting Monolog for Drupal 8 since this spring, to make sure we make the proper choice by bundling it in D8, showing that it is not just a whim.

Licenses added to the comparison

@fietserwin: Good catch: I've updated the table to include the licenses (MIT vs Apache).

license compatibility

MIT license isn't actually a thing, there are several licenses that are incorrectly mislabelled as "The MIT license" unfortunately none of which are compatible with the GPL (and thus the code is not able to be included with Drupal core). The APL is compatible and so the code could be included. However a few other projects (notably jQuery) have created a dual license with the GPL so that they could be included with Drupal.

Link license included

@dalin: indeed, that's why I've included the link to the actual license text for both projects. Also, this is how Seldaek choses to label the license under which it put Monolog.

Which probably means we may have a legal tag to add to the monolog issue on d.o.

Monolog is fine, legally

Monolog is using the "real" MIT license, which is the same license used by Symfony, which is completely GPL compatible. We're good there.

Apache 2 is not GPLv2-compatible so if that's what log4php is using, it's off the table right there.