Add Monolog Symfony-Bridge to Drupal

This is just an "Add library so patches work" issue, which we've generally commited with a "we can easily pull it out if we end up not using it" caveat. So, let's do that and unblock #1289536: Switch Watchdog to a PSR-3 logging framework

I'm really not convinced by this route: watchdog() previously, and Monolog on its own, expose a much richer interface than the Symfony LoggerInterface, which is basically just made of one method set: <level>(<message>, <context>)

In comparison, watchdog() exposes a richer interface: watchdog(<channel>, <message template>, <message arguments>, <level>, <context>. It has just one method, but more cleanly identified parameters, which lend themselves cleanly to event i18n and aggregation in reports (think of the current mongodb_watchdog UI, or tools like kibana: much easier to use if logged content is structured).

Of course, we can serialize the whole set of structured information in $context just to shoehorn it to the Symfony LoggerInterface, then add a Monolog Processor in the Logger-Handler chain, just to restore the structured data to that native rich handlers can store structured information instead of having just unstructured data to log, but that seems a pointless waste of resources. I think it would make better sense to use a native integration between Drupal and the Monolog: its main entry point, Logger::addRecord() already includes the level parameter, and the channel separation can be replicated efficiently by instantiating multiple Loggers with separate configurations: according to Monolog docs, a Logger is just that, a channel.

We could then expose the more limited LoggerInterface on top of the default logger, for the sake of Symfony code requiring that interface.

Resetting to CNW for these reasons.

Regarding the patch itself the ClassLoader::findFile() changes appear to be due to composer code generation, but:

• they do not fix the fact that passing findFile('') or findFile('\\') will throw an warning instead of just failing to load the class. It's a stupid case, but it should not cause a php notice anyway
• are inconsistent between code and phpdoc: the phpdoc says the function returns path|null, but it returns path|false if passed '' or '\\' or a non loadable class name. Since the is no case return null, the one to chane is the phpdoc

FWIW, the error mentioned above about the classloader is not present in the original code of the Symfony UniversalClassLoader, but a consequence of the loader changes in Composer. I'll pursue this on composer, not here.

OK, I reviewed it in more detail, and I withhold my earlier objections.

The composer issue is being addressed within composer.

FWIW, I've continued my series on other logging solutions on my blog (log4j, kohana...), to explain why we're bringing in Monolog rather than another solution.

No if we're going to do this at all, let's use the Monolog interface which has feature parity with watchdog() currently. The fact it didn't is the reason I originally rejected it a year or more ago.

There are some places in core that Symfony's logger interface might need a bridge so that Symfony code can actually log, but that's no reason to hamstrung everywhere else.

#10: 1810664.patch queued for re-testing.

13: 1810664.patch queued for re-testing.

Postponed in accordance with #20.

unblocked.

I think we can won't-fix this now, no? We have a home-grown PSR-3 compatible logging system now. Some parts of it at least could be swapped out with any PSR-3 library. I don't think it's still in scope to rip it back out in favor of Monolog at this point, much as I'd like to have less home-grown code.

One thing we should make sure of is that we can actually swap the logger as wished, probably like we swap the database for the mongodb version using service tags.

I was just cleaning up the Postponed tag on D8. Lots of stuff got forgotten there. I'm fine with closing this, but wanted to get it out of limbo.

Crell asked me to look at this figure out whether it's won't fix or not. If the PSR-3 logger is implemented properly, then we can add monolog from contrib. If it's not that's a bug but would be a separate bug report to this issue.

Adding the library and refactoring core to use it could be done in a way which doesn't break bc or cause much disruption (although would need to figure out what to do with contrib logging modules in use on sites etc. which starts to get tricky).

If that's correct and we thought it was worth doing (not sure on that bit), then it'd be possible to do this in a minor version. See #2350615: [policy, no patch] What changes can be accepted during the Drupal 8 beta phase? for the long version of that answer.

Going to tag minor version target and bump to 8.1.x for now.

The services that are using a PSR-3 logging interface would port easily. However, some are using the logger factory directly instead. Those would need to be modified as that's a Drupal-specific interface.

Well, the logger factory should be swapped out anyway, to return Monolog\Logger objects instead of Drupal\Core\LoggerChannel objects, so that shouldnt be a problem at all. Where i see the problem is:
The mess with log levels.

• PSR3 uses strings
• Drupal core uses RFC 5424 ints
• Monolog uses ints but 100-600

#2267545: Standardize to RFC 5424 log levels

Though, Monolog plans to also switch to RFC in 2.0, which will make things easier..I would say, that would be a good point to pull Monolog in since it would require less changes

Moved to dblog.module for future triage.

I reviewed the code of Monolog (it has a stable version since 1 year now) and it seems everything necessary to support it is already in place.

I'm closing this issue since the bridge proposed is already in place.