...
Display name and descriptive information associated with attributes used on the consent view is now determined in a just-in-time fashion. This reduces the processing needed for those deployments (or specific attributes) which do not require consent. This change should be irrelevant unless you are using an externally-developed feature using the old (and now deprecated) APIs. Legacy behavior can be re-established by using the idp.service.attribute.resolver.suppressDisplayInfo property.
The startup sequence now logs any duplicate properties it finds to help with debugging. This is generally only visible in the container log prior to IdP “startup” so requires proper logging configuration at that layer.
...
Also take note that with this release, the process of "finding" property files has been improved. In older versions, and when the idp.searchForProperties property is false/missing, the set of property files loaded is solely controlled by the idp.additionalProperties setting. New installs by default, or systems that explicitly enable the idp.searchForProperties property, will locate and load all files with the ".properties" extension in the conf tree. The explicit property can still be used for directly loading files from alternate locations.
Note that there are no plans to actually break or remove support for the older ways of configuring many features; the property additions are purely for simplification for newer deployers or for those who wish to take advantage.
Auto-Wired Components and Logging
...