Previously, the meta-data annotation processor was taking the first
setter that match the property name it has to handle. Contrary to
getters that are enforced by a return type (no argument), multiple
setter candidates may exist.
If a property's type got narrowed over time, the original setter may
have been marked as Deprecated. As the annotation processor takes the
first setter that matches based on the name only, it may pick up the
deprecated one and therefore mark the property as being (wrongly)
deprecatede in the meta-data.
It turns out that checking for the actual type of the setter parameter
brought a side effect: some primitive properties may use the primitive
or the Wrapper counter part. This commit not only look at the proper
setter based on the type but also fallback on the wrapper (or) primitive
if necessary.
Closes gh-4338
Previously, manual meta-data were added to the existing set of entries
which could lead to duplicates if a manual entry is meant to complement
a property that is detected via the processor.
We now match the name and type of the item against the auto-detected
entries. If no match is found, we add the extra entry as we did before.
If a match is found we override the description, default value and
deprecation information.
Closes gh-3562
The annotation processor detects `@ConfigurationProperties` bean or
method definition and merges manual meta-data. The former step will fail
with a NPE if the annotation is not present on the classpath. This could
happen if the annotation processor is added to a module that is not
actually using Spring Boot.
We now have a defensive check that skips that steps but still attempts to
merge manual meta-data if present.
Closes gh-3720
Add a new @DeprecatedConfigurationProperties annotation which can be
used by the `ConfigurationMetadataAnnotationProcessor` to generating
meta-data deprecated blocks.
Fixes gh-3543
Previously, an item could only have a 'deprecated' boolean flag to
indicate that the property is deprecated. It is desirable to provide an
additional description for the deprecation as well as the name of the
property to use instead.
The `deprecated` boolean flag is now supported. Instead, a `deprecated`
object can be specified with two optional attributes: `reason` to provide
an explanation for the deprecation and `replacement` to refer to the
property that should be used instead. If none of them is present, an
empty deprecation object should be set.
For backward compatibility, the `deprecated` field is still set.
Deprecation information can only set via manual meta-data.
Closes gh-3449
If a field is initialized via a factory method taking a single argument,
we can relatively safely consider that said argument is a good
representation of its default value. This is typically the case for
Charset or MimeType instances.
We now make sure to detect such use case (i.e. method argument with a
single argument).
Closes gh-3482
Liquibase has a `changeLog` property that is definitely used as a
`Resource` but cannot be defined as such as the original String value
should be kept against an API we don't control.
Update the tests also to make it more clear that if hints are added
against a property that is detected automatically, said property still
keeps all its auto-discovered capabilities.
Closes gh-3457
Make sure to fail the build with a proper compilation error message if
the user-defined meta-data are invalid. For now, this takes care of the
JSON format but other checks may be added in the future.
Closes gh-3329
Spring Buildmaster
Phillip Webb
Stephane Nicoll
Johnny Lim
Andy Wilkinson
arghya88