App Configuration Spring 4.0 - Draft

[mrm9084]

Description

Updating App Configurations Spring Library to use the 4.0 Spring Design.

Changes

• Changed From azure-spring-cloud to spring-cloud-azure
• Moved Code into implementation folder for revapi
• Cleaned up code, some pre azure sdk code was still around
• Renamed some classes for clarity, none of which are part of the public API
• Feature Flags now have a Selects API similar to configurations
• Feature Flags can now come from multiple sources without issue
• Decoupled Feature Flag and Configuration Property Sources
• Watch Keys aren't loaded if monitoring is disabled on startup

Blockers

• [X] Geo Replication https://github.com/Azure/azure-sdk-for-java/pull/30084
• [X] App Configuration SDK Client Regression, also blocks Geo Replication https://github.com/Azure/azure-sdk-for-java/issues/30536
• [ ] SDK throws uncatchable errors, doesn't actually block but makes catching the issues sub optimal https://github.com/Azure/azure-sdk-for-java/issues/30518
• [ ] Dynamic Features, this feature branch updates the Feature Management code to the 4.0 style. Can't update the starter until both are done. https://github.com/Azure/azure-sdk-for-java/tree/feature/azconfig-spring/DynamicFeature

[azure-sdk]

API change check

APIView has identified API level changes in this PR and created following API reviews.

spring-cloud-azure-appconfiguration-config spring-cloud-azure-appconfiguration-config-web

[check-enforcer[bot]]

This pull request is protected by Check Enforcer.

What is Check Enforcer?

Check Enforcer helps ensure all pull requests are covered by at least one check-run (typically an Azure Pipeline). When all check-runs associated with this pull request pass then Check Enforcer itself will pass.

Why am I getting this message?

You are getting this message because Check Enforcer did not detect any check-runs being associated with this pull request within five minutes. This may indicate that your pull request is not covered by any pipelines and so Check Enforcer is correctly blocking the pull request being merged.

What should I do now?

If the check-enforcer check-run is not passing and all other check-runs associated with this PR are passing (excluding license-cla) then you could try telling Check Enforcer to evaluate your pull request again. You can do this by adding a comment to this pull request as follows: /check-enforcer evaluate Typically evaulation only takes a few seconds. If you know that your pull request is not covered by a pipeline and this is expected you can override Check Enforcer using the following command: /check-enforcer override Note that using the override command triggers alerts so that follow-up investigations can occur (PRs still need to be approved as normal).

What if I am onboarding a new service?

Often, new services do not have validation pipelines associated with them, in order to bootstrap pipelines for a new service, you can issue the following command as a pull request comment: /azp run prepare-pipelines This will run a pipeline that analyzes the source tree and creates the pipelines necessary to build and validate your pull request. Once the pipeline has been created you can trigger the pipeline using the following comment: /azp run java - [service] - ci

[saragluna]

One more thing is the 4.x supports users to configure proxy, HTTP client options, retry, profile, and credential properties to the internal clients.

[mrm9084]

One more thing is the 4.x supports users to configure proxy, HTTP client options, retry, profile, and credential properties to the internal clients.

This can be done using the ConfigurationClientBuilderSetup and SecretClientBuilderSetup which enable modification of clients based on the endpoint.

I've talked with my team and we were thinking about making it so your auto configure options would be the default for all, but keep ours to allow for individual override. Thoughts?