Instrumentation API Config vs autoconfigure ConfigProperties

[trask]

@anuraaga brought up whether we can consolidate these in the SIG meeting today. There's still time, as neither are declared stable (yet).

I looked through previous discussions, and this seems to be the primary issue:

Unfortunately that won't be possible with the current shape of this repo: instrumentation-api only uses OTel API, not the SDK

#3866 (comment)

This does sound like a dealbreaker unless someone has creative solution/ideas?

[mateuszrzeszutek]

There's still time, as neither are declared stable (yet).

ConfigProperties is a part of the autoconfigure-spi, which is actually stable right now.

There was one idea of making Config an interface/abstract class, and keeping the actual implementation in the agent classloader, but I'm not sure whether it's a viable idea: we're using Config way before we get ConfigProperties, and we still need to have a concrete Config implementation for library instrumentation purposes.

One more reason for keeping Config is that it's completely safe, it never throws - it always returns the default value if something goes wrong. Which is probably the behavior what we want in advice/instrumentation code.

[jack-berg]

One more reason for keeping Config is that it's completely safe, it never throws - it always returns the default value if something goes wrong. Which is probably the behavior what we want in advice/instrumentation code.

ConfigProperties has been extended with default getters