use SPI to manage components #1412
Conversation
✅ Deploy Preview for opentelemetry-php canceled.
|
brettmc
changed the title
brettmc
changed the title
To resolve our long-standing race conditions stemming from using composer's autoload->files to registry SDK components at runtime, this changes things so that: - components are registed in various composer.json files, under the extra.opentelemetry.registry key - a composer script is registered to write this config out to a JSON file - the SDK Registry is modified to make manually registering components a no-op (currently behind a flag, OTEL_PHP_EXPERIMENTAL_JSON_REGISTRY), and instead configure itself from the generated JSON file If we move ahead with this approach, a follow-up PR could tidy up the Registry and remove our various late-binding providers.
brettmc
force-pushed
the
composer-extra-registry
branch
from
ffb28df to
abd9944
Compare
|
An alternative idea if we want to avoid duplicating the "load implementations from The main difference between the solution in this PR and an SPI-based approach is the addition of a name/key for each implementation within the
Transport factory implementationsWe can extend $factories = iterator_to_array(ServiceLoader::load(TransportFactoryServiceInterface::class));
array_multisort(
array_map(static fn($factory) => $factory->priority(), $factories),
SORT_DESC,
$factories,
);
$factoriesByProtocol = [];
foreach ($factories as $factory) {
$factoriesByProtocol[$factory->protocol()] ??= $factory;
}
self::$transportFactories = $factoriesByProtocol;interface TransportFactoryServiceInterface extends TransportFactoryInterface {
public function protocol(): string;
public function priority(): int;
}Factories to initialize the SDK from environment variablesWe could align the implementation with the file-based implementation by adding a new, from the current implementation independent interface2 similar to namespace OpenTelemetry\Config\SDK\Environment;
/**
* @template T
*/
interface ComponentProvider {
/**
* @return T
*/
public function createPlugin(): mixed;
public function name(): string;
}Alternatively we could follow the approach mentioned for transport factory implementations and add a name(/priority) method to the factory interfaces and continue using the Footnotes
|
|
updated to use SPI, and implemented the idea of having factories declare their key & priority. |
|
There was a problem hiding this comment.
One small code-style comment was placed.
I understand that the Registry stuff will not be used when using extra.spi. Is it correct that third-party libraries (in my case, proprietary code/packages within a company) can also add their instrumentation through the SPI way, as shown in composer.json?
It would be nice to pair this with some documentation regardless, e.g. a 'How to add instrumentation into your composer package' section. It would be a good way to demo/reflect/document the preferred way of including AutoInstrumentations.
@xvilo That's right. It's still up for debate exactly how registry/SPI should interact, and which one would be the default. The SPI mechanism will definitely allow custom components like we have now. |
To resolve our long-standing race conditions stemming from using composer's autoload->files to registry SDK components at runtime, this changes things so that: - components are registed in various composer.json files, under the extra.opentelemetry.registry key - a composer script is registered to write this config out to a JSON file - the SDK Registry is modified to make manually registering components a no-op (currently behind a flag, OTEL_PHP_EXPERIMENTAL_JSON_REGISTRY), and instead configure itself from the generated JSON file If we move ahead with this approach, a follow-up PR could tidy up the Registry and remove our various late-binding providers.
add the php-cs-fixer no_blank_lines_after_class_opening rule and apply to codebase
the spec has added in-development otlp file/stdout exporter. We already supported this programmatically, so add some factories and sdk config to allow configuration from environment (only for stdout, per spec)
The event logger was a Development-status component of the logging signal. It has been removed in favour of adding emitEvent to the logger interface, see open-telemetry/opentelemetry-specification#4319
…metry-php into composer-extra-registry
this better represents what the class does now, and it doesn't need to be top-level as it's no longer intended to be user-facing
brettmc
changed the title
brettmc
force-pushed
the
composer-extra-registry
branch
from
934939d to
e33845b
Compare
|
@open-telemetry/php-approvers @Nevay I think this is ready for review: NB that it targets 2.x branch and has some BC breakage, which I've started to document in |
To resolve our long-standing race conditions stemming from using composer's autoload->files to register SDK components at runtime, this changes things so that:
extra.spi_register.phpfiles manually register through SPI, but will be removed fromautoload_filesif SPI is allowed to runIf we move ahead with this approach, a follow-up PR could remove our various late-binding providers.