Prototype SSI OpenFeature provider injection - #12192

Motivation

The current Java integration requires customers to add and register the Datadog OpenFeature provider. This does not provide the intended Single Step Instrumentation customer experience.

This prototype tests whether one dd-java-agent.jar can own configuration delivery and install the provider when an application uses OpenFeature.

Agentless is the product-default deployment mode. The source setting remains explicit because it starts request and billing activity.

Changes and Decisions

• Treat an omitted DD_FEATURE_FLAGS_CONFIGURATION_SOURCE as disabled.
• Start the CDN poller when the customer explicitly selects agentless.
• Keep remote_config as an explicit Agent-backed source.
• Add a Feature Flags instrumentation target that is independent from tracing.
• Instrument OpenFeatureAPI.getInstance() for OpenFeature Java SDK 1.20.x.
• Inject the provider and evaluator helpers into the application classloader.
• Install only when the active provider is exactly NoOpProvider.
• Never replace a customer-selected provider.

The customer application needs only the OpenFeature SDK and standard OpenFeature code:

OpenFeatureAPI api = OpenFeatureAPI.getInstance();
Client client = api.getClient("java");

This prototype reuses the current provider to isolate provider injection and source lifecycle behavior. It does not implement the final evaluation-only provider, injected telemetry hook, direct EVP fallback, or offline byte initialization.

The matching dogfood integration is DataDog/ffe-dogfooding#110.

Validation

Manual end-to-end proof used the linked dogfood application and a controlled UFC endpoint.

• The application JAR contained no Datadog OpenFeature provider classes.
• The application JAR contained no OpenTelemetry classes.
• The explicit agentless source made one UFC request.
• The provider reached READY after 34 ms.
• Evaluation returned allocation rollout, variant pi, value 3.1415926, and reason STATIC.
• The same flow passed with DD_TRACE_ENABLED=false.
• The no-source control made zero UFC requests and did not inject the provider.
• The no-source evaluation returned the application default with PROVIDER_NOT_READY behavior.

This validates behavior after Java agent attachment. It does not validate SSI attachment on each serverless platform.