Broadcast ConfigChangeEvent using Spring ApplicationEvent

[nobodyiam]

What's the purpose of this PR

Broadcast ConfigChangeEvent using Spring ApplicationEvent so that it's easy to customize the logic to handle config changes.

Brief changelog

• Add ApolloConfigChangeEvent class
• Refactor PropertySourcesProcessor to publish ApolloConfigChangeEvent when config changes

Follow this checklist to help us incorporate your contribution quickly and easily:

• Read the Contributing Guide before making this pull request.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Write necessary unit tests to verify the code.
• Run mvn clean test to make sure this pull request doesn't break anything.
• Update the CHANGES log.

[codecov-commenter]

Codecov Report

Merging #4305 (343fcf9) into master (a42b793) will increase coverage by 0.03%.
The diff coverage is 100.00%.

❗ Current head 343fcf9 differs from pull request most recent head 7232497. Consider uploading reports for the commit 7232497 to get more accurate results

@@             Coverage Diff              @@
##             master    #4305      +/-   ##
============================================
+ Coverage     53.17%   53.21%   +0.03%     
- Complexity     2668     2673       +5     
============================================
  Files           488      489       +1     
  Lines         15253    15267      +14     
  Branches       1577     1576       -1     
============================================
+ Hits           8111     8124      +13     
  Misses         6587     6587              
- Partials        555      556       +1     

Impacted Files	Coverage Δ
...apollo/spring/config/PropertySourcesProcessor.java	96.49% <100.00%> (+0.12%)	⬆️
...pring/property/AutoUpdateConfigChangeListener.java	92.72% <100.00%> (+0.72%)	⬆️
...ork/apollo/spring/spi/ApolloConfigChangeEvent.java	100.00% <100.00%> (ø)
...spring/spi/DefaultApolloConfigRegistrarHelper.java	75.75% <100.00%> (+1.56%)	⬆️
...i/DefaultConfigPropertySourcesProcessorHelper.java	100.00% <100.00%> (ø)
...ervice/service/ReleaseMessageServiceWithCache.java	84.70% <0.00%> (-1.18%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a42b793...7232497. Read the comment docs.

[misselvexu]

Why not consider implementing the configuration auto-refresh mechanism based on EnvironmentChangeEvent ?

[nobodyiam]

Why not consider implementing the configuration auto-refresh mechanism based on EnvironmentChangeEvent ?

This is an interesting idea.
The reason why we don't use EnvironmentChangeEvent is the refactored piece of codes should support all Spring scenarios, not just Spring Cloud.
However, one thing that might make sense is we use the ApplicationEvent mechanism to publish the config changes, e.g. publisher.publishEvent(springConfigChangeEvent), which would be more natural in Spring environment.

[misselvexu]

Why not consider implementing the configuration auto-refresh mechanism based on EnvironmentChangeEvent ?

This is an interesting idea. The reason why we don't use EnvironmentChangeEvent is the refactored piece of codes should support all Spring scenarios, not just Spring Cloud. However, one thing that might make sense is we use the ApplicationEvent mechanism to publish the config changes, e.g. publisher.publishEvent(springConfigChangeEvent), which would be more natural in Spring environment.

Thank you for your answer, that whether to consider separating the client sdk, such as java version, spring version, spring boot version, spring cloud and so on version of the sdk.

[nobodyiam]

Why not consider implementing the configuration auto-refresh mechanism based on EnvironmentChangeEvent ?

This is an interesting idea. The reason why we don't use EnvironmentChangeEvent is the refactored piece of codes should support all Spring scenarios, not just Spring Cloud. However, one thing that might make sense is we use the ApplicationEvent mechanism to publish the config changes, e.g. publisher.publishEvent(springConfigChangeEvent), which would be more natural in Spring environment.

Thank you for your answer, that whether to consider separating the client sdk, such as java version, spring version, spring boot version, spring cloud and so on version of the sdk.

We already had such discussions that ultimately there might be 3 java SDKs: apollo-client, apollo-client-config-data, spring-cloud-apollo-client(this name is not finalized).

[nobodyiam]

@misselvexu @gy09535

I have updated the logic to broadcast the config change event using Spring ApplicationEvent, which should be more natural and easy to customize. Please help to take a look.

[lepdou]

LGTM