In the log4php documentation they configure only a root logger. (see: http://logging.apache.org/log4php/quickstart.html)
<configuration xmlns="http://logging.apache.org/log4php/">
<appender name="myAppender" class="LoggerAppenderFile">
<param name="file" value="myLog.log" />
</appender>
<root>
<level value="WARN" />
<appender_ref ref="myAppender" />
</root>
</configuration>
The above is configuration ONLY for the root logger. Yet they continue in their example:
// Fetch a logger, it will inherit settings from the root logger
$log = Logger::getLogger('myLogger');
What about if I only want the root logger? The fact they overlook this on the Quick Start is mind boggling. Why should I have 2 loggers off the bat, one which they don't even configure (will it break my code if I execute this example? I think so!), and not 1?
So the question remains, how can I use simply the root logger?
Answer:
After my ranging I found the answer in deeper in their documentation (see http://logging.apache.org/log4php/docs/loggers.html) :
Invoking the class static Logger::getRootLogger() method retrieves the root logger.
You found out: Yes, you can only use the root logger. But you would miss an interesting part. So here is why you shouldn't only use the root logger:
Log4php allows you to create any arbitrary logger name. You can log this logger name into the log target if you want, i.e. a line like
2014-06-11 12:15 TheLoggerName Here is the message
is possible.Why would it be interesting? Because it helps adding context to the log message.
One approach is to define some distinct logger names for special logging concerns, like a logger for security messages ("user logged in", "password was wrong", "access violations"), audit trails, database stuff etc.
Another approach is to encode the class name in the logger name. That way you can directly see which class the log message came from, which will help you locate the source of the message. You would simply convert backslashes and underscores to dots, and then have the logger name (assuming PSR-0/4 conforming class names).
And if you are there, it does not matter that you only configure the root logger, because that is where every logged message will eventually end. But it get's better: By doing this you would be able to silence all warning messages from the database classes, but log everything down to debug level from the HTTP client classes, just by altering the log configuration.
It probably will sound like overkill for you to do so, and I can say from experience that in most cases doing a complex configuration is not the thing to do, but being able to do it if needed is better than not being able to do it because there was only the root logger being used. And the part with knowing where the log message came from does pay off instantly if you include the name in the formatting pattern.