ConfigProvider & Service Registration

This page explains how the hypervel/log package integrates with Hyperf's dependency injection container and service discovery system. It covers the ConfigProvider class, which serves as the package's entry point for registering service bindings and publishing configuration files. For details about the LogManager class that gets registered, see 2.1. For information about customizing the published configuration, see 3.3. For alternative integration patterns using factory adapters, see 4.2.

Overview

The ConfigProvider class is a standardized integration point used by Hyperf to automatically discover and configure packages. When the application bootstraps, Hyperf scans for ConfigProvider classes and invokes them to gather service registrations and publishable assets.

Service Discovery Mechanism

Hyperf uses Composer's extra metadata to discover package configuration providers. The hypervel/log package declares its ConfigProvider in composer.json:

Sources: composer.json40-43

The discovery process follows these steps:

Step	Component	Action
1	Composer Install	Reads extra.hyperf.config from all installed packages
2	Hyperf Bootstrap	Scans for declared ConfigProvider classes
3	Service Discovery	Instantiates each ConfigProvider class
4	Configuration Loading	Invokes the __invoke() method
5	Container Registration	Processes returned dependencies array
6	Asset Publishing	Registers items from publish array

The extra.hyperf.config key in composer.json points to Hypervel\Log\ConfigProvider, instructing Hyperf to automatically load this class during application initialization.

Sources: composer.json40-43

ConfigProvider Structure

The ConfigProvider class implements a simple invokable pattern, returning a configuration array when called:

Sources: src/ConfigProvider.php9-27

The returned array has two primary keys:

dependencies

Maps interface names to concrete implementations for dependency injection binding. The package registers a single binding:

Interface	Implementation	Purpose
Psr\Log\LoggerInterface	Hypervel\Log\LogManager	Primary logging interface binding

This binding means any class that type-hints LoggerInterface in its constructor will receive a LogManager instance from the container.

Sources: src/ConfigProvider.php14-16

publish

Defines assets that can be published to the application directory. The package publishes one configuration file:

Property	Value	Description
id	config	Identifier for the publishable asset
description	The configuration file of log.	Human-readable description
source	__DIR__ . '/../publish/logging.php'	Source file within the package
destination	BASE_PATH . '/config/autoload/logging.php'	Target location in application

Sources: src/ConfigProvider.php17-24

Dependency Injection Binding

The service registration creates a binding between Psr\Log\LoggerInterface and Hypervel\Log\LogManager. This binding is processed by Hyperf's DI container during application bootstrap:

Sources: src/ConfigProvider.php14-16

The binding mechanism works as follows:

1. Registration Phase: During bootstrap, the container receives the mapping LoggerInterface::class => LogManager::class
2. Resolution Phase: When code requests LoggerInterface, the container resolves to LogManager::class
3. Instantiation Phase: The container creates or retrieves a LogManager instance
4. Injection Phase: The instance is injected into the requesting class

This allows application code to depend on the PSR-3 LoggerInterface without knowing about the concrete LogManager implementation:

Sources: src/ConfigProvider.php14-16

Configuration File Publishing

The publish array defines how the default configuration file is made available to applications. The publishing process is triggered by the Hyperf CLI command:

php bin/hyperf.php vendor:publish hypervel/log

When executed, Hyperf processes the publish configuration:

Sources: src/ConfigProvider.php17-24

The publish configuration structure:

Field	Value	Purpose
id	"config"	Groups related publishable items (allows selective publishing)
description	"The configuration file of log."	Displayed during publishing for user confirmation
source	__DIR__ . '/../publish/logging.php'	Absolute path to source file in package directory
destination	BASE_PATH . '/config/autoload/logging.php'	Absolute path to destination in application

The BASE_PATH constant is defined by Hyperf and points to the application root directory. The config/autoload/ directory is automatically scanned by Hyperf's configuration system, ensuring the published file is loaded without additional setup.

Sources: src/ConfigProvider.php17-24

Bootstrap Integration Flow

The complete integration flow from package installation to runtime usage:

Sources: composer.json40-43 src/ConfigProvider.php9-27

Bootstrap Phases

Phase	Timing	ConfigProvider Involvement
Package Discovery	composer install	Package metadata read, ConfigProvider class path registered
Service Registration	Application bootstrap	__invoke() called, dependencies array processed
Container Binding	Application bootstrap	LoggerInterface bound to LogManager in DI container
Config Publishing	Manual developer action	publish array used to copy configuration file
Runtime Resolution	Request handling	Container resolves LoggerInterface to LogManager instance

The separation between service registration (automatic) and configuration publishing (manual) allows the package to work with default configuration even if the user never publishes the config file. Publishing only becomes necessary when the user wants to customize logging behavior.

Sources: src/ConfigProvider.php9-27

ConfigProvider Class Implementation

The complete ConfigProvider class is minimal but critical:

Sources: src/ConfigProvider.php9-27

Key implementation details:

• Namespace: Hypervel\Log (line 5)
• No Constructor: The class has no dependencies and requires no initialization
• Single Method: __invoke() returns the configuration array
• PSR-3 Import: Uses Psr\Log\LoggerInterface (line 7)
• Static Configuration: All values are hardcoded, no dynamic configuration needed

The simplicity of this class reflects its single responsibility: declaring how the package should integrate with Hyperf. All complex logic resides in LogManager and related classes.

Sources: src/ConfigProvider.php1-28

Service Resolution at Runtime

Once registered, the binding is used throughout the application lifecycle:

Resolution Pattern	Code Example	Result
Constructor Injection	public function __construct(LoggerInterface $logger)	Container injects LogManager
Method Injection	public function handle(LoggerInterface $logger)	Container injects LogManager
Manual Resolution	$logger = $container->get(LoggerInterface::class);	Returns LogManager instance
make() Helper	$logger = make(LoggerInterface::class);	Returns LogManager instance

The binding ensures that LogManager is treated as a singleton—the same instance is returned for all requests to LoggerInterface within the same application lifecycle (per-process for traditional PHP, per-worker for Swoole/Hyperf).

Sources: src/ConfigProvider.php14-16

Relationship with Other Integration Points

The ConfigProvider is one of multiple integration mechanisms in the package:

Integration Point	Purpose	Covered In
ConfigProvider	Service registration and config publishing	This page (4.1)
HyperfLogFactory	Alternative factory pattern for Hyperf-native code	4.2
LogFactoryAdapter	Adapts LogManager to Hyperf's LoggerFactory interface	4.2
logging.php	Default configuration for LogManager	3.1

The ConfigProvider establishes the primary integration path—most applications will use LoggerInterface injection. Factory adapters provide alternative access patterns for specific use cases.

Sources: src/ConfigProvider.php9-27