Sebastian De Deyne has a post to his site that shares some hints on how to track down the dreaded "class log does not exist" error in Laravel-based applications.

Every now and then I come across a Class log does not exist exception in Laravel. This particular exception is thrown when something goes wrong really early in the application, before the exception handler is instantiated.

Whenever I come across this issue I'm stumped. Mostly it's related to an invalid configuration issue or an early service provider that throws an exception. I always forget how to debug this, so it's time to document my solution for tracking down the underlying error.

As Laravel hides the real issue behind an error thrown from the logging class, it's difficult to determine where the problem actually lies. The path to solve this and get to the actual error involves a change to the handle method and using the die method to output both the message and stack trace of the issue before Laravel can try to handle it. Obviously this is only really meant for debugging but can be handy when this error is hiding the real reason for the failure.

In his latest post Stephan Hochdörfer shares a library he's created to hopefully make it easier for developers to integrate PSR-3 compatible logging libraries into their code, a "logging facade" based on an idea from the Java world.

Lately I have seen more and more libraries picking up PSR-3 when it comes to logging. What a lot of libaries do wrong is that they depend on a concrete implementation of PSR-3, e.g. Mongolog instead of relying on the PSR-3 interface. From what I have seen this is because loggers get instantiated directly within the class. This is not a bad thing but it couples your code to a concrete implementation of PSR-3 which in turn means that there`s no interoperability.

The Java community solved the problem by creating a Simple Logging Facade library (SLF4) which I "ported" to PHP last week.

The library makes provides a simple static interface to setting the PSR-3 logger of your choice and fetching it from anywhere in your application. He includes an example of what the code would look like for a basic Monolog instance. He ends the post talking about this method for getting/setting the logger instance and how it compares to using other options like a dependency injection container or even just a manual call to a setter.

On the Qafoo blog today Tobias Schlitt talks about dynamic dispatch, what he calls a "fundamental concept of OOP" to help provide clean, clear interfaces in the code.

I want to use this blog post to illustrate the concept of dynamic dispatch which I use a lot recently to motivate creating clean OO structures in my trainings. In my experience, this helps people to understand why we want to write code in this way. After that I will show why traits are bad in this direction.

He explains the concept of "dynamic dispatch" by starting from the beginning...with procedural PHP code. He looks at the usual flow of this kind of application that call shared functions in a "top down" fashion. He looks at what would happen if new logging needs were introduced (use a new method? patch the current one?) and the dependencies that can be introduced because of it. With this in mind, he continues and talks about how the "dynamic dispatch" happens during the code execution, splitting the log request based on the information it's given instead of different implementations for each. He points out that using a trait doesn't allow for this abstraction and instead embeds the code into the class itself, re-introducing the original problem.

Gonzalo Ayuso as a new post today showing the results of some of his testing with the event dispatcher and Silex to send logs to a remote server.

Today I continue playing with event dispatcher and Silex. Now I want to send a detailed log of our Kernel events to a remote server. We can do it something similar with Monolog, but I want to implement one working example hacking a little bit the event dispatcher. Basically we’re going to create one Logger class (implementing PSR-3 of course).

He includes the sample code defining a "Logger" class that takes whatever message sent to it and pushes it into a given socket resource. He also creates a provider for the logger to implement it in the example and registers it with the event dispatcher. He hooks it into the request, get controller, terminate and exception events. On the other side he uses React to make a basic server to listen on port 4000 for the incoming log data.

With the PSR-3 logging interface recently accepted by the PHP-FIG, Jamie Munro has written up a post for PHPMaster.com that shows how to implement the interface with log4php, the Apache logging tool.

With the recent passage of PSR-3, a standard for a common interface for logging libraries, it seems appropriate to discuss the implementation with my favorite logging library. log4php is an open source Apache project that is a very versatile logging framework. Through log4php’s configuration files, logging has a variety of output locations, so it’s possible to send specific log levels to different output locations.

He includes the Composer requirements for the interface and shares the code for a wrapper class that implements the Logger interface and defines methods for each of the logging levels (alert, notice, debug, etc). Also in the post is an example XML configuration for log4php and how to load it into your class instance.

The PHP-FIG (Framework Interoperability Group) has recently accepted the PSR-3 definition for a standardized Logger interface structure that can be used for interoperability between frameworks (and other tools).

The main goal is to allow libraries to receive a PsrLogLoggerInterface object and write logs to it in a simple and universal way. Frameworks and CMSs that have custom needs MAY extend the interface for their own purpose, but SHOULD remain compatible with this document. This ensures that the third-party libraries an application uses can write to the centralized application logs.

The implementation of this structure into your application makes it easier should you decide to swap out logging tools or want to create your own that can be used across several different frameworks. This is the third PSR to be accepted by the group, following PSR-1 and PSR-2 more related to coding standards.

In his latest post, Stuart Herbert has shared some thoughts about the recently proposed PSR-3 proposal for a unified logging interface for PHP projects.

PSR-3 is a proposed standard (voting has finished, it should appear as an accepted standard when the PSR folks recover from too much Christmas turkey) describing a common logging interface for PHP frameworks. It’s based on a small subsection of RFC 5424, which describes the Syslog standard, which is a very sensible choice. Sysadmins think in terms of Syslog levels, and they utterly hate dealing with loggers that don’t map cleanly onto Syslog.

He briefly introduces the PSR and the format of the logger with some of the main methods it should implement and what they do. He talk gets into some of his critiques about the proposal, namely the method naming, the exception handling parameter and the proposed LogLevel constants.

On the ThinkPHP blog there's a recent post looking at writing a query logger in PHP as a mysqlnd plugin using the mysqlnd_uh extension.

A new approach to implementing a query logger and potentially more complex features such as monitoring or read/write-splitting is the MySQLnd Userland Handler Extension (mysqlnd_uh, pecl website). The extension lets you register a PHP class as a proxy for every MySQLnd connection. Every call to a function to MySQLnd (usually indirect through mysqli, mysql, pdo_mysql) is passed to the PHP class, which then calls the original MySQLnd function.

They give a simple example to start - a logging function and how to configure it - followed by a more real-world scenario of logging inside of a project plugin.

Next up in the phpRiot "Zend Framework 101" series is this new look at the logging component of the Zend Framework - Zend_Log.

This article shows you how to use Zend_Log, the logging component of the Zend Framework. It allows you to record messages from your application however you please. In this article I will show you how to record messages to a log file. Additionally, if you use the Firebug and FirePHP plug-ins for Firefox, Zend_Log can be extremely useful for application development and debugging. I will also show you how to achieve this.

They walk you through the creation of a simple logger and putting it to use by recording just the events you want (via error levels). There's also an extra section on integrating it with the Firebug/FirePHP extensions for Firefox and push your messages directly to the browser.

In a new post to his blog today, Raphael Stolt shows how to take the output from the Zend_Log component of the Zend Framework and, with a bit of custom coding, make it output an RSS feed.

Whilst touring the web I found an interesting project for turning Apache Web Server log files into RSS feeds. This approach can be adjusted to monitor the maintenance needs of a web application deployed on an assumed productive system. Therefor a XML capable Zend_Log instance will be set up and the resulting log file will be transformed into a RSS feed via a custom Action Helper wrapping a XSLT transfomation.

He sets up the XML logger first, using the Zend_Log, Zend_Log_Writer_Stream and Zend_Log_Formatter_Xml to create the XML output from the logging. Then, with the help of the custom helper - Recordshelf_Controller_Action_Helper_Xslt - he reformats the XML output into an RSS feed ready for public consumption. (There's even a screenshot of what it might look like in a feed reader).