[DOCS-15222] Document Java agentless Feature Flags delivery - #38518
[DOCS-15222] Document Java agentless Feature Flags delivery#38518leoromanovsky wants to merge 9 commits into
Conversation
|
/review |
There was a problem hiding this comment.
🤖 Automated review by Claude. AI-generated; verify before acting.
Reviewed the Java Feature Flags updates and the surrounding pages that reference Java support. Findings are minor clarity/consistency issues — nothing blocking. See inline comments.
Reviewed ad0ff38485ded74706b1e47509b919e007eb5161 — workflow run
janine-c
left a comment
There was a problem hiding this comment.
Looks great! I have some minor writing notes, but nothing urgent. Let me know if you have any questions, and let me know if you need anything else!
aarsilv
left a comment
There was a problem hiding this comment.
Thanks for doing this! Approving with a few comments you can take or leave
| - A Datadog [**API key**][7] | ||
| - Your Datadog [**site**][14] | ||
|
|
||
| Use the same version of `dd-java-agent` and `dd-openfeature`. Agentless delivery does not require a separate Datadog Agent service. |
There was a problem hiding this comment.
Should this be use a minimum version? What if dd-java-agent is upgraded but we haven't made any changes to dd-openfeature?
There was a problem hiding this comment.
I mention the minimum version 1.65.0 (next minor) in a few places; they are published w/ the same tag.
There was a problem hiding this comment.
Use the same version of
dd-java-agentanddd-openfeature
I was wondering if this may make people think dd-java-agent and dd-openfeature must always be the same version as each other.
There was a problem hiding this comment.
I see - for this release specifically yes agent just needs to be bumped to 1.6.5.
In the serverless docs (https://docs.datadoghq.com/serverless/guide/datadog_forwarder_java/), they encourage people to always download latest Java agent, or rather don't really mention a pinned version.
Overall it is a positive thing for us if people DO keep the versions in sync, for example in the next release we'll add exposure forwarding through the Java agent and I want them to upgrade to it.
| 5. Confirm that application code initializes the Datadog OpenFeature provider. | ||
| 6. Confirm that `DD_API_KEY`, `DD_SITE`, and `DD_ENV` are configured in the application process. | ||
| 7. Confirm that the application can make outbound HTTPS requests to Datadog. | ||
| 8. Enable `DD_TRACE_DEBUG=true` and check for authentication, timeout, or malformed-payload messages from the Feature Flags agentless endpoint. |
There was a problem hiding this comment.
Should we add something like during the migration window confirm DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED is no longer set
There was a problem hiding this comment.
The client will log when there is bad configuration: https://github.com/DataDog/dd-trace-java/blob/9a23583a981ef90d386299f9be3d54b6eb1dec3d/products/feature-flagging/feature-flagging-agent/src/main/java/com/datadog/featureflag/FeatureFlaggingSystem.java#L74
Motivation
Java 1.65.0 adds default CDN delivery for
dd-openfeature. Direct delivery simplifies onboarding for long-running servers and supports serverless runtimes that cannot connect to a Datadog Agent.Java must still load
dd-java-agentas a JVM agent. Remote Configuration also requires a reachable Datadog Agent. Customers need clear requirements for both components and delivery sources.Changes and Decisions
dd-openfeatureanddd-java-agent.-javaagentandJAVA_TOOL_OPTIONSrequirements.Validation