fix: Add system property substitution to declarative config

[MikeGoldsmith]

Summary

Adds support for Java system property substitution in declarative configuration files, extending the existing environment variable substitution functionality. Users can now reference system properties using ${sys:property.name} syntax alongside environment variables.

Addresses #5926

Changes

• Extended pattern matching: Updated regex to support ${sys:property.name} in addition to existing ${VAR} and ${env:VAR} patterns
• Backward compatible: All existing env var patterns continue to work unchanged
• Default values: System properties support :-default syntax like env vars
• Property name support: Allows dots in property names (e.g., ${sys:app.version})

Testing

• Adds unit and integration tests
• All existing tests pass

Example Usage

file_format: "1.0.0-rc.3"
resource:
  attributes:
    - name: service.name
      value: ${SERVICE_NAME}              # env var (backward compatible)
    - name: service.version  
      value: ${sys:app.version}           # system property
    - name: environment
      value: ${env:ENV:-production}       # env var with default

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.20%. Comparing base (fff95e0) to head (b352442).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##               main    #8073   +/-   ##
=========================================
  Coverage     90.20%   90.20%           
- Complexity     7592     7595    +3     
=========================================
  Files           841      841           
  Lines         22911    22926   +15     
  Branches       2288     2293    +5     
=========================================
+ Hits          20666    20681   +15     
  Misses         1529     1529           
  Partials        716      716           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[zeitlinger]

Note: add a comment to open-telemetry/opentelemetry-java-instrumentation#15775 if this is accepted

[jack-berg]

Technically this is non compliant with the spec. The syntax describes "Optionally followed by env:" with no affordance for alternative prefixes.

I would have preferred none of this prefix business at all, but env: allows for compatibility with the collector's syntax, which had a lot of momentum and was stabilizing.

The collector also supports alternative prefixes to substitute from other places besides env vars (things like other files, network locations), AND allows you to do things like substitute entire objects or array (where as declarative config explicitly limits substitution to primitive types). So collector substitution is a superset of declarative config substitution. The motivation behind this was simplicity: since declarative config is going to be implemented 10+ times, we want the implementation burden to be lower.

The question we need to answer in the java is whether system property support is important enough for us to either:

• Not complying with the spec
• Try to update the spec to reflect our use cases

Personally, I don't think spec non-compliance is that big of a deal here. But I also want to be use case motivated. @MikeGoldsmith (or anyone else) have you heard this requested from users?

[trask]

yeah, I think it's good to support both env vars and system properties in the Java ecosystem

[MikeGoldsmith]

I've not heard anything directly that using system properties like this is a hard requirement but I definitely see the benefit for those who prefer them over env vars.

I've opened a spec issue and draft PR to add support for per-language prefixes.

[jack-berg]

Even if we don't add support for the sys prefix, we should add support for env for better interop with collector and other languages.

[jack-berg]

Assuming the java SIG agrees on the direction, I like the implementation. Thanks for working on this.

[jack-berg]

Will leave open for a few days to give other @open-telemetry/java-approvers the chance to object.