Configuration Provider

Purpose and Scope

The ConfigProvider class serves as the integration point between the hypervel/object-pool package and the Hyperf framework. It registers dependency bindings and event listeners during application bootstrap, enabling automatic dependency injection and lifecycle management for pooled objects.

For information about how these registered components function at runtime, see Framework Integration. For details about specific contracts and interfaces, see Contracts & Interfaces.

Sources: src/ConfigProvider.php1-25

---

Overview

The ConfigProvider class implements Hyperf's configuration provider pattern, which is automatically invoked during the framework's service discovery phase. The class exposes a single public __invoke() method that returns an array containing two registration categories:

Category	Purpose	Registered Items
dependencies	Interface-to-implementation bindings for DI container	Factory::class, Recycler::class
listeners	Event listener classes for lifecycle hooks	StartRecycler::class

This configuration is processed by Hyperf's container and event dispatcher during application initialization, before any worker processes start handling requests.

Sources: src/ConfigProvider.php13-24

---

Class Structure

Diagram: ConfigProvider Registration Flow

The above diagram illustrates how ConfigProvider integrates with Hyperf's bootstrap process. The __invoke() method returns a configuration array that Hyperf processes to populate the container and event system.

Sources: src/ConfigProvider.php13-24

---

Dependency Bindings

The dependencies array establishes interface-to-concrete class mappings that enable type-hinted dependency injection throughout the application.

Factory Interface Binding

This binding maps the Hypervel\ObjectPool\Contracts\Factory interface to the PoolManager implementation. Any class that type-hints Factory in its constructor will automatically receive a PoolManager instance from the container.

Usage Pattern:

Recycler Interface Binding

This binding maps the Hypervel\ObjectPool\Contracts\Recycler interface to the ObjectRecycler implementation. This enables the StartRecycler listener to retrieve the recycler service via dependency injection.

Sources: src/ConfigProvider.php16-18

---

Dependency Binding Architecture

Diagram: Dependency Resolution Chain

This diagram shows how interface type-hints are resolved to concrete implementations through the bindings defined in ConfigProvider. The PSR-11 container uses these mappings to perform dependency injection at runtime.

Sources: src/ConfigProvider.php16-18 src/Listeners/StartRecycler.php28-29

---

Event Listener Registration

The listeners array registers event listener classes that respond to framework lifecycle events.

StartRecycler Listener

The StartRecycler::class entry registers the listener that initializes the object recycling subsystem. This listener implements ListenerInterface and listens for the AfterWorkerStart event.

Listener Configuration:

• Event: Hyperf\Framework\Event\AfterWorkerStart::class
• Action: Retrieves Recycler from container and calls start() method
• Timing: Executed once per worker process after initialization

The registration ensures that when Hyperf dispatches the AfterWorkerStart event, the StartRecycler::process() method is invoked, which in turn starts the automated recycling scheduler.

Sources: src/ConfigProvider.php20-22 src/Listeners/StartRecycler.php19-30

---

Registration Flow

Diagram: ConfigProvider Execution Sequence

This sequence diagram illustrates the timing of ConfigProvider invocation and how its configuration is processed. The dependencies are registered during bootstrap, while the listeners are triggered later during the worker start phase.

Sources: src/ConfigProvider.php13-24 src/Listeners/StartRecycler.php26-30

---

Configuration Array Structure

The return value of ConfigProvider::__invoke() follows Hyperf's standard configuration format:

Array Key	Type	Description
dependencies	array<string, string>	Interface-to-class mappings for DI container
listeners	array<int, string>	Event listener class names

Complete Structure:

Sources: src/ConfigProvider.php15-23

---

Integration Points

Diagram: ConfigProvider Integration Architecture

This diagram shows how ConfigProvider serves as the bridge between the package and Hyperf's framework services. The configuration it provides enables automatic dependency injection and event-driven lifecycle management.

Sources: src/ConfigProvider.php1-25 src/Listeners/StartRecycler.php1-31

---

Package Discovery

The ConfigProvider class is discovered automatically by Hyperf through Composer's package metadata. The package's composer.json file declares this class in the extra.hyperf.config section, which instructs Hyperf's configuration aggregator to invoke this provider during application bootstrap.

Discovery Mechanism:

1. Composer installs the hypervel/object-pool package
2. Hyperf scans installed packages for configuration providers
3. ConfigProvider::__invoke() is called during bootstrap
4. Returned configuration is merged into the application's container and event system

This automatic discovery pattern enables zero-configuration installation of the package. Developers do not need to manually register services or listeners.

Sources: src/ConfigProvider.php11-25

---

Summary

The ConfigProvider class provides a minimal, declarative interface for registering the object pool system with Hyperf. Its responsibilities are:

1. Dependency Binding: Maps Factory and Recycler interfaces to their implementations
2. Event Registration: Registers the StartRecycler listener for automated lifecycle management
3. Framework Integration: Follows Hyperf's configuration provider pattern for automatic discovery

All runtime behavior, including pool creation, object management, and recycling operations, is handled by the components registered through this provider. The ConfigProvider itself has no runtime logic beyond returning the configuration array.

Sources: src/ConfigProvider.php1-25