remove system property access from library instrumentation

[zeitlinger]

Is your feature request related to a problem? Please describe.

Library instrumentation should not have access to system properties for settings.
Declarative config is the way to go.

Describe the solution you'd like

remove deprecated DeprecatedLibraryConfigPropertiesUtil (added in #15809)

[laurit]

I'm not sure we can do this. Although declarative configuration provides more flexibility and allows expressing stuff that can't be reasonably done with just properties the property based configuration still has its own strengths that may make it attractive for users. Namely the convention over configuration nature of the property based configuration allows users to get running with minimal configuration while the everything must be explicitly configured philosophy of declarative configuration requires users to first craft (read copy-paste from somewhere) configuration file. Also users might not use the auto configuration or declarative configuration at all and set up the sdk programmatically. Can we require that these users switch over to declarative configuration?

[zeitlinger]

Can we require that these users switch over to declarative configuration?

Yes, that's explicitly the goal.
If that creates problems for the users, we'd rather address those instead of having to keep the old system around forever.

@jack-berg anything I missed?

[trask]

property based configuration still has its own strengths that may make it attractive for users

this is definitely true, and I think we have wiggle room in the Java agent distro to map property-based configuration into declarative configuration API (even long-term if we have to though I'm hoping not), but I'm hesitant to support system properties directly in library instrumentation. a middle ground could be @zeitlinger's proposal to publish a bridge that end users of library instrumentation can opt into if they want

[laurit]

In my opinion the short term solution would need to support the system properties/env vars as the current code does and the declarative configuration. Removing system properties/env var support right away is undesirable as that could only be merged for 3.0 which would require us to either merge it into a separate branch or keep the pr open until we are ready for 3.0.

proposal to publish a bridge that end users of library instrumentation can opt into if they want

I suspect that developing utils that allow reading from both configuration sources might give a better result than trying to use the declarative config api for everything.

[zeitlinger]

Removing system properties/env var support right away is undesirable as that could only be merged for 3.0

that's why this issue is tagged as 3.0 - it's not difficult to implement, so we don't need to keep a PR around.

I suspect that developing utils that allow reading from both configuration sources might give a better result than trying to use the declarative config api for everything.

there are two things here

1. use bridging to allow users more freedom
   • we can let uses opt in as @trask said above (publish a bridge that end users of library instrumentation can opt into if they want)
2. what API to use
   • we've moved from using config properties API to declarative config API to make this the default going forward