Spring Cloud Hoxton is trying to support both 2.2 and 2.3 simultaneously.
19699 removed some deprecations which will cause problems.
So far the items I've found that do not have replacements are:
org.springframework.boot.context.properties.ConfigurationBeanFactoryMetadata.org.springframework.boot.actuate.health.CompositeHealthIndicatororg.springframework.boot.actuate.health.HealthAggregator
It was a smaller list than I initially feared. I'll double-check that those are all of them.
Comment From: scottfrederick
Just going by deprecation comments:
org.springframework.boot.context.properties.ConfigurationBeanFactoryMetadatawas replaced byorg.springframework.boot.context.properties.ConfigurationPropertiesBeanorg.springframework.boot.actuate.health.CompositeHealthIndicatorwas replaced byorg.springframework.boot.actuate.health.CompositeHealthContributororg.springframework.boot.actuate.health.HealthAggregatorwas replaced byorg.springframework.boot.actuate.health.StatusAggregator
Of course this doesn't mean that all the methods and features of the classes that were removed have replacements that work for Spring Cloud. If you can provide some details on how the removed classes are used, or which Spring Cloud projects use them, we can dig deeper and make sure you have what you need.
Comment From: spencergibb
Sure. My term replacements wasn't probably the most descriptive. ConfigurationBeanFactoryMetadata is in a method signature and can't be removed on our side. I'll have to look at the health stuff in more detail to see if a Hoxton app can run with boot 2.3 without those.
Comment From: scottfrederick
@spencergibb I'll look into restoring ConfigurationBeanFactoryMetadata first thing tomorrow.
Comment From: wilkinsona
ConfigurationBeanFactoryMetadata is rather pointless in Boot 2.2. It no longer holds any state and just delegates straight onto the application context. I wonder if the logic could be moved to Cloud rather than leaving it in Boot's public API?
Comment From: spencergibb
Having it missing breaks our build with 2.3
Comment From: scottfrederick
@spencergibb ConfigurationBeanFactoryMetadata has been restored in 2.3.0 snapshots. We'll leave this issue open until you can confirm that the health indicator and status aggregator replacements work for Spring Cloud.
Comment From: spencergibb
The health stuff is deprecated in spring cloud and can't be removed until ilford. Without them our build will break.
Comment From: scottfrederick
Just so I understand, the classes that were removed from Boot are in a public API in Spring Cloud, not just used internally?
Comment From: spencergibb
yes
Comment From: scottfrederick
Can you point us to the Spring Cloud projects that need CompositeHealthIndicator and HealthAggregator so we can test that we get the necessary classes back in place?
Comment From: spencergibb
Spring Cloud Commons and Spring Cloud Netflix off the top of my head.
Comment From: scottfrederick
@spencergibb The 2.2.x branches of spring-cloud-build, spring-cloud-commons, and spring-cloud-netflix all now build for me with the latest Boot 2.3.0.BUILD-SNAPSHOT. Hopefully that covers any other projects that need these classes restored.
I had to add a direct dependency on spring-boot-starter-validation in a few subprojects to get them to build due to https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.3.0-M1-Release-Notes#validation-starter-no-longer-included-in-web-starters:
spring-cloud-commons/spring-cloud-loadbalancerspring-cloud-netflix/spring-cloud-netflix-zuulspring-cloud-netflix/spring-cloud-netflix-sidecar
That should be a backward-compatible change in dependencies.
If you can confirm with a full build of Spring Cloud with Boot 2.3.0 snapshots, I think we can close this issue.
Comment From: spencergibb
yeah, I did that in master earlier.
So it looks like de1a26cf35b260fdf1133742cce00e64d31d033f and afb67887da5586353f71fe4d79d23431d69bc3f2 fix this then?
Comment From: scottfrederick
So it looks like de1a26c and afb6788 fix this then?
Yes, those two commits have hopefully restored everything Cloud needs for compatibility.
Comment From: scottfrederick
@spencergibb I'm going to close this issue based on my testing, feel free to re-open if your builds uncover a problem.
Comment From: fduser1
@scottfrederick Are there plans to re-drop the deprecated the code in later versions of Spring Boot 2.3, or is that going to be held off until v2.4?
(I maintain a library that makes usage of the deprecated code. I want to be able to support all supported versions of Spring Boot which currently span between 2.1-2.3 at the moment.)
Comment From: spencergibb
It won't happen in 2.3
Comment From: scottfrederick
The current (informal and so-far-undocumented) policy is to remove deprecations no sooner than two minor versions after being marked deprecated. So something marked as Deprecated since 2.2.x would be removed no sooner than in 2.4.0. With the six-month Spring Boot release cycle, this policy would give users one year to adapt.
As a rule, deprecations are not removed in patch versions (e.g. 2.3.1).
Comment From: rshar31
I'm upgrading our spring boot application from Spring boot 2.1.7 Release version to 2.7.9. Can anyone give me the solution for these replacement:
org.springframework.boot.actuate.health.CompositeHealthIndicator was replaced by org.springframework.boot.actuate.health.CompositeHealthContributor
org.springframework.boot.actuate.health.HealthAggregator was replaced by org.springframework.boot.actuate.health.StatusAggregator
As these replacement implementation and their methods are different. Should I need to write new implementation or is their any alternative for this. @scottfrederick, @spencergibb
Comment From: philwebb
@rshar31 You'll need to adapt to the new interfaces. If you have any further questions please ask on stackoverflow.com or gitter.im. We prefer to keep the issue tracker for bugs and enhancements.