use SPI to manage components #1412
Conversation
✅ Deploy Preview for opentelemetry-php canceled.
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 2.x #1412 +/- ##
============================================
- Coverage 72.31% 72.07% -0.24%
- Complexity 2729 2758 +29
============================================
Files 401 405 +4
Lines 8148 8200 +52
============================================
+ Hits 5892 5910 +18
- Misses 2256 2290 +34
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 14 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
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.
|
@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 |
in most cases, we can use existing _register.php files rather than using config.spi - this removes some repetition, and means the experience without SPI plugin enabled should be closer to when it is enabled. Merge 3x different _register.php's from SDK into one at the top level.
in most cases, we can use existing _register.php files rather than using config.spi - this removes some repetition, and means the experience without SPI plugin enabled should be closer to when it is enabled. Merge 3x different _register.php's from SDK into one at the top level.
per code review feedback
…metry-php into composer-extra-registry
add SpiLoadableInterface, which is used by factories. Not applied to the factories in Context, due to dependency (Context should not depend on API or SDK)
brettmc
force-pushed
the
composer-extra-registry
branch
from
5fc05ec to
3e80235
Compare
this allows moving all SPI config into _register.php files
|
|
||
| namespace OpenTelemetry\Context\Propagation; | ||
|
|
||
| interface TextMapPropagatorFactoryInterface |
There was a problem hiding this comment.
Should IMO live in the SDK similar to ComponentProvider. It doesn't make much sense to implement the env-based factory w/o also implementing a corresponding component provider.
(Sidenote: would still prefer if we move ComponentProvider as well as an abstraction for env-based factories into SDK independent package(s))
There was a problem hiding this comment.
Moved things around in 0571d3b - WDYT?
reorganise extension propagator factories into SDK, and add a deptrac rule to allow SDK->Extension dependency. Add PackageDependency attribute to the SDK-housed extension propagator factories.
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.