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:
|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
|Deployment||Composer / Packagist||Maven||Drupal 8 already uses composer|
|Master repository||Github||Apache SVN||Not so significant, but...|
|File layout/naming||PSR-0||Non-compliant with PSR-0|
|Class loading||PSR-0 autoloading||
||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|
|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|
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 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.
@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.
@fietserwin: Good catch: I've updated the table to include the licenses (MIT vs Apache).
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.
@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 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.