Drupal does logging via watchdog() and a module hook. That makes it only useful post-full-bootstrap when we have hooks.

Symfony, or at least the kernel, has a logging object (with interface) that it passes to many objects optionally. If things happen that need to get logged, it calls $logger->info() (and similar), which, because it's an interfaced object, can do whatever it wants behind the scenes. Right now we are not leveraging that anywhere.

We really ought to merge these. :-)

Option 1: Write a new logger class that internally wraps watchdog(). It takes whatever was called against the object and turns it into a watchdog() call. We then pass that object to wherever Symfony has one, and all is right with the world.

Option 2: Write a new logger class that does what we want, and make watchdog() a trivial wrapper of it. If we want it extensible then we can likely use a listener, as those should be available earlier than hooks. We can then transition over from watchdog() to logger objects (which we could even still call a watchdog object if we wanted to, for old time's sake) as stuff is refactored, and stick the logging object into the DIC so that everything is cleanly injected.

I personally prefer option 2, because it gets us further along toward an all-injected world and keeps watchdog() function calls out of objects; it's a hard-dependency to avoid. It's the more forward-thinking approach. That requires figuring out the registration of additional listeners, but we need to do that anyway.

Comments

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

FWIW, I will be working on this: I already discussed it with amateescu a few days ago, and have some work on watchdog and its implementations, as well as using Monolog (outside Drupal/Symfony).

Crell’s picture

Crell commented

fgm: Spiffy. Are you looking at this from an approach 1 or approach 2 angle? And how does Monolog fit into the picture?

anavarre’s picture

anavarre
Primary language French
Location 🇪🇺
commented

FYI, see also #1408208: Enable users to determine which types of log messages get written to dblog/syslog. Right now it's all or nothing.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

Actually, I was thinking more along the lines of #2, except not specifically wanting to create a new Logger class from scratch, but using Monolog, which I like quite a lot, and already has a wrapper (bundle) in Symfony. Here is how I see it:

  • step 1: bring in a logger, probably Monolog, and take its configuration (streamhandler) from config. Write a hook_watchdog implementation that logs into it. At this point, this is just something a contrib could do
  • step 2: add the logger info into the dic, update code invoking symfony classes to pass them the logger instance shared with the hook_watchdog() implementation so that class-based code no longer needs to call watchdog, but can use the logger interface directly now that it receives one
  • step 3: incrementally replace the calls to watchdog by direct calls to the logger methods.
  • step 3bis: can be in parallel with step 3: convert existing hook_watchdog() implementations to stream Handlers
  • at some point during this, not sure which currently, replace the hook_watchdog mechanism itself by the chain of dispatches allowed by the stream processor / handler mechanism, so that, for instance, a site could have a syslog handler receive all message, then filter only messages above Warning for further handlers, allowing something like dblog to be used even in production for its convenience, because it would only receive serious messages, while faster handlers could still recevie the whole flow of messages, down to Debug level.

The main issue I'm worried about, at this point, is internationalization of watchdog messages, which currently relies on separate storing of messages class (the message column) and arguments, being merged by t(), whereas Monolog (for instance) does not provide this. The "extra" column which could store arguments only receives data from Processor classes, not from the Logger addRecord(). Of course, Monolog is only one option, The $context passed in all LoggerInterface can probably be used for this.

Another issue with Monolog would be the licensing, and I'm not sure what we would want to do about it: it is currently licensed by default under the "MIT" license (which version is not clear), not the GPL. Assuming this means the X.11 license, it is compatible with the GPLv2 or later, but this should be clarified with the author (Jordi Boggiano aka Seldaek). Not to be confused with the old similarly named Monolog library for Java by OW2, which was licensed under LGPL2.1.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

@anavarre: this is also related to one of my previous patches on that topic: #1268636: Watchdog should ignore reports below the system reporting level.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

Yesterday at DrupalCamp Lyon, I did an impromptu presentation/discussion about the current watchdog() implementations, Symfony2 Logger interface, Monolog, and the envisioned implementation, what it brings us over the current situation (basically, it should be faster in many situations, and generally more useful), and discussed use scenarios for such an improved logging mechanism.

If you can make sense of them, @noisetteprod took a few shots of my whiteboard explanations: http://twitpic.com/9pxy8m http://twitpic.com/9pxyaj

Crell’s picture

Crell commented

I couldn't make heads or tails of the pictures, but yay for discussing things. :-) If I understand it, the plan in #4 seems sane. It sounds like implementing option 1 first, then migrating it to option 2 piecemeal. Is that correct? My main question is timing. Would we have development time to do that, or we end up caught part way through the migration when code freeze happens? That would suck. :-)

The MVP for me in this case is that any Symfony class that has a logger object parameter gets one, and we can do the same for any other object we spawn from the DIC. I'd want us to get to that ASAP.

MIT license is what Symfony2 uses, so is OK to include. Jordi is a Symfony dev as well.

catch’s picture

catch
he/him
Primary language English
commented

There's already an issue somewhere for porting watchdog to a class, along with some discussion of monolog. Let's please merge this one in either direction.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

Would that be #1289536: Switch Watchdog to a PSR-3 logging framework, or is there another one ? I hope to discuss a bit with jordi/seldaek at Symfony live next week, if he is available, since I've a pending pull request on Monolog too.

catch’s picture

catch
he/him
Primary language English
commented

That's the one yeah. I'm typing from phone so I won't try to mess with issue statuses, thanks for digging it out!

catch’s picture

catch
he/him
Primary language English
commented
Status: Active » Closed (duplicate)

Marking this as duplicate of #1289536: Switch Watchdog to a PSR-3 logging framework, we can continue over there.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

For the record, we had a discussion at Symfony Live with Crell and Seldaek, including my current D8 code and Monolog patches, of which I expect to have a first showable version during the Barcelona DevDays, as a basis for work.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

Also, at DC Munich, @skottler mentioned existing code in the d.o. infra which probably needs to be considered too:

http://munich2012.drupal.org/program/sessions/turning-every-log-entry-go...