PSR-3 gives PHP libraries a common logger contract; it does not, by itself, make Apache log4php a PSR-3 implementation. Before wiring the two together, verify the exact log4php version used by your project. If it does not implement PsrLogLoggerInterface, use a wrapper that maps the contract to log4php’s API.
What is PSR-3?
PSR-3 is a PHP-FIG standard for a shared logging interface. Its goal is to let libraries accept a PsrLogLoggerInterface and write to an application’s centralized logging system without depending on a particular logger. The standard defines the contract; a logging framework supplies the implementation. See the PSR-3 specification.
Apache describes log4php as a PHP logging framework that began as a port of Log4j and developed PHP-specific features. That description does not establish whether a particular log4php release implements PSR-3. The Apache project index is at Apache Logging Services.
What are the PSR-3 log levels?
LoggerInterface defines eight level-specific methods and a generic log method:
#1 Best Overall
- Used Book in Good Condition
| Level | Method |
|---|---|
| Emergency | emergency() |
| Alert | alert() |
| Critical | critical() |
| Error | error() |
| Warning | warning() |
| Notice | notice() |
| Informational | info() |
| Debug | debug() |
| Generic dispatch | log($level, ...) |
Calling log with one of the standard levels must produce the same result as calling that level’s method. If the logger receives an unknown level, it must throw PsrLogInvalidArgumentException. These are interface obligations, not assumptions to make about log4php’s similarly named levels or methods.
How do PSR-3 messages and context work?
A message must be a string or an object with a __toString() method. An implementation may handle particular objects specially; otherwise, it must cast the message to a string. The message can contain placeholders, with matching keys in the context array. Placeholder syntax is exactly {name}: the key name goes inside one opening and one closing brace, with no whitespace inside.
Keep the message template static and put changing values in context. PHP-FIG’s PSR-3 meta document explains that this supports translation and avoids forcing the logger to assume how context should be escaped for a particular output format.
Context may contain arbitrary data. The standard does not require every logger to interpolate every value into the message. If a logger uses the context entry named exception to produce a stack trace, it must first verify that the value is actually an Exception. Do not assume that any value under that key can safely be treated as one.
Rank #3
Does log4php support PSR-3?
Do not infer PSR-3 support from log4php’s name, its Log4j origins, or similarities between logging levels. The available Apache project description establishes that log4php is a PHP logging framework, but does not establish its current release, API, maintenance status, Composer constraints, or native PSR-3 compatibility. Confirm the behavior of the exact installed release before writing an integration.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to implement PSR-3 with log4php
- Identify the installed version. Check the project’s Composer lockfile and the release documentation or source for that exact version. Do not use Apache Log4j documentation: Log4j is a separate Java project, and log4net is a separate .NET project.
- Check the interface contract. Confirm whether the installed log4php class implements
PsrLogLoggerInterface. If it does, verify its behavior against all eight level methods, generic dispatch, unknown levels, context, and exception handling. - Choose native use or an adapter. If the framework class does not implement the interface, create a wrapper that implements
LoggerInterfaceand delegates to log4php. Do not type-hint the framework as a PSR-3 logger until compatibility is confirmed. - Map every level and edge case. Ensure each PSR-3 method reaches the intended log4php level; make
logdispatch consistently; and reject unknown levels withPsrLogInvalidArgumentException. Preserve context, and only treat a context value as an exception after checking its type. - Test with the project’s installed dependencies and configuration. Confirm that the adapter loads with the installed
psr/logversion and that log4php routes entries as intended. A correct interface mapping does not by itself configure appenders, destinations, or formatting.
PSR-3 provides AbstractLogger and LoggerTrait to reduce repetitive forwarding methods when building a logger: each leaves generic log as the core implementation point. Using the trait still requires explicitly implementing LoggerInterface. These are PSR-3 tools, not evidence that log4php includes native support.
Quick Recap
What to verify in a wrapper
- Contract: the wrapper implements the installed
PsrLogLoggerInterfaceand exposes all eight level methods pluslog. - Dispatch: generic calls for standard levels match their dedicated methods; unknown levels raise the required exception.
- Messages and context: string and stringable messages work, and context is not discarded or interpolated in a way that breaks the intended output handling.
- Exceptions: trace handling checks that
context['exception']contains an Exception before using it as one. - Configuration: the adapter delegates into the configured log4php instance, while destinations and formatting remain the framework’s responsibility.
- Dependency compatibility: the interface version required by the project matches the installed
psr/logpackage and the code in the selected log4php release.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
